CDT504 Chap.5 Metrics, Targets and Final Specifications
Metrics, Targets and Final Specifications
Metrics make needs testable
A specification pairs a metric with a value. Build a needs-metrics matrix to check that each important need is represented and that every metric has a reason to exist. Specify units and direction.
At least, at most and exactly create different failure conditions, and an exactly target is defensible only when movement either way harms performance.
Targets become final through trade-offs
Early targets use customer and competitive evidence. Final values incorporate selected concepts, technical models, bills of materials, prototype results and subsystem budgets.
Benchmarking cannot justify combining the best number from every competitor if the resulting package is infeasible.
What this chapter covers
- 01
Needs-metrics matrix
- 02
Units and direction
- 03
Marginal and ideal values
- 04
Competitive benchmarking
- 05
Technical and cost models
- 06
Final specification flow-down
Worked example · free
Interpret conflicting targets
- 2Compare each concept with both limits.
- 2Reject invalid averaging across units.
- 2Name the next model or test.
Key terms
- Metric
- An observable quantity used to represent performance against a need.
- Marginal Value
- The boundary of acceptable performance for a specification.
- Ideal Value
- The preferred performance level pursued when trade-offs allow it.
- Needs-Metrics Matrix
- A map showing which measures represent each customer need.
- Bill of Materials
- A list of parts and estimated purchase or fabrication costs used as an evolving cost model.
Metrics, Targets and Final Specifications FAQ
Why can one need require several metrics?
Complex outcomes such as usability or safety may not be represented faithfully by one product property. Combining objective properties with observed task performance can preserve the link to user value.
What is the difference between target and final specifications?
Targets are set early from needs and competitive evidence. Final specifications are revised after concepts, technical and cost models, prototypes and trade-offs reveal what can responsibly be promised.
How can a metric be gamed?
A team can improve the number while weakening the outcome it was meant to represent. Recheck the linked need and add another measure when the proxy can be optimised independently of user value.
Why should test conditions sit beside a metric?
The same label can produce incomparable results under different loads, environments, instruments or participant groups. A specification needs a definition and method as well as a value. Recording conditions lets later teams repeat the test and recognise when a design change invalidates an earlier comparison.
How are subsystem budgets checked?
Confirm that allocated mass, cost or power totals remain inside the system limit, then add interface demands and shared resources that local budgets may omit. Compliant subsystems can still fail at system level if connections, packaging or controls consume unallocated capacity.
When should a target be written as a range?
Use a range when performance is acceptable between two defensible boundaries and movement beyond either boundary harms the outcome or creates another cost. State the linked need and test method. A range should reflect evidence and trade-offs rather than conceal uncertainty about what value matters.
Assessment move
Create a needs-metrics matrix for one product and look for orphan needs and metrics. Label each value as minimum, maximum, exact or range and explain the direction. Recompute a simple bill of materials under high and low estimates. Finish by identifying one metric that could be gamed and pairing it with an outcome measure. Start with the needs list rather than available sensors or easy measurements.
For each important need, ask what observable change would demonstrate improvement and under what test condition. Give the metric a unit, direction, test method and owner. Where one measure cannot represent the outcome, use a small set and explain how the measures complement one another. Audit every direction word.
If lower force helps a user, an upper bound is likely; if sufficient runtime is required, a lower bound is likely; if deviation either way harms performance, justify an exact target or range. Write the reason beside the symbol before calculating anything. Add marginal and ideal values, keeping the boundary of acceptability distinct from the preferred result.
Use competitive evidence as a reference rather than constructing an impossible product from the best number in every column. Then build one technical model and one cost model. A bill of materials with high and low estimates is enough to expose whether performance gains consume the target cost. Update it when the concept or supplier assumption changes.
Flow system budgets to subsystems and check their sum, but also examine interface demands that local budgets omit. For revision, work a trade-off case with unlike units and explain why kilograms and hours cannot be averaged. Identify the need priorities or models that should resolve the decision. Finally, test proxy fidelity. Ask whether a team could improve the number while weakening the user outcome.
If so, revise the measure or add an observed-performance metric. This check turns quantified specifications into evidence rather than decorative precision.
