The purpose of the requirements matrix is to identify the links between the market requirements and performance measures. Market requirements describe the features that will make the design desirable. Performance measures guide the engineering decisions used to make the design real (tangible).
Refer to the Requirements matrix section in part 2 of the textbook.
Tasks
-
List primary market requirements. This step itself takes effort and can be broken down into substeps. Establish an importance value for each market requirement. Mattson and Sorensen recommend using a multiplicative progression (1, 2, 4, 8, 16) or geometric progression (1, 3, 9) to create significant gaps between importance values.
- Identify performance measures that will enable the team to develop a design
that satisfies the market requirements.
- Each market requirement will need at least one performance measure.
- Any on performance measure will be able to map to (satisfy) more than one market requirement.
Performance measures are metrics that have units.
- Develop target values for each performance measure.
- During opportunity development (before conceptual design), the target values might only be guesses
- As the design evolves, e.g. during concept development and later, the team
will gain a better understanding of how easy it is to reach target
values, or even whether the targe values are feasible.
Along with specific target values, most performance measures should have a range of acceptable values, that provide upper and lower limits for the performance measure.
-
Use the matrix format to identify the linkages between the primary market requirements and the performance measures. In the matrix, these linkages are indicated by dots in the cells where the market requirement and the performance measure intersect.
-
Use the importance values for the market requirements, and the intersections locations in the matrix to compute an importance value for each performance measure. Performance measures with higher importance values will have a bigger impact on the desirability of the design – higher importance means satisfying more or more important market requirements.
- Identify and consider tradeoffs where performance measures are in conflict. This will focus effort of the team on these conflicts, which may result in re-imagined conceptual design or substitution of subsystem designs (at later stage).
Iteration is necessary.
- Refine the matrix as customer requirements are added, removed, or have importance values changed.
- Refine the matrix to make performance measures more precise, e.g. as modeling or prototype testing during concept development or subsystem design lead to better understanding of the technology used in the design.
- Re-imagine the conceptual design to reduce conflicts or tradeoffs – Do this by creating separate requirements matrices for each conceptual design.
Apparent Sources of Confusion
-
Nearly identical market requirements and performance measures. This is tricky, or seems to be. Students will list a market requirement like "power supply detaches to reduce weight" and a performance metric "Detachable power supply" with a yes/no measurement scale. Students appear to confuse a design requirement (e.g. minimize weight) with how that is achieved (detachable power supply, in this case).
-
Too many yes/no requirements. If a requirement leads to a yes/no metric, ask yourselves whether that metric (1) is truly optional, and (2) whether including that requirement involves a tradeoff. If the metric is not optional, it becomes an absolute feature or a constraint, and including it in the requirements matrix does not provide much value. If the requirement does not involve any tradeoffs, e.g. including an on/off switch, then consider leaving it out of the requirements matrix. That does not mean removing the requirement from the design!
-
Unhelpful market requirements. If the market requirements are poorly chosen, e.g. are vaguely worded, or there are too few or too many market requirements, then building a requirements matrix will be not yield much insight
The requirements matrix is a tool to help your team think about the performance measures for your project and how those performance measures are related to market requirements. The real value in developing a requirements matrix is the degree to which it increases understanding of your performance measures. Improved knowledge of both market requirements and performance measures, and their connection, will help your team focus engineering effort where it will have the best chance of satisfying market requirements.
From the textbook (p. 284 in 4th edition)
A requirements matrix is a
… tool for translating broad market requirements into specific performance measures that are generally quantitative.
from p. 285 (under "Using the requirements matrix")
It is most easily used by first listing the market requirements in Section A. Then, for each market requirement, the team decides what performance measures would best represent market requirements. These are placed in Section B. The team seeks unambiguous objective performance measures. When objective performance measures are not possible, the team creates unambiguous subjective performance measures. This is continued for each market requirement. Next the team indicates relationships in section C. Finally, through dialogue with others, benchmarking, and other research, the team establishes the ideal values in section D.
…
During concept development, after a concept is chosen, the team reconsiders the performance measures and the tradeoffs that exist between them for the chosen product concept.
…
During any stage of development, the predicted and measured value are placed in section E of the matrix. The predicted and measured values are compared with the target values during the approval [step] at the end of various stages.