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)

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:

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 CorporationDavid M Cronin