Abstract
Context: Some believe that Requirements Engineering (RE) for a computer-based system (CBS) should be done up front, producing a complete requirements specification before any of the CBS’s software (SW) is written. Problem: A common complaint is that (1) new requirements never stop coming; so upfront RE goes on forever with an ever growing scope. However, data show that (2) the cost to modify written SW to include a new requirement is at least 10 times the cost of writing the SW with the requirement included from the start; so upfront RE saves development costs, particularly if the new requirement is one that was needed to prevent a failure of the implementation of a requirement already included in the scope. The scope of a CBS is the set of requirements that drive its implementation. Hypothesis: We believe that both (1) and (2) are correct, but each is about a different category of requirements, (1) scope determininG (G) or (2) scope determineD (D), respectively. Past Work: Re-examination of the reported data of some past case studies through the lens of these categories indicates that when a project failed, a large number of its defects were due to missing D requirements, and when a project succeeded, the project focused its RE on finding all of its D requirements. Conclusions: The overall aim of the future research is to empirically show that focusing RE for a chosen scope, including for a sprint in an agile development, on finding all and only the D requirements for the scope, while deferring any G requirements to later releases or sprints, allows upfront RE (1) that does not go on forever, and (2) that discovers all requirements whose addition after implementation would be wastefully expensive, wasteful because these requirements are discoverable during RE if enough time is devoted to looking for them.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
A mnemonic: The first letters that completely distinguish the phrases “scope determining” and “scope determined” are the phrases’ last letters!
- 2.
The example does not expose all the nuances that emerge only when the definitions are applied to real-life CBSs.
- 3.
Use of mathematical notation, e.g., the variable “C ”, is not signaling any attempt to be formal about inherently informal, real-world concepts [17]. Attempts to stick to only natural language led to confusingly ambiguous sentences, e.g., with two different scopes distinguished by multi-word adjective phrases that confused the authors!
- 4.
The data from which the list of pains is obtained are in the papers listed at the cited website [27].
References
Agile Alliance. Principles: The Agile Alliance (2001). http://www.agilealliance.org/
Balaji, S., Sundararajan Murugaiyan, M.: WATEERFALLVs [sic] V-MODEL Vs AGILE: A COMPARATIVE STUDY ON SDLC. JITBM 2(1) (2012)
Barbosa, L., Freire, S., et al.: Organizing the TD management landscape for requirements and requirements documentation debt. In: Proceedings of WER (2022). http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER22/WER_2022_Camera_ready_paper_28.pdf
Berry, D., Daudjee, K., et al.: User’s manual as a requirements specification: Case studies. REJ 9(1), 67–82 (2004)
Berry, D., Lucena, M., et al.: Scope determined (D) versus scope determining (G) requirements: A new significant categorization of functional requirements. Tech. rep., Univ. Waterloo (2023). https://cs.uwaterloo.ca/~dberry/FTP_SITE/tech.reports/GvsDprelimTechReport.pdf
Berry, D.M., Czarnecki, K., et al.: Requirements determination is unstoppable: An experience report. In: Proceedings of RE, pp. 311–316 (2010)
Berry, D.M., Czarnecki, K., et al.: The problem of the lack of benefit of a document to its producer (PotLoBoaDtiP). In: Proceedings of SWSTE, pp. 37–42 (2016)
Berry, D.M., Damian, D., et al.: To do or not to do: If the requirements engineering payoff is so good, why aren’t more companies doing it? In: Proceedings of RE, p. 447 (2005)
Boehm, B.W.: Software Engineering Economics. Prentice-Hall, Englewood Cliffs (1981)
Boehm, B.W.: A spiral model of software development and enhancement. SIGSOFT Softw. Eng. Notes 11(4), 14–24 (1986)
Ellis, K., Berry, D.M.: Quantifying the impact of requirements definition and management process maturity on project outcome in business application development. REJ 18(3), 223–249 (2013)
Gaborov, M., Karuović, D., et al.: Comparative analysis of agile and traditional methodologies in IT project management. jATES 11(4), 1–24 (2021)
Gause, D., Weinberg, G.: Exploring Requirements: Quality Before Design. Dorset House, New York (1989)
Gellert, C.: Requirements engineering and management effects on downstream developer performance in a small business findings from a case study in a CMMI/CMM context. Master’s thesis, Univ. Waterloo, Canada (2021). http://hdl.handle.net/10012/17777
Greenspan, S.J.: Extreme RE: What if there is no time for requirements engineering? In: Proceedings of RE, pp. 282–284 (2001)
Isaacs, D., Berry, D.M.: Developers want requirements, but their project manager doesn’t; and a possibly transcendent Hawthorne effect. In: Proceedings of EmpiRE (2011)
Jackson, M.A.: Problems and requirements. In: Proceedings of ISRE, pp. 2–8 (1995)
Jiang, L., Eberlein, A.: An analysis of the history of classical software development and agile development. In: Proceedings of IEEE SMC, pp. 3733–3738 (2009)
Kalinowski, M., Curty, P., et al.: Supporting defect causal analysis in practice with cross-company data on causes of requirements engineering problems. In: Proceedings of ICSE SEIP, pp. 223–232 (2016)
Kasauli, R., Knauss, E., et al.: Requirements engineering challenges and practices in large-scale agile system development. JSS 172, 110851 (2021)
Lehman, M.M.: Programs, life cycles, and laws of software evolution. Proc. IEEE 68(9), 1060–1076 (1980)
Lehman, M.M.: Laws of software evolution revisited. In: Montangero, C. (ed.) EWSPT 1996. LNCS, vol. 1149, pp. 108–124. Springer, Heidelberg (1996). https://doi.org/10.1007/BFb0017737
Lucia, A., Qusef, A.: Requirements engineering in Agile software development. J. Emerg. Technol. Web Intell. 2(3), 212–220 (2003)
Malm, T.: Requirements engineering in agile projects - Comparing a sample to requirements-engineering literature. Master’s thesis, Faculty of Social Sciences, Business and Economics, Åbo Akademi Univ., Turku, Finland (2020). https://www.doria.fi/bitstream/handle/10024/177487/malm_tobias.pdf
Mendez, D., Tießler, M., et al.: On evidence-based risk management in requirements engineering. In: SWQD: Methods and Tools for Better Software and Systems, pp. 39–59 (2018)
Mendez, D., Wagner, S., et al.: Naming the pain in requirements engineering: Contemporary problems, causes, and effects in practice. EMSE 22, 2298–2338 (2017)
NaPiRE: Napire data and publications (Viewed 1 November 2022). http://napire.org/#/data
Ou, L.: WD-pic, a new paradigm for picture drawing programs and its development as a case study of the use of its user’s manual as its specification. Master’s thesis, Univ. Waterloo (2002). https://cs.uwaterloo.ca/~dberry/FTP_SITE/tech.reports/LihuaOuThesis.pdf
Rasheed, A., Zafar, B., et al.: Requirement engineering challenges in agile software development. Math. Prob. Eng. 2021 (2021)
Rogers, G.: How agile can requirements engineers really be? RE Magazine (2014). https://re-magazine.ireb.org/articles/requirements-engineers
Royce, W.W.: Managing the development of large software systems: Concepts and techniques. In: WesCon (1970)
Schach, S.R.: Classical and object-oriented software engineering with UML and Java, 4th edn. McGraw-Hill, New York (1998)
So, J., Berry, D.M.: Experiences of requirements engineering for two consecutive versions of a product at VLSC. In: Proceedings of RE, pp. 216–221 (2006)
Thesing, T., Feldmann, C., Burchardt, M.: Agile versus waterfall project management: Decision model for selecting the appropriate approach to a project. Procedia Comput. Sci. 181(01), 746–756 (2021)
Van Cauwenberghe, P.: Chapter 18: Refactoring or up-front design? (2002). http://wwww.agilecoach.net/html/refactoring_or_upfront.pdf
Wagner, S., Mendez, D., et al.: Requirements engineering practice and problems in Agile projects: Results from an international survey. In: Proceedings of CibSE, pp. 85–98 (2017)
Acknowledgements
The authors thank Luiz Márcio Cysneiros, Sarah Gregory, Irit Hadar, Andrea Herrmann, John Mylopoulos, Mike Panis, Davor Svetinovic, and Anna Zamansky for their comments on previous drafts or in oral presentations of this work.
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2023 The Author(s), under exclusive license to Springer Nature Switzerland AG
About this paper
Cite this paper
Berry, D.M., Lucena, M., Sakhnini, V., Dhakla, A. (2023). Scope Determined (D) and Scope Determining (G) Requirements: A New Categorization of Functional Requirements. In: Ferrari, A., Penzenstadler, B. (eds) Requirements Engineering: Foundation for Software Quality. REFSQ 2023. Lecture Notes in Computer Science, vol 13975. Springer, Cham. https://doi.org/10.1007/978-3-031-29786-1_6
Download citation
DOI: https://doi.org/10.1007/978-3-031-29786-1_6
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-031-29785-4
Online ISBN: 978-3-031-29786-1
eBook Packages: Computer ScienceComputer Science (R0)