Requirements volatility is one of the classical problems encountered in systems engineering and new product development. Changes in requirements that occur or are discovered after the design has started can lead to costly delays, rework, project cancellation or even failures in the field. However, the root cause analysis behind requirements volatility tends to stop prematurely by focusing on bad requirements gathering, writing, analysis or modeling behaviors.
If you continue to ask “What caused the cause?” when confronted by an unexpected change in requirements, you will most often get back to the same fundamental process defect, “failure to manage our decision baseline“. That’s because every requirement is the result of an upstream decision; every requirement is a derived requirement. If you don’t control the requirements derivation process (which is 100% decision-making), then you can’t expect its output (requirements) to be stable and unchanging.
Here’s how requirements are created. I (or my customer) make a decision and commit to implement a specific alternative. This alternative has inherent consequences (aka derived requirements) that flow from its definition:
- Life cycle
These derived requirements can and should be captured at the point of decision and communicated immediately to other decision-makers on the project. The decision and its consequences should be captured as part of the project’s decision baseline. The owners of various requirements sets should then take these derived requirements and blend them into the requirements baseline where appropriate; perhaps refining and elaborating them so they are expressed in the language most useful to downstream decision-makers. Explicit traceability should be maintained between the decision baseline (which includes the decision-maker’s initial statement of derived requirements as they understand them) and the requirements baseline (the translation of these “raw” derived requirements into official, testable and approved requirements).
In a large project or complex product, decisions are (and must be) made in parallel and by many different parties; requirements are being created one decision at a time. Therefore, the process of maintaining decision-to-requirements traceability should also be nearly continuous, i.e. done on a per-decision basis. This delivers the latest set of constraints to each downstream decision-maker as soon as they are created and known so that these constraints can be appropriately factored into each decision.
The starting point for a good decision baseline is a proven decision pattern that frames the project/product as a Decision Breakdown Structure (DBS) of “fundamental questions/issues that demand an answer/solution”.
Failure to manage the decision baseline and decision-to-requirements traceability condemns your project to an uncomfortably high and risky level of requirements volatility. If this is you, then create and manage your decision baseline and avoid requirements volatility by leveraging the powerful capabilities of the Decision Driven® Solutions Framework (DDSF). Get started today by contacting the Decision Driven® Solutions team at email@example.com or firstname.lastname@example.org to begin a free trial.