Requirements management for numeric requirements versus text requirements

1. Cognition Cockpit: Numeric Requirements v Text Requirements
Most of us who are familiar with requirements management are used to the idea of a requirement
being a textual "shall" description. For traditional requirements management, where a
requirement is identified, written, and tested, the text based shall statement works fine. But what
about when you have a requirement with a numeric target? Wouldn't it be nice to let the product
development team make predictions about the requirement satisfaction instead of just a pass/fail
statement?
The Cognition Cockpit engine supports a new concept in requirements management: the idea of
a numeric requirement type. This brings users the ability to define a requirement with a numeric
target and calculate the predicted requirement value based on the values of sub requirements.
This is sometimes referred to as Transfer Function Analysis (a phrase often used in the Design
For Six Sigma (DFSS) world). Some requirements may be simple Pass Fail and are
validated/verified through testing. Other requirements may have a specific physical target range
and are more appropriately evaluated through transfer functions. Following is a (very simple)
example of how Cockpit handles a numeric requirement:
Requirement: Power (in an electric circuit)
Target: "The Power shall be at least 10 Watts"
Subrequirements/Children of Power:
Current
Total Resistance
The engineer (or supplier/whoever) enters design values for Current and Total Resistance.
Current Design Value: 2 A +/- .1
Total Resistance: Design Value: 2.8 Ω +/-.05
Next, the engineer enters an equation in Cockpit (or uses a spreadsheet or uses Matlab: Cockpit
can run transfers functions through various methods):
Power = Current2 * Total Resistance
Cockpit will now evaluate the equation using the inputs (with variation) from the
subrequirements/children and calculate a predicted design value AND VARIATION for the
target requirement:
Power Predicted Design Value: 11.2 +/-.1.138
Cockpit automatically evaluates this predicted design value for Power against the target
statement for Power and does a Root Sum Squared (RSS) calculation and delivers the following
information real time to the team:
Power Process Capability/Cpk: 1.1 (or Z Score or PNC or DPMO)

2. Cockpit also automatically generates the following information real time (screen shot):
In this way, the engineer can see real time the likelihood that the Power requirement will meet
its target. When a subrequirement of Power changes- for example if the owner of Current gets a
new input from a vendor- Cockpit will recalculate the equation, notify the owners, and re-plot
the results. In addition, Cockpit can run Monte Carlo analysis on Power using various
distributions and distribution types (ex: normal, uniform, triangular, Weibull) for the
subrequirements Current and Total Resistance. In a real product development project there can
be a series of tiered transfer functions at various levels of the requirements flowdown. Each
equation will "roll up" as different values change on each subrequirement.
Here is a Cockpit screenshot showing the current engineering values for Power:

3. Note the user sees real time information for the Power requirement including predicted Design
Value, predicted Process (long or short) Value, and statistical (not just Pass Fail) Test Data.
Cockpit will also automatically generate a real time Scorecard for Power:
Of course, if you are working with software requirements, Cockpit may simply use Pass Fail test
results to "satisfy" the Power requirement (and flag defects where appropriate). However, in the
case where you have a physical requirement the transfer function capability of Cockpit is a way
for the design team to gain real time visibility into the predicted performance of a single
requirement, group of requirements, or the entire system.
©2011 Cognition Corporation
David M Cronin