In one line: A specification is a metric plus a value. It translates a customer need into a measurable target the team can design to, test against, and keep score with.
Core idea
Customer needs are written in the customer’s language (it must be loud). Engineers need something measurable. A specification pairs a metric (sound pressure level, in dB) with a value (100 dB or more at 1 m), so the need becomes a target that can be verified. Ulrich and Eppinger call setting specifications one of the most integrative activities in development [1]. Customer needs, competitive benchmarks, technical feasibility and cost all have to come together at once.
How it works
Specifications are typically set twice:
| Target specifications | Final specifications | |
|---|---|---|
| When | after needs are identified, before concepts | after a concept is chosen |
| Based on | customer needs and competitive benchmarks | the chosen concept’s models, tests and cost |
| Values | often ranges: marginally acceptable to ideal | single values the team commits to |
Steps for target specifications:
- List metrics, each traceable to one or more needs.
- Collect competitive benchmarks.
- Set ideal and marginally acceptable values.
- Reflect: are any needs unmeasured, or any metrics unjustified?
Steps for final specifications:
- Build technical and cost models of the chosen concept.
- Refine the values based on what is feasible.
- Make the trade-offs explicit (see Trade-off Analysis).
- Flow specifications down to subsystems.
A worked example from class shows why the translation matters. “Loud” for a rock band means roughly 100 dB or more. A conventional speaker is only a few percent efficient, so reaching that level implies an amplifier on the order of 100 W, and that drives power supply, heat and cost.
In practice
Good specifications let the team keep score, force the first hard trade-offs early, and give verification a clear target. A useful exercise is to find a real product specification and identify its key metrics, units and values, then list at least three for your own project. Common failure modes include:
- metrics with no customer behind them
- needs with no metric
- values copied from the last product without anyone asking why
- specifications written so vaguely they can’t be tested
Questions to ask yourself
- Which of our key specifications can I trace to a customer need?
- Which value was set by habit rather than evidence?
- What is the marginally acceptable value, and does the team agree?
Connections
- From: Identifying Customer Needs, Market Requirements Document. Via: House of Quality.
- Used in: Concept Selection. Refined by: Trade-off Analysis.
- Capabilities exercised: Decision Making, Communicating and Advocacy, Connecting Across Disciplines.