THE SHORT ANSWER
Turn an idea into a requirement by moving through PROBLEM → USER → USE CASE → OUTCOME → FEATURE → REQUIREMENT. Define what the system must do, the quality or constraint it must satisfy, the assumptions still untested and the observable acceptance criteria for the first useful version.
Move from problem to requirement
| Layer | Question | Illustrative registration example |
|---|---|---|
| Problem | What is difficult today? | People cannot reserve a workshop place reliably |
| User | Who experiences it? | Eligible participant |
| Use case | When and why do they act? | Select a session and register |
| Outcome | What should be true afterwards? | A valid place is recorded and confirmed |
| Feature | What capability supports it? | Registration form and confirmation |
| Requirement | What must the system do? | Validate eligibility and prevent duplicate active registration |
Separate functional and non-functional needs
A functional requirement states behavior: a user can submit a registration. A non-functional requirement states a quality or constraint: the form must be keyboard usable, protect personal data and return a clear result under expected load.
Constraints include budget, deadline, regulation, existing systems, team capability and supported devices. Assumptions identify what still needs evidence.
Use a lightweight product brief
- Problem and evidence
- Target user and context
- Desired outcome
- Primary journey
- In-scope capabilities
- Explicitly out-of-scope work
- Data and integrations
- Risks and constraints
- Acceptance criteria
- Open questions and owner
A user story can prompt discussion: ‘As a [user], I need [capability], so that [outcome].’ It does not replace acceptance criteria or technical analysis.
Evidence & context: GOV.UK Service Manual · GOV.UK Service Manual
Write criteria someone can check
‘Easy to use’ is an aspiration. ‘A first-time participant can choose a session, correct invalid fields and receive confirmation without staff help’ is observable. Include error and permission conditions, not only the happy path.
Before committing to the build, ask: Do we need this? Who needs it? What is the smallest useful version? What data must it store? Which systems must connect? What can go wrong? How will we test it, and how will we know it works?
Validate the underlying need through Startup Idea Validation, then map the user journey.
Sources & further reading
- Learning about users and their needs
GOV.UK Service Manual. Public-service design guidance linking user needs to stories, acceptance criteria and continued research. Its process should be adapted to the product and risk context.
- Agile tools and techniques
GOV.UK Service Manual. Practical guidance on user stories, prioritized backlogs and collaborative delivery. User stories support discussion; they do not replace design and technical analysis.
- Designing strong experiments
Strategyzer. Practitioner guidance on explicit hypotheses, relevant participants and well-designed artefacts. Experiment quality and interpretation still depend on context.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗