Requirements Gathering Template: Turn Requests Into Testable Work
Download a requirements gathering template with interview questions, a completed example, acceptance checks, and a method for resolving conflicting requests.
A requirements gathering template records what users need to accomplish, why it matters, and how the delivered work will be checked. Start with the user's task before accepting a proposed feature as the answer. “We need a dashboard” is a request for a solution; it does not yet explain the problem.
Download the editable requirements gathering template. It includes interview prompts, a reusable requirement record, three completed examples, and a review checklist. Use it for a small workplace project without buying software or creating an account.
The goal is shared understanding that can guide delivery. A long document does not help if the requester, builder, and reviewer still imagine different results.
What does the template capture?
Capture the user, task, reason, evidence, required behavior, acceptance check, priority, and open questions. Keep each requirement separate enough to discuss, change, and verify without rewriting the whole project.
| Field | What to record |
|---|---|
| ID | A stable reference for this requirement |
| User and situation | Who needs to act, and in what context |
| Task and reason | What they need to achieve and why |
| Evidence or source | Observation, interview, policy, or other basis |
| Required behavior | What the delivery must enable |
| Acceptance check | How someone can establish whether it works |
| Priority and rationale | Why it belongs in this delivery |
| Owner and open question | Who can confirm it and what remains uncertain |
The GOV.UK Service Manual distinguishes user needs from the more constrained user stories used to describe features and content. Stories can include acceptance criteria and dependencies. Preserve that separation: a need explains the job; a requirement describes what a particular delivery must do about it.
Keep the overall purpose in your project brief. This template goes deeper into individual requirements. Repeating the full brief in every row makes the document harder to review without adding understanding.
A source field also prevents invented certainty. “Assumed by project team; needs confirmation” is more useful than presenting an untested preference as something users definitely need.
What should you ask before documenting a requirement?
Ask someone to describe the last time they tried the task, including where work stopped and what they did next. Concrete episodes reveal details that broad questions about ideal features often miss.
Try these prompts:
- What were you trying to accomplish?
- What happened immediately before you started?
- Which information or access did you need?
- Where did you become uncertain or unable to continue?
- What did you do instead?
- How would you know the task had been completed correctly?
Then ask them to show the current process where appropriate. A person may say the instructions are “hard to find” when the real problem is that three similarly named versions exist and nobody can identify the approved one.
GOV.UK's guidance on defining user needs includes operational needs and the skills required to deliver, use, and manage technology. For an internal project, speak with the people maintaining the result as well as those using it on launch day.
Do not turn one person's account into a claim about every user. Record whose experience you observed, the context, and what still needs checking. If you have only a requester interview, say so in the working record.
Also distinguish evidence from authority. A policy owner can confirm what a process permits; an employee can explain where it is confusing. Neither perspective automatically substitutes for the other.
What does a testable requirement look like?
Describe an observable behavior and a check that could fail. Replace “easy,” “modern,” and “user-friendly” with a concrete task someone must be able to complete under stated conditions.
The following three requirements are fictional examples for an expense FAQ. They demonstrate the format and do not represent actual user research.
| ID | Required result | Acceptance check |
|---|---|---|
| R-01 | A new starter can reach approved submission instructions from the welcome message | With new-starter access, follow the published link and locate the submission steps |
| R-02 | Readers can identify the current policy source | Every FAQ answer links to the policy version confirmed by the policy owner |
| R-03 | Readers know where to ask a question the FAQ does not answer | The FAQ names the responsible team and provides the agreed contact route |
For R-01, the evidence field might contain a documented interview in a real project. In this fictional exercise, the missing-link problem is simply a scenario assumption. Do not copy that assumption into your own project as if it were evidence you collected.
Each acceptance check should name the relevant conditions. A link opening for an administrator does not prove that a new starter can use it. A published contact address does not prove anyone is responsible for monitoring it; confirm ownership too.
Atlassian's product requirements guidance includes goals, assumptions, user stories, and explicit out-of-scope information. You can use those distinctions for a small document project without adopting a full software-development process.
Include operational constraints when they matter: access permissions, accessibility, maintenance ownership, or use on a particular device. A requirement about what something does is incomplete if the intended audience cannot use it in their actual situation.
How do you resolve conflicting requests?
Return to the agreed outcome, make the trade-off explicit, and ask the authorized owner to decide. Requirements gathering is not a promise that every requested feature will be delivered.
Suppose one person wants all expense guidance in one short FAQ while another wants every policy exception included. Both may have a reasonable concern. The first is protecting findability; the second is protecting accuracy.
Instead of choosing the louder preference, propose a checkable arrangement: concise answers link to the complete approved policy, and unusual cases point to the correct owner. Ask both parties whether that meets the actual need and what failure they still foresee.
For each disagreement, record:
- The competing requests and their reasons.
- The evidence or constraint supporting each.
- The consequence of choosing one approach.
- Who is authorized to decide.
- The decision and any condition that would reopen it.
The GOV.UK needs guidance emphasizes understanding the problem rather than starting from a preferred solution. That is especially useful when two proposed features appear incompatible but the underlying needs are not.
Do not label every request mandatory. Ask what fails without it and whether a smaller delivery still serves the agreed audience. Preserve rejected or deferred requests with reasons so the same debate does not restart without new evidence.
How do requirements become a manageable delivery plan?
Confirm the accepted requirements with users, delivery people, and the person who can approve the result. Then schedule a small coherent delivery while keeping each requirement linked to its source and acceptance check.
Read the requirements back in ordinary language. Ask the requester what they expect to be different after delivery, and ask the builder what they believe they must produce. A mismatch is cheaper to resolve here than after a polished implementation.
Use the project intake form when a new request belongs to a separate initiative. Use the workback schedule for the accepted delivery's dependencies and review steps. Neither document should replace the requirement's evidence or acceptance check.
Keep one current version. When a requirement changes, record the reason and assess the consequence before treating it as part of the existing commitment. Shared understanding needs maintenance, not just an initial approval.
Then translate accepted work into daily outcomes. Do Only 3 Things a Day helps you make a realistic plan around those outcomes and protect the attention they require. A requirement says what must become true; a daily commitment says what you will do to move it forward.
Frequently asked questions
Is requirements gathering only for software?
No. It can clarify a report, an internal guide, a workshop, or a changed process. The same questions apply: who needs what, why, under which conditions, and how will you check the result?
How is this different from a project brief?
The brief establishes the overall problem, outcome, boundaries, and ownership. Requirements describe individual capabilities or conditions the delivery must satisfy. Link the two rather than duplicating their full contents.
Must every request be accepted?
No. A request can be valuable and still fall outside the current scope, capacity, or evidence. Record the decision and reason, and identify a future review trigger where appropriate.
When should you stop gathering and start delivering?
Start a bounded delivery when the necessary requirements are understood well enough to act and verify the result. Keep investigating unresolved questions that affect later work; complete certainty about everything is rarely a useful starting condition.