Define the need before the product
A useful requirements brief describes what people need to achieve and the conditions a solution must satisfy. It gives suppliers a fair question and prevents attractive demonstrations from deciding the wrong problem.
Record the current process and evidence, the users affected, a measurable outcome, essential workflows, data and integration needs, accessibility, security and continuity constraints, budget and timing. Give every must-have a testable acceptance statement.
Use this one-page structure
| Section | Question to answer | Useful evidence |
|---|---|---|
| Problem and baseline | What happens now, for whom, at what volume and with which delay, error, cost or risk? | Observation, user interviews, process data, support records and sampled work. |
| Outcome | What should become better and how will the organisation recognise it? | A baseline, target, measurement owner and review date. |
| Users and workflows | Which internal and external users complete which important tasks, including exceptions? | Real scenarios, accessibility needs, devices, locations and support routes. |
| Information and dependencies | Which data, records, identities, integrations and suppliers must interact with the service? | Data inventory, dependency map, volumes, retention and ownership. |
| Constraints and acceptance | Which legal, security, continuity, budget and timing limits apply, and how will each essential need be tested? | Pass-or-fail statements with named evidence and an accountable reviewer. |
Write requirements that can be tested
Weak
“The system must be easy to use, secure and integrate with our tools.” This does not identify a user, task, threat, interface or pass condition.
Testable
“A trained caseworker using a keyboard must create, amend and retrieve a standard record in the pilot environment, with required fields validated and an audit event recorded.”
Keep the statement solution-neutral unless a genuine dependency requires a named standard or interface. Label preferences separately so that they cannot quietly overrule a real user need.
Finish with a decision rule
State which requirements are mandatory, which are weighted preferences, what evidence is acceptable, who can approve an exception and which unresolved risk would stop the decision. Keep the original brief so later reviews can test whether the chosen technology solved the stated problem.
GOV.UK guidance recommends starting with evidenced user needs and making choices that can adapt as understanding changes in its technology-choice guidance.
Technology requirements brief FAQs
How detailed should a technology requirements brief be?
Detailed enough for different suppliers and reviewers to understand the same problem and test the essentials, but no longer than the decision needs. Start with one page and attach evidence, workflows or technical schedules only where they change the choice.
What is the difference between a requirement and a preference?
A requirement must be satisfied for the solution to be viable; a preference improves suitability but can be traded against another benefit. Treating every wish as mandatory reduces competition and can increase cost without improving the outcome.
Should the brief name a preferred product?
Usually describe the outcome and constraints first. Name a product, platform or standard only when an evidenced dependency, policy or interoperability need genuinely requires it, and record why that constraint exists.
Continue your business technology decision
Use the next guide that matches the requirement, investment, supplier, implementation, migration, access, continuity or renewal question you still need to resolve.
