Requirements and Decisions
“The systems requirements definition process generates a set of system requirements from the supplier’s perspective using the stakeholder requirements that reflect the user’s (stakeholders’) perspective as the basis.” 1
After (or as) the stakeholders’ needs and wants (what) are gathered, they are translated into formal requirements (by adding how well and under which conditions to the whats). After the ‘external’ requirements are gathered they are refined and allocated through the engineering process to implementable elements and recombined to systems (products).
This indicates the premise of engineering that the needs of a stakeholder can be elicited, then refined to a point that a solution which addresses those needs can be implemented. The refinement process expands on these needs to formally specify functions and constraints (while capturing non-functional requirements). It has been taught that the process of refining requirements has higher-level requirements creating lower-level derived requirement. While it is correct that there is an association between higher and lower level requirements, it is not a direct relationship.
Requirements are actually the operational translation of decisions (design). One requirement does not ‘begat’ the next. While a requirement may be associated with other requirements it does not directly create them. Rather, it influences associated requirements by embodying needs or constraints in criteria. Criteria inform Decisions, which select Alternatives for which derived Requirements are developed. This places Decision Making in the center of Systems Engineering (all engineering, really).
A ‘Requirement’ that results from this decision-making is often called a ‘derived requirement’. The real difference between the upper and lower requirement sets are due to the constraints of the decision; the lower requirements have fewer degrees of freedom in regard to its eventual implementation. In the engineering domain, the decision block is often called a ‘design decision’, which leads to our next section.
- INCOSE (2015). Systems Engineering Handbook: A Guide for System Life Cycle Process and Activities (4th ed.). D. D. Walden, G. J. Roedler, K. J. Forsberg, R. D. Hamelin, and, T. M. Shortell (Eds.). San Diego, CA: International Council on Systems Engineering. Published by John Wiley & Sons, Inc.
What are we REALLY doing ⬅ ✴ ➡ SyE_Architecting – Functional Analysis-Design and Decisions