Every requirement that you will ever face can be traced to an upstream decision; all requirements are derived requirements. I used to offer students in my Decision Driven® Design workshops a large cash prize if they could name a requirement that I couldn’t trace to such a decision; I’ve never had to pay up on that challenge. Pull out a requirements specification and do a thought experiment; you’ll quickly see why. Ask yourself which upstream decision(s) would have to change (i.e. by committing to a different alternative) for this requirement to be invalidated, weakened or made more demanding. You will always be able to find at least one decision that would blow up each requirement. If you get stuck on an example, send it my way and I’ll be glad to help.
Requirements are the inherent consequences that flow from the definition of an alternative that has been selected for implementation. As soon as the alternative is chosen as the committed solution, its inherent consequences become constraints that could affect (topple over, invalidate) all other decisions in the project. New requirements are created at the point of decision – at the instant you commit to the alternative.
As I’ve discussed before, the standard V-model of product development leaves the impression that requirements create requirements. This leads nearly everyone to maintain requirement-to-requirement traceability, when a decision-to-requirement traceability model better represents the true derivation process. The last time I reviewed the CMMI framework, it reinforced this flawed traceability paradigm. I’m amazed that there hasn’t been a revolt among systems engineers, given the effort required to maintain this incomplete form of traceability.
If you maintain requirement-to-decision-to-requirement traceability (i.e. capture the decision transform that links any set or pair of requirements) you have the ability to do a comprehensive impact analysis. You can walk the dependencies and see the ripple effect from changing any object (alternative or requirement). If you fail to capture the “decision in the middle”, a change requires recreating the derivation process from memory. This quickly becomes impractical when designing a complex product or system.
The traceability diagram below shows how a “decision in the middle” creates and transforms requirements. “Upstream” requirements constrain a decision (when translated into evaluation criteria). Alternatives have inherent consequences, including derived requirements that should be added to the requirements baseline. Multiply this diagram across all the decisions associated with a product or project and you have a complete view of the requirements derivation process.
You can create and manage your requirements in the Requirements Analysis tool available within the Decision Driven® Solutions Framework (DDSF) and then use our Decision Management tools to maintain requirement-to-decision-to-requirement traceability. Please contact the Decision Driven® Solutions team at firstname.lastname@example.org or email@example.com to start your free trial of DDSF.