By Obaid Tariq, Founder & Lead Engineer · Published
Disclosure: AI Dev Planner is a software development company, and a brief written with this template is the kind we quote against. It works just as well with any other supplier. See our disclosure policy.
A software requirements document records what a system must do, how well it must do it, and how you will know it is finished. Its job is practical: give every development company the same picture, so their quotes can be compared, and give the team that wins a reference to build and test against.
The template below has eleven sections. Each one explains what to include and shows a short worked example. The examples all describe the same fictional project, an online booking system for a small group of physiotherapy clinics, so you can see how the sections fit together. Building a subscription product? Work through the SaaS MVP planning checklist first, then record the answers here.
So everyone knows which version is current, who owns it and who can approve a change.
Explains the problem and what success means, so the team can make sensible trade-offs when a detail is missing.
Every screen and permission follows from this list, so it is worth getting right first.
| Role | Needs to | May see |
|---|---|---|
| Patient | Book, cancel and rebook; join a waiting list | Only their own appointments |
| Receptionist | Manage bookings for their clinic | All appointments at their clinic |
| Physiotherapist | See their own schedule | Their own appointments |
| Clinic manager | Set opening hours and practitioners; view reports | Everything for their clinic |
The section that prevents most disputes. Anything not listed as in scope is out of scope.
What the system must do. Write each one so a tester could check it, and give it an ID and a priority.
FR-07 (Must). As a patient, I want to join a waiting list for a fully booked day, so that I am offered a slot if someone cancels.
Data decisions are the most expensive to change later, and they drive privacy, hosting and migration work.
Each integration needs its own estimate. Unknowns here are the most common cause of late surprises.
How well the system must work. These are easy to forget and change both the price and the architecture.
Writes down what everyone is taking for granted, so it can be checked rather than discovered.
An honest list of what is not known yet, each with an owner and a date to answer it by.
Defines how you will decide the work is finished, before the work starts.
Select the text below and paste it into your own document. Replace each bracketed prompt, and delete any line that genuinely does not apply rather than leaving it blank.
SOFTWARE REQUIREMENTS DOCUMENT Project: [name] Version: [0.1] Date: [date] Owner: [name, role] Approver: [name, role] 1. DOCUMENT CONTROL Change log: [version] [date] [what changed and why] 2. BACKGROUND AND GOALS Problem: [in the words of the people who have it] Why now: [what has changed or what it costs] Goals and measures: [goal] -> [how it will be measured] Not goals: [what this project will not try to do] 3. USERS AND ROLES [Role] | needs to: [...] | may see and change: [...] 4. SCOPE In scope: [...] Out of scope: [...] Later: [...] 5. FUNCTIONAL REQUIREMENTS FR-01 (Must/Should/Could) As a [role], I want [action], so that [outcome]. Acceptance criteria: - Given [situation], when [action], then [result]. 6. DATA Main records and how they relate: [...] Personal / special category data: [...] Retention and deletion: [...] Data to migrate: [source, format, volume, quality] 7. INTEGRATIONS [System] | direction: in/out/both | frequency: [...] | API confirmed: yes/no If unavailable: [...] 8. NON-FUNCTIONAL REQUIREMENTS Performance: [...] Availability: [...] Security: [...] Accessibility standard: [e.g. WCAG 2.2 level AA] Devices and browsers: [...] Hosting region, backups and recovery: [...] 9. CONSTRAINTS, ASSUMPTIONS AND DEPENDENCIES Budget range: [...] Deadline and reason: [...] Must use / must not use: [...] Assumptions: [...] 10. RISKS AND OPEN QUESTIONS Q-01: [question] | owner: [...] | answer by: [date] | affects: [IDs] 11. ACCEPTANCE AND SIGN-OFF Testers: [...] Environment: staging Test window: [...] Blocks sign-off: [...] Signed off by: [...]
"Patients can cancel and rebook" is two requirements. Split them, so each can be estimated, built and tested on its own.
"Patients are reminded the day before" leaves the team free to suggest the best channel. "Send an SMS via provider X" fixes a choice before anyone has compared options.
"Fast" and "user-friendly" cannot be tested. "Usable within three seconds on a mid-range phone over 4G" can.
Decide what each word means at the top of the document and stick to it, so priorities survive the first budget conversation.
Silence is read differently by every reader. An explicit out-of-scope list is the cheapest protection against disputes about the invoice.
An honest "not known yet" with an owner and a date is far more useful to an estimator than a confident guess.
Send the same document to every company you are considering and ask each one to list its assumptions and exclusions against your section numbers. Our guide to how to choose a software development company covers the questions to ask and the contract clauses to check, and the MVP cost calculator gives an indicative GBP range before you speak to anyone.
If a supplier will handle personal data on your behalf, plan the data processing contract alongside the requirements. The ICO says that every time a controller uses a processor to process personal data there must be a written contract (ICO, accessed 18 October 2026).
A software requirements document (SRD or SRS) describes what the system must do and how well, in enough detail to estimate, build and test it. A product requirements document (PRD) is usually written by a product team and focuses more on the user problem, goals and priorities, with less technical detail. A statement of work (SOW) is a contractual document that describes the work a supplier will deliver, the price and the timeline, and often refers to a requirements document for the detail.
As long as it needs to be for someone else to estimate and test the system, and no longer. For an MVP or a single internal tool, a few pages covering every section of this template is often enough. Larger systems with many roles, integrations or regulatory requirements need more detail, usually split by module. A short document that answers every section is more useful than a long one that skips scope, data or acceptance.
The business should own it, because it records business decisions: who the users are, what is in scope and what counts as done. In practice it is often drafted by a product owner, an operations lead or a founder, then refined with the development team during discovery, who add technical detail and flag gaps. Whoever writes it, one named person should own it and approve changes.
They need the decisions in it, even if not as one long document. Agile teams usually keep requirements as a prioritised backlog of user stories with acceptance criteria, which is what section 5 of this template produces. The other sections, such as scope, data, integrations and non-functional requirements, still need writing down somewhere, because they shape the architecture and the estimate before the first sprint starts.
It can help you draft structure, rephrase requirements as user stories and spot missing sections, but the decisions have to come from you: who the users are, what is out of scope and what counts as done. Check every drafted requirement against how your business actually works, and do not paste confidential or personal data into a tool whose terms allow that data to be used for training.
Send it to us. We will point out the gaps that would change an estimate, whether or not you build with us.