Problem Definition and Requirements
From Need to Spec
A requirement is a testable statement of what the design must do or be. The discipline is turning a vague stakeholder wish ("it should be easy to use") into something you can pass or fail ("a new user completes setup in under five minutes without documentation").
Distinguish carefully:
- Needs - the underlying goal (transport groceries safely).
- Requirements - measurable obligations derived from needs.
- Constraints - fixed boundaries: budget, envelope, standards, available voltage. Constraints are requirements you cannot trade away.
- Specifications - the target values assigned to requirements.
- Assumptions - beliefs not yet verified. Every assumption is a risk; list them explicitly.
Requirements should be verifiable, unambiguous, traceable to a need, and non-conflicting. Terms like "lightweight," "rugged," or "user-friendly" are traps: they are not measurable until given a number and a test method. Also watch for requirements that specify a solution rather than a need ("must use a steel bracket") - these prematurely close the design space.
Traps
- A question gives a requirement with no acceptance criterion and asks whether it is well-formed. It is not.
- Confusing a constraint with a preference: a preference can be traded in a trade study; a constraint cannot.
- Missing the negative requirement - what the design must not do (must not exceed 60 dB, must not require mains power).
Rule of Thumb
If you cannot write the test, rewrite the requirement. Before accepting any requirement, ask: what instrument, measurement, or observation would prove compliance? If the answer is fuzzy, the requirement is fuzzy.
Worked example: "The enclosure must be weather-resistant" becomes "The enclosure prevents water ingress when sprayed at 12.5 L/min for 3 minutes from any direction, per the applicable ingress-protection test." Now it can be verified, and the designer knows what to design against.