Derived requirements – continued

If decisions create requirements (as explained in my previous post), then decisions also create ALL the interactions between requirements.  This implies that there is never a constant, always-present, solution-independent relationship between any 2 requirements.

Perhaps you’ve been involved in populating or using a House of Quality as part of a Quality Function Deployment (QFD) initiative.  The House of Quality diagram has 2 parts that represent requirement-to-requirement interactions, a relationship matrix and a correlation matrix.  In each, a set of symbols is used to represent the strength and nature of the relationship (positive or negative correlation).   Many QFD practitioners assume that these relationships are constant and unchanging, but this is only true when you “freeze” the technology and platform decisions behind the House of Quality.

A relationship between a stakeholder need and a product characteristic (a user requirement and a system requirement) or 2 product characteristics is always solution/technology dependent.  If you make any significant changes to your technology platform or solution architecture, you blow up the House of Quality.  That’s why QFD is a very powerful method for making continuous, incremental improvements on a stable product platform, but not for inventing a disruptive alternative.

I use an outlandish example to teach this principle by asking:

  • “What is the relationship between the learning effectiveness of this workshop (a stakeholder need/goal for the training) and the average body mass of the students?”
  • “What is the correlation between student weight and classroom illumination?”

Most folks are politically correct enough to say “none”, not wanting to be accused of promoting a “fat people are stupid” stereotype.  I say there’s a very strong positive relationship and correlation because I’ve made a “Choose Classroom Lighting Technology” decision.  Instead of the ho-hum alternative (fluorescent lamps), I’ve committed to a “Let’s light the least-performing student on fire every N hours” solution.  This seemingly tangential decision ties together requirements (parameters/attributes) that would normally be completely independent.

Some would argue that science as represented by unchanging equations makes universal, solution-independent relationships between requirements.  Take Newton’s second law of motion as represented by F = ma (force = mass x acceleration).  This seems to say that a user need (acceleration) would have a strong negative relationship with a product characteristic (mass).  However, even Newton’s laws have a range of validity; they work within and across a specific (in this case, very wide) operating regime.  These laws break down (have to be amended) for nanoscale particles to account for quantum effects and near the speed of light to account for relativity.  “Choose Operating Regime” is an important decision for any product; it determines which science (equations) apply to your product and therefore which requirements are related.

Whenever you make a design decision, you may create unexpected relationships (cross-constraints) between requirements.  If you maintain a decision-to-requirements trace, you are more likely to catch these cross-constraints and factor them into your downstream decisions.  If you use the more common requirements-to-requirements traceability model, you are more likely to overlook these interactions and pay a price when future decisions fail to account for unexpected constraints.

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 or 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 Decision Concepts, Decision Driven Innovation, Decision Driven Product Development, Decision Driven Strategy and tagged , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

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

You are commenting using your 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