Do you understand Requirements and Requirements Engineering? This article provides a good introduction.
A software requirement is a description of a specific capability that a software product is expected to have in order to satisfy the needs of stakeholders. While there is no single, agreed-upon definition of the term, it encompasses both the things that the software must do and the conditions under which it must do them. Requirements engineering is the process of formally identifying, documenting, and validating software requirements. For software engineers, requirements engineering represents the first steps in the development of a software product; requirements translate into specifications that then inform the design and implementation.
Special emphasis is given to the requirements process because it is well known that the most painful struggles and the most spectacular failures in software development stem from oversights and misestimations early in the life of a project (Reel 1999). Scientific software is no exception. Studies conducted by NASA in the early 1990s found that while cost overruns were rampant among R&D projects, projects that invested 2% to 3% of their budget on planning and developing requirements saw cost overruns between 80% and 200%, whereas those that invested 8% to 14% of their budget had overruns between 0% and 50% (Hihn and Habib-Agahi 1991, Habib-Agahi et al. 1991). The benefits are well established: requirements engineering, by far the least expensive development activity, has an outsized impact on everything that follows.
Nevertheless, numerous studies have found that scientific software developers, as a rule, do not produce requirements documents (Segal 2005, Segal 2009, Sanders and Kelly 2008, Li et al. 2011, Heaton and Carver 2015). There are several reasons for this situation, perhaps the greatest one being that researchers simply don't know how. Many scientific software projects are exploratory in character, and the requirements are discovered in the course of development. Trying to produce complete, well-articulated requirements upfront would be an exercise in futility. However, with some considerations and adaptations, readers will find that requirements engineering techniques can yield tremendous benefits.
In this mini-series of articles, we explore the practical application of requirements engineering for scientific software. We also provide terms, tools, and techniques to empower both scientific software developers and clients.
Mini-series list
- Understanding requirements
- Writing requirements
- Understanding and Performing the requirements engineering process
Citations
- John S Reel. Critical success factors in software projects. IEEE Software, 16(3):18–23, 1999.
- Jairus Hihn and Hamid Habib-Agahi. Cost estimation of software intensive projects: A survey of current practices. In Proceedings of the 13th international conference on Software engineering, pages 276–287. IEEE Computer Society Press, 1991.
- Hamid Habib-Agahi, Shantanu Malhotra, and James Quirk. Estimating software productivity and cost for NASA projects. Journal of Parametrics, 11(1):59–71, 1991.
- Judith Segal. When software engineers met research scientists: A case study. Empirical Software Engineering, 10(4):517–536, 2005.
- Judith Segal. Some challenges facing software engineers developing software for scientists. In Software Engineering for Computational Science and Engineering, 2009. SECSE’09. ICSE Workshop, pages 9–14. IEEE, 2009.
- Rebecca Sanders and Diane Kelly. Dealing with risk in scientific software development. IEEE software, 25(4), 2008.
- Yang Li, Nitesh Narayan, Jonas Helming, and Maximilian Koegel. A domain specific requirements model for scientific computing (NIER track). In Proceedings of the 33rd International Conference on Software Engineering, pages 848–851. ACM, 2011.
- Dustin Heaton and Jeffrey C Carver. Claims about the use of software engineering practices in science: A systematic literature review. Information and Software Technology, 67:207–219, 2015.
