Scientific Computing (SC) software has significant societal impact due to its application in safety related domains, such as nuclear, aerospace, military, and medicine. Unfortunately, recent research has shown that SC software does not always achieve the desired software qualities, like maintainability, reusability, and reproducibility. Software Engineering (SE) practices have been shown to improve software qualities, but SC developers, who are often the scientists themselves, often fail to adopt SE practices because of the time commitment. To promote the application of SE in SC, we conducted a case study in which we developed new SC software. The software, we developed will be used in predicting the nature of solidification in a casting process to facilitate the reduction of expensive defects in parts. During the development process, we adopted SE practices and involved the scientists from the beginning. We interviewed the scientists before and after software development, to assess their attitude towards SE for SC. The interviews revealed a positive response towards SE for SC. In the post development interview, scientists had a change in their attitudes towards SE for SC and were willing to adopt all the SE approaches that we followed. However, when it comes to producing software artifacts, they felt overburdened and wanted more tools to reduce the time commitment and to reduce complexity. While contrasting our experience with the currently held perceptions of scientific software development, we had the following observations: a) Observations that agree with the existing literature: i) working on something that the scientists are interested in is not enough to promote SE practices, ii) maintainability is a secondary consideration for scientific partners, iii) scientists are hesitant to learn SE practices, iv) verification and validation are challenging in SC, v) scientists naturally follow agile methodologies, vi) common ground for communication has always been a problem, vii) an interdisciplinary team is essential, viii) scientists tend to choose programming language based on their familiarity, ix) scientists prefer to use plots to visualize, verify and understand their science, x) early identification of test cases is advantageous, xi) scientists have a positive attitude toward issue trackers, xii) SC software should be designed for change, xiii) faking a rational design process for documentation is advisable for SC, xiv) Scientists prefer informal, collegial knowledge transfer, to reading documentation, b) Observations that disagree with the existing literature: i) When unexpected results were obtained, our scientists chose to change the numerical algorithms, rather than question their scientific theories, ii) Documentation of up-front requirements is feasible for SC We present the requirement specification and design documentation for our software as an evidence that with proper abstraction and application of “faked rational design process”, it is possible to document up-front requirements and improve quality. / Thesis / Master of Science (MSc)