Question 5 of 5: Customer requirements and design specifications

Question 5: Customer requirements and design specifications (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

a) Definitions, characteristics and purpose

Customer requirements (also called customer needs or the voice of the customer) are qualitative statements, gathered directly from the people who will use, buy, install, service or dispose of the product, describing what they want the product to do or how they want it to perform — in the customer’s own language, without engineering jargon or numerical targets (e.g. "the tool should be easy to carry one-handed" or "the pump should not require maintenance more than once a year"). Their purpose is to capture the true problem being solved before any solution concept is fixed, and to give the design team a traceable, customer-validated basis against which every later design decision can be checked.

Design specifications (engineering specifications, or a Product Design Specification) are the quantitative, measurable, testable targets the engineering team derives FROM the customer requirements — each one stated with a metric, a unit, and either a target value with tolerance or a marginal/ideal value pair (e.g. "total mass ≤ 2.5 kg", "mean time between failures ≥ 8760 h"). Their purpose is to translate an ambiguous customer want into an unambiguous engineering target that can be designed to, verified by test or analysis, and used to compare competing concepts objectively. A good specification set is complete (covers every requirement), traceable (each spec can be linked back to the requirement(s) it satisfies), measurable (a number, not an adjective), and non-conflicting internally (or explicitly flags the trade-off if two specs pull against each other, e.g. mass vs. strength).

b) A systematic process for establishing design specifications

1. Gather the raw voice of the customer. Interviews, surveys, focus groups, and direct observation of the product/task in use; capture requirements verbatim, without pre-editing them into engineering language, so nothing is lost or misinterpreted early.
2. Organize and interpret the raw data. Sort the verbatim statements into an affinity diagram of related themes, then restate each as a clear, single-idea customer requirement (removing duplication and ambiguity, but still in customer-oriented terms).
3. Establish relative importance. Rank or weight the requirements (e.g. by direct customer rating, or a pairwise-comparison method) so the team knows which needs are must-have versus nice-to-have when trade-offs arise later.
4. Benchmark competitors. Measure how existing/competing products perform against each requirement, to calibrate what "good" looks like and to identify opportunities to differentiate.
5. Translate each requirement into one or more metrics. For every requirement, identify an engineering metric that, if satisfied, would satisfy the requirement (this many-to-many mapping is the core of a House-of-Quality / Quality-Function-Deployment matrix, which lays requirements against metrics and also cross-checks metrics against each other for conflicts).
6. Set target values. Using the benchmarking data and the importance weighting, set a numeric target (and acceptable tolerance/marginal value) for every metric — this final list of metric + target + tolerance IS the design specification set.
7. Reflect and iterate. Review the specification set as a whole for completeness and internal consistency, and revisit it at each later design stage (concept selection, embodiment, detail design) as more is learned about what is actually achievable, updating specs where reality and ambition conflict.