Requirements gathering turns a broad request into clear statements that a team can discuss and test. Learn to identify the underlying need, ask about constraints and exceptions, define acceptance conditions, and keep a traceable decision record. This roadmap uses a fictional equipment-loan service. Your final output is a small requirements pack that explains who needs what, why it matters, and how someone will know the result works.
Start with the problem rather than the proposed feature
The fictional request is “We need a better booking system.” Ask who experiences the problem and what currently happens. The receptionist reports overlapping reservations; borrowers cannot tell whether a camera is available. These are different needs that may share a solution. Write the current problem and its consequence before deciding that a calendar, chatbot, or mobile app is required.
Identify borrowers, reception staff, the equipment custodian, and the person responsible for service rules. Ask who can clarify eligibility and approve changes. Do not treat the loudest stakeholder as the only source of requirements. Record disagreements, such as whether staff can override a booking limit, instead of quietly choosing the answer you find easiest to implement.
Write statements with observable behaviour
Create a user story: as an eligible borrower, I want to see available collection slots so I can request equipment without arranging an impossible pickup. GOV.UK’s user-story guidance explains the user, need, and purpose structure Source 1. A story starts a conversation; it does not replace detailed rules or acceptance conditions.
Write a requirement that the system rejects overlapping confirmed loans for the same camera. Define overlap using start and end times, including whether one loan may end exactly when another begins. NASA’s requirements guidance discusses translating needs into clear technical requirements Source 2. Borrow the discipline of clarity and verification without imposing aerospace documentation scale on this small exercise.
Avoid adjectives such as fast, easy, and secure as complete requirements. Ask what those words mean in context and who can agree the criteria. For a beginner project, state a provisional response-time target as an assumption needing owner confirmation rather than inventing a service commitment and presenting it as approved.
Work through acceptance cases and exceptions
Use a fictional camera C1 with a confirmed loan from 10:00 to 12:00. A request from 11:00 to 13:00 must be rejected under the no-overlap rule. A request from 12:00 to 14:00 is permitted only if the agreed boundary rule allows immediate turnover. If inspection time is required, that condition changes the result and must be explicit.
Add cancellation, unavailable equipment, duplicate submission, and ineligible borrower cases. Write expected outcomes in plain language. A cancelled loan should free availability only according to the defined cancellation state, not merely because a person closes the browser. Keep the test data fictional and the examples small enough to inspect manually.
Create a traceability table linking need N1, requirement R1, acceptance cases A1–A3, and the decision owner. If a stakeholder changes the turnover rule, the table shows which tests and screens need review. Traceability is useful because it supports change analysis, not because a spreadsheet full of identifiers looks formal.
Prioritise and review the pack
Separate essential loan integrity from optional conveniences such as colour themes. Explain the consequence of delaying each item and identify dependencies. The Scrum Guide describes a Product Backlog as an ordered, evolving list in its framework Source 3. You can learn from the idea of ongoing refinement without claiming that this small documentation exercise is a full Scrum implementation.
Walk through the examples with a peer acting as receptionist and another acting as borrower. Ask them to identify ambiguous terms and missing recovery paths. Revise the statements when two reasonable readers predict different outcomes. Record approvals separately from unresolved assumptions so implementation does not turn a guess into policy.
Deliver the problem statement, stakeholder list, glossary, requirements, acceptance cases, and decision log. Include a short change-impact example for adding inspection time between loans. The next learning step is observing a real authorised workflow, where discovery and negotiation will reveal more complexity than a fictional brief can contain.
- DiscoverAsk about the problem and affected people.
- ClarifyDefine terms, rules, and exceptions.
- SpecifyWrite observable behaviour and examples.
- ReviewResolve disagreement and track changes.
| Checkpoint | What to produce | How to review it |
|---|---|---|
| Need | Avoid overlapping camera loans | Describe the current consequence |
| Requirement | Reject overlapping confirmed intervals | Define boundary and turnover rules |
| Acceptance | 11:00–13:00 conflicts with 10:00–12:00 | Expected rejection is explicit |
| Change | Add inspection time | Revisit availability and acceptance cases |
- Need
- Borrowers need a feasible collection slot.
- Requirement
- Availability reflects confirmed loans and agreed buffers.
- Test
- A conflicting request receives a clear rejection and recovery route.
Common questions
Is a user story the same as a requirement?
A user story expresses a user need and its purpose in a compact form. It usually needs discussion, rules, and acceptance conditions before implementation. A requirement can describe more specific behaviour or constraints. Use both where helpful, but do not assume a well-worded story resolves every boundary case or policy question.
What makes a requirement testable?
A reviewer can determine whether the expected behaviour occurred under defined conditions. “Prevent overlapping confirmed loans” becomes testable when overlap, confirmation, and timing boundaries are clear. “Make booking better” does not specify an observable result. Use concrete examples to reveal ambiguity before the team starts building the feature.
Should I include technical implementation details?
Include them when they are genuine constraints or necessary to communicate an agreed design decision. Avoid choosing a technology merely because a stakeholder proposed it before the problem was understood. Separate the need from the solution so the team can assess alternatives while respecting actual integration, performance, or organisational requirements.
How do I handle conflicting stakeholder requests?
Record the conflict, its consequences, and the person or group authorised to decide. Explore the underlying needs rather than simply voting on preferred features. Use examples to make the disagreement concrete. Do not silently resolve a policy issue in the document because implementation would otherwise be inconvenient.
Why define whether end times can touch?
A loan ending at noon and another starting at noon may or may not be feasible, depending on inspection and handover needs. Without an explicit rule, different developers or testers may make different assumptions. The boundary case is small but operationally important, so include it in the acceptance examples and decision log.
How much documentation is enough?
Enough to support a shared understanding, implementation, review, and change management for the risk and complexity involved. The fictional service needs a concise pack, not hundreds of pages. Remove duplicate descriptions but retain important rules and decisions. A short document is useful only if it does not conceal unresolved assumptions.
What should I do when a requirement changes?
Record the new decision, its reason, and the affected needs, tests, screens, and dependencies. Review whether earlier assumptions still hold. Traceability helps identify the impact rather than preventing change. Keep the previous version available so the team can understand why an expected outcome differs from an earlier discussion.
What demonstrates requirements skill in a portfolio?
Show an ambiguous request, the questions you asked, clarified rules, acceptance examples, and a revision after review. Include unresolved items honestly and label fictional stakeholders. A reviewer should see how your work reduced uncertainty and made a decision testable, not merely a large list of feature names formatted as user stories.
Continue your learning
Process Mapping Roadmap: Document a Workflow and Find Improvement Opportunities. Project Coordination Roadmap: Plan and Track a Small Team Project.
Sources and further reading
- GOV.UK: user stories — User, need and purpose in a story.
- NASA: requirements definition — Clear requirements derived from needs and verification thinking.
- Scrum Guide — Ordered, evolving Product Backlog within Scrum.
Skills & Learning Desk
MP Job Hub’s organisational byline for sequenced practice, course evaluation and useful learning habits.
Skill roadmaps · Learning resources · Practice projects
View profile →Read our research process or request a correction.
