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.