All requirements are derived requirements

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.

Decision-Requirements Trace

Decision-Requirements Trace

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 trial@decisiondriven.com or solutions@decisiondriven.com to start your free trial of DDSF.

About decisiondriven

Innovator in Decision Management, Systems Thinking and System Engineering methods and tools
This entry was posted in Big Ideas, Decision Concepts and tagged , , , , , , , , , , , . Bookmark the permalink.

2 Responses to All requirements are derived requirements

  1. I agree with your observation that all requirements can be traced to a decision at some level of abstraction.

    Picking a nit with CMMI over traceability, however, may prove to be limiting to your argument since the practice doesn’t *require* that traceability be limited only to requirements. In fact,
    (a) even as written, Specific Practice 1.4 discusses both traceability among requirements as well as work products resulting from or contributing to requirements, and
    (b) nothing in the practice says that traceability not be maintained from/to decisions.

    Furthermore, CMMI has an entire process area called “Decision Analysis and Resolution”, which when used properly, could easily and appropriately generate the sort of artifacts of decisions that would lend themselves to being traced to or from requirements. Your argument is actually a strong one for why CMMI should be consumed holistically rather than piecemeal, as many others do.

    Last note: Keep in mind, CMMI does not provide a process for managing requirements, but merely a handful of practices that would improve how requirements are managed. In this light, the practice for maintaining traceability should not be interpreted as what to maintain traceability to, or how to maintain traceability, rather as what benefits to product development and project management can be derived from maintaining traceability. In your argument, maintaining traceability to decisions is precisely the sort of thing organizations who understand the value of maintaining traceability would and ought to do! Interpreting CMMI REQM SP1.4 in such a way that only maintains traceability to/among requirements would easily leave large gaping holes in the collective understanding of the eventual product.

    Nice work!

  2. decisiondriven says:

    Hillel,
    You’re a generous soul – I see this as a gaping hole in CMMI which reinforces incomplete and unscientific traceability practices to the detriment of all. If CMMI is to be “consumed holistically”, it needs a holistic information architecture that integrates all the knowledge artifacts together in a way that’s consistent with thinking science.

    Requirement-to-requirement traceability really is a flawed (unscientific) concept except in the trivial case in which a higher-level requirement is simply allocated without change to a lower-level component.

    DAR at least references the fact that criteria should be traceable to requirements, but leaves out the second half of the traceability paradigm, that derived requirements (inherent consequences, constraints that flow from the selected alternative) should be captured and communicated to the requirements baseline before the decision analysis is deemed to be complete.

    I’ve been to over 50+ companies that are somewhere on a CMMI journey and have yet to have a single one who maintained any decision-requirement traceability until I explained the science of requirements derivation to them. There’s no reason to leave this ambiguity in CMMI; to leave the practice unchanged is akin to continuing to recommend trepanation let the evil spirits escape when treating epilepsy. If your doctor did that today you’d sue him/her for malpractice.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s