Problem Identification and Specification
This domain tests your ability to turn a fuzzy complaint or opportunity into a clear design brief and a specification that can be tested. Exam questions ask you to identify stakeholders, separate needs from wants, state constraints, and write criteria with values, units and methods of checking.
Core rules
- Identify the client (who pays), the user (who operates it) and other stakeholders such as maintainers or bystanders. Their needs may conflict.
- Research using interviews, observation, questionnaires, anthropometric data and product analysis. Report what the research changed.
- Write the brief as a short statement of intent, without prescribing the solution.
- Write the specification as a list of criteria. Each should be measurable, for example 'must clamp phones 60–85 mm wide' rather than 'must fit most phones'.
- Use 'must' for essential requirements and 'should' for desirable ones. Add constraints such as budget, deadline, available machinery and standards.
Worked example
Problem: cyclists cannot see phone navigation safely. Brief: design a holder that lets a cyclist view a phone while riding. Specification extracts: must clamp phones 60–85 mm wide; must hold a 200 g phone at 6 N vibration without loosening; must allow removal in under 10 seconds without tools; must keep phone dry in rain (IPX4 or better); mass under 120 g; material and processing cost under N$80; should allow portrait and landscape orientation. Each criterion has a value and a test method, so the prototype can be judged objectively.
Traps
- Adjective-only criteria such as 'strong', 'cheap' or 'attractive' - these cannot be tested.
- Specifying a solution ('must be 3D printed') instead of a requirement.
- Ignoring a stakeholder group, such as the person who cleans or repairs the product.
- Mixing the brief and specification in one paragraph.