Software Requirements Document Template (With Example)
By Yuliia Tytarenko · · 13 min read
A software requirements document needs eight parts: purpose and scope, goals, users, functional requirements, non-functional requirements, constraints, assumptions and open questions, and a change log. Below is a skeleton you can paste into your own editor, with one line on what belongs in each section, a short filled-in example from an invented project, and the rules that make each requirement testable. If you are writing it at the end of a discovery phase in software development, most of the inputs already exist; this template turns them into one document the team can build and test against.
What goes in a requirements document
A requirements document answers one question: what must the software do, and how will we know it does? It is not a design document or a project plan, so it does not pick a database (unless that is a fixed constraint) or set release dates. A useful one contains:
- Context: why the project exists and what is in and out of scope.
- Goals: the outcomes the software must move, with a number for each where possible.
- Users: who uses the system and what they are trying to get done.
- Requirements: what the system must do (functional), how well it must do it (non-functional) and the limits nobody on the team can change (constraints).
- Acceptance criteria: how each requirement will be checked.
- Assumptions and open questions: what you believe but have not confirmed, and what is still undecided.
- History: what changed, when and why.
The international standard behind the formal version, the software requirements specification (SRS), is ISO/IEC/IEEE 29148:2018, "Requirements engineering". You do not need it to write a good document, but it is the reference if a client or a regulated industry asks for a formal SRS.
The template, section by section
Copy the skeleton below into a document or a wiki page. The line under each heading says what to write there; replace it with your content.
# [Project name]: Software Requirements
Version: 0.1 | Status: Draft | Owner: [name] | Last updated: [date]
## 1. Purpose and scope
One paragraph: the problem, who has it, and what this software changes.
In scope: [bullet list]. Out of scope: [bullet list].
## 2. Goals and success metrics
Each goal with a metric, its current value, a target and a date.
## 3. Users and stakeholders
Each user type: role, what they need to get done, current pain points.
Each stakeholder: name, role, what they decide or approve.
## 4. Functional requirements
One row per requirement:
ID | Title | Description | Priority (Must/Should/Could/Won't)
| Status (Draft/In review/Approved) | Linked goal | Owner
| Acceptance criteria (one checkable statement per line)
## 5. Non-functional requirements
Performance, availability, security, privacy, accessibility,
offline behaviour, supported devices. Same row format, with a number.
## 6. Constraints
Limits the team cannot change: regulation, contracts, budget,
deadline, mandated technology or hosting region.
## 7. Assumptions
What you treat as true but have not confirmed. One line each.
## 8. Open questions
Question | Who answers it | Needed by [date] | Requirements affected
## 9. Glossary
Terms that mean something specific in this project.
## 10. Change log
Version | Date | Author | What changed and why
A few notes on using it:
- Keep the ID stable. Number requirements once (REQ-001, REQ-002) and never reuse a number. Tests, tickets and estimates will point at those IDs.
- Put constraints in their own section, so they are not traded away like features in a planning meeting.
- Write short rather than empty. "No accessibility requirements beyond the platform defaults, confirmed with [name]" is a decision; a blank section is a question nobody asked.
If you also need the material that feeds this document (stakeholders, problem statement, architecture notes, roadmap), the discovery phase template lists every section of the wider discovery output.
A filled-in example
The example below is from Fieldwise, an invented project: a mobile app for the field technicians of an invented company, Northline Services, which today assigns visits by phone and spreadsheet and collects results on paper. The full example, with goals, journeys, architecture decisions, a roadmap and risks, is on the example report page.
Purpose and scope (excerpt). Technicians close visits on paper and the office re-types the forms into the dispatch system. In scope: a technician app and a dispatcher board connected to the existing dispatch system. Out of scope for the first release: route optimisation.
Goals (excerpt).
| Goal | Metric | Current | Target |
|---|---|---|---|
| Reduce missed and repeated visits | Visits missed or repeated | 9% | 4% |
| Remove double entry | Office re-typing time per day | 4 h | 30 min |
| Technicians adopt the app | Visits closed in the app (pilot regions) | 0% | 90% |
Requirements (excerpt).
| ID | Requirement | Type | Priority | Status | Linked goal | Acceptance criteria |
|---|---|---|---|---|---|---|
| REQ-001 | Day list: a technician sees their assigned visits for the day, in order, with status | Functional | Must | Approved | Reduce missed and repeated visits | A visit assigned in dispatch appears in the app within one minute. Visits are ordered by planned time. |
| REQ-003 | Work without coverage: the app works for a whole day offline and synchronises when coverage returns | Non-functional | Must | In review | Technicians adopt the app | 100 visits closed offline are all delivered, none lost or duplicated. The app shows what is waiting to sync. |
| REQ-004 | Decline with a reason: a technician can decline an assigned visit and choose a reason | Functional | Should | Approved | Reduce missed and repeated visits | The dispatcher is alerted within 30 seconds. The visit returns to the board with the reason. |
| REQ-005 | Data stays in the EU: personal customer data is stored and processed only in the EU region | Constraint | Must | Approved | none | The database and backups are hosted in the EU. No personal data is sent to a service outside the EU. |
| REQ-012 | Routing suggestions: the app suggests an order for the day's visits that reduces driving | Functional | Could | Draft | none | Deferred to a later release after the pilot. |
Assumption (excerpt). A photo is at most 5 MB and a visit has at most six photos.
Open question (excerpt). Is a ticked box enough as customer confirmation, or must the signature be legally binding? This blocks REQ-007 (customer confirmation), which stays in Draft until legal answers.
Note what is missing: screen layouts, technology choices (apart from the hosting region, a client-imposed constraint) and dates. Those belong in the design, architecture and roadmap.
Writing requirements that can be tested
A requirement is finished when someone who was not in the meeting can tell whether the software meets it. That usually takes three things: one behaviour per requirement, a measurable condition, and acceptance criteria.
Weak and strong wording
| Weak | Why it fails | Testable |
|---|---|---|
| The app should be fast. | "Fast" means something different to everyone. | The day list opens in under two seconds on the reference phone with 20 visits. |
| The system must handle offline mode properly. | "Properly" cannot be checked. | 100 visits closed offline are all delivered after reconnecting, none lost or duplicated. |
| Users can manage visits. | "Manage" hides several behaviours. | Split into: view the day list, close a visit, decline a visit with a reason. |
| The app is user-friendly. | Not observable. | Closing a visit takes under two minutes in the pilot test. |
Words to search for and replace before review: fast, easy, intuitive, user-friendly, flexible, robust, properly, etc., and/or, as appropriate, support. Each one usually hides a number or a second requirement.
Acceptance criteria
Acceptance criteria are the checks that decide whether a requirement is done. Write them as short statements that are either true or false, one per line, from the user's or system's point of view. They become the basis of acceptance tests, so a tester should be able to read one and know what to try.
Two to four criteria per requirement is typical. Ten usually means several requirements; none means it is not understood yet, so move it to open questions.
MoSCoW priority
MoSCoW sorts requirements into four groups:
- Must: without it the release does not work, is not legal or is not safe.
- Should: important, but the release still works without it, perhaps with a workaround.
- Could: useful if time allows; the first to drop when the schedule is under pressure.
- Won't (this time): agreed to be out of this release. Writing it down is the point: it records a decision instead of leaving the request in limbo.
The method comes from the DSDM agile framework (background on the MoSCoW method). A common rule of thumb is that Musts should take no more than about 60% of the planned effort, so the Shoulds and Coulds act as contingency. That is a practitioner guideline, but the point holds: if everything is a Must, priority carries no information.
Non-functional requirements
Non-functional requirements describe qualities of the whole system rather than one feature. They are often left empty, and they cause late surprises because they drive architecture and hosting choices. Areas to ask about:
| Area | Question to answer | Example of a measurable answer |
|---|---|---|
| Performance | How quickly must key screens or calls respond, under what load? | Day list opens in under 2 s on a three-year-old phone |
| Availability | When must it be up, and how much downtime is acceptable? | Available 06:00-20:00 local time on working days |
| Offline and connectivity | What must work without a network? | A full day of visits can be closed offline |
| Security | Who can sign in, how, and what happens to a lost device? | Sign-in through the company directory; a lost phone can be locked remotely |
| Privacy and data location | Where may personal data be stored and processed? | Only in the EU region, backups included |
| Accessibility | Which standard or level applies? | Name the standard and level the client requires |
| Supported platforms | Which devices, browsers and versions? | Android and iOS versions in use across the fleet |
Write each answer in the same row format as functional requirements, with an ID, a priority and acceptance criteria. "Secure" is not a requirement; "a lost phone can be locked from the office" is.
Keeping the document alive
Three habits keep the document from going stale after sign-off.
Versioning. Give the document a version and a status (Draft, In review, Approved), give each requirement its own status, and log every change with its reason. When the team disagrees about what was agreed, the log settles it.
Traceability to goals. Link every requirement to the goal it serves, and check the other direction too: every goal should be served by at least one requirement. A requirement with no goal is a constraint, a quality, or scope creep worth questioning; a goal with no requirements will not be delivered. Carry the requirement IDs forward into tickets, test cases and milestones so you can answer "what breaks if we drop REQ-004?".
Change control. After approval, every change records who asked, which requirements change, what it does to the estimate and who approved it. On a small project that is a line in the change log and a message to the sponsor; what matters is that nobody edits an approved requirement silently.
Tools can take over the first draft. Discovery Phase AI drafts requirements (type, MoSCoW priority, acceptance criteria and a linked goal) from the decks, documents and transcripts you upload, for you to review before anything is saved, and gives each requirement an AI quality score.
Which format: PRD, BRD or SRS
The three names overlap, and many teams use one document for all three jobs. The difference is mostly who the document is for:
| Document | Main reader | Focus | When it is the right shape |
|---|---|---|---|
| BRD (business requirements document) | Sponsors, business owners | Business problem, objectives, scope, benefits | Getting a project approved and funded, before a solution is chosen |
| PRD (product requirements document) | Product, design and engineering | What the product does for its users, features, user flows, release scope | A product team building and iterating on its own product |
| SRS (software requirements specification) | Engineering, testing, the client or a supplier | Precise functional and non-functional requirements, acceptance criteria, constraints | A contract or handover between parties, regulated work, or anything that will be formally tested against the document |
The template above is an SRS with a short business section on top, which suits most client projects: the sponsor reads sections 1 and 2, the delivery team works from sections 4 to 8. An internal product team can drop the formality and keep goals, requirements and acceptance criteria. For a tender or a regulated domain, check whether the client expects the ISO/IEC/IEEE 29148 structure.
FAQ
How long should a software requirements document be?
As long as the requirements, no longer. The Fieldwise example has 12 requirements; a larger system can have hundreds. What matters is that each one is testable and traceable to a goal or a constraint.
Should user stories replace the requirements document?
They can sit inside it. A user story ("As a technician, I want to decline a visit with a reason so that dispatch can reassign it") is one way to phrase a functional requirement, and its acceptance criteria are the same. What stories often miss are non-functional requirements and constraints, so keep sections 5 and 6 even if the functional section is a list of stories.
When is a requirements document finished?
When every Must and Should has acceptance criteria, every open question has an owner and a date, and the sponsor has approved the version you will estimate against. After that it is maintained, not finished. Before signing off, the discovery phase checklist has a short list of checks for the requirements section.