Scope determined (D) versus scope determining (G) requirements: A new significant categorization of requirements

Some believe that Requirements Engineering (RE) for a computer-based system (CBS) should be done upfront, producing a complete requirements specification before any of the CBS’s software is written. 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 software to include a new requirement is at least 10 times the cost of writing the software 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 the CBS’s implementation. 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. Reexamination of the reported data of some past case studies through the lens of these categories indicates that when a project fails, a large majority of its defects were due to missing D requirements, and when a project succeeds, the project focused its RE on finding all of its D requirements. The hypothesis that waterfall methods (WMs), with their upfront RE, do a better job of avoiding missing D requirements in developing CBSs than do agile methods (AMs) was not supported by the data from 8 WM projects and 8 similar AM projects in one company. In fact, the null hypothesis, that there is no difference between WMs and AMs in avoiding missing D requirements in developing CBSs, cannot be rejected for any logically posssible assignment of the collective data from the 16 projects to 16 specific projects. It appears that intimate knowledge of the domain and development of a CBS is necessary to be able to classify the CBS’s defects arising from missing requirements as of category D or G with respect to (w.r.t.) the CBS’s scope. Finally, software and requirement engineers are able to learn from a half-hour lecture about D and G requirements to correctly categorize most requirements of a familiar CBS as D or G, w.r.t. the CBS’s scope.