Decide how much detail your project needs
There is no single right size for a requirements document. Too little, and the team builds on guesses. Too much, and months pass before anyone learns anything. Let the situation set the depth.
| Situation | Right depth | Why |
|---|---|---|
| An early idea you want to explore | A one-page brief, followed by a discovery phase | You do not yet know enough to specify, and pretending otherwise wastes effort |
| Replacing an internal tool or spreadsheets | A full document for the core workflows, lighter for the rest | The process exists and can be described accurately |
| Work under contract or regulation | A formal specification with identifiers and sign-off | Requirements must be traceable to tests and approvals |
| A product that will keep changing | A short stable core and a living backlog | Detail written far ahead will be out of date before it is built |
A software requirements document template
Copy the outline and adapt it. Sections 4 and 7 take the most care, and the examples later in this guide show how to write them.
Software requirements document
Template1. Purpose
The problem the system solves, for whom, and the outcome expected
2. Users and roles
Each role, what it is responsible for and what it may see and do
3. Scope
Processes and features included in this release
What is explicitly out of scope
4. Functional requirements
One requirement per line: identifier, statement, priority, acceptance criteria
Grouped by workflow, in the order the work happens
5. Data
The main records, their important fields and who owns each
Data to be migrated, and from where
Retention and deletion rules
6. Integrations
Each external system, what is exchanged, in which direction and how often
7. Quality requirements
Performance, availability, security, privacy, accessibility and compatibility
8. Constraints and assumptions
Technology, budget, dates, policies and anything assumed to be true
9. Acceptance and sign-off
How the finished system will be tested and who approves it
10. Glossary and open questions
Terms with one agreed meaning each
Decisions still to be made, and who will make them
How to write a requirement that can be tested
A requirement is useful when two people reading it would build the same thing and a third could check it. The test is simple. Ask how you would prove it is done. If you cannot answer, rewrite it.
| Weak requirement | Why it fails | Testable version |
|---|---|---|
| The system should be user friendly | Nobody can prove it true or false | A new warehouse operator can record a goods receipt without training, using the on-screen guidance only |
| Managers can approve orders | Which managers, which orders, and what happens next are missing | An order above the approval limit is held until a user with the manager role for that region approves or rejects it, with a reason |
| The system must be fast | Fast has no agreed meaning | The order list shows its first results within the response time agreed in section 7, measured on the reference laptop and connection |
| Reports can be exported | The format and the content are not stated | Any report can be exported as a spreadsheet file containing the same rows and columns as the screen, with the filters applied |
| The system integrates with accounting | It names a system and no behavior | When an invoice is approved, it is created in the accounting system within the agreed interval, and a failure is shown to the finance role |
Use one statement per requirement. If a sentence contains and, it is often two requirements, and one of them will be forgotten in testing.
Example of a functional requirement
Order approval, written in full
From an invented order management system. The identifier lets designs, tests and change requests refer to the same line.
- IdentifierORD-012
- StatementAn order whose total is above the approval limit of the customer account must be approved by a regional manager before it is released to the warehouse.
- PriorityMust
- RulesThe limit is set per customer account. A manager cannot approve an order they created. A rejected order returns to its author with the reason.
- Acceptance criteriaAn order under the limit goes straight to the warehouse. An order over the limit appears in the approval queue of the right region and nowhere else. Approval and rejection are recorded with user, date and reason. The author is notified of the outcome.
- Open questionWho approves when the regional manager is away?
Notice the open question. Writing the requirement properly exposed a decision the business had not made. That is the document doing its job.
Examples of quality requirements
Quality requirements, also called non-functional requirements, describe how well the system must do its work. They are the ones most often left out, and the most expensive to add after the fact. The values in square brackets are yours to set.
| Quality | The question it answers | Example requirement |
|---|---|---|
| Performance | How quickly must it respond, under what load? | With [number] users working at once, a search returns within [time] on the reference device |
| Availability | When must it be usable, and how long may it be down? | The system is available during business hours in every region served, with maintenance outside them |
| Security | Who may access what, and how is that enforced? | Every user signs in with company single sign-on, and access to customer records is limited by role |
| Privacy | Which personal data is held, and under which rules? | Personal data is stored in [region] and can be exported or deleted on request |
| Accessibility | Who must be able to use it? | All screens meet the accessibility standard named in the contract |
| Compatibility | Which browsers, devices and systems? | The current and previous versions of the major browsers, on laptops and tablets |
| Audit | What must be traceable afterwards? | Every change to an order records the user, the time and the old and new values |
| Recovery | How much data may be lost, and how fast must service return? | Backups allow recovery to within [time] of a failure |
Review checklist
Before the document is signed off
0 of 10 checkedCommon mistakes
- Describing the current system screen by screen, and so rebuilding its problems
- Writing requirements nobody can test, such as intuitive or flexible
- Specifying the solution, for example a dropdown, when the need is a choice from a list
- Leaving out exceptions, such as returns, cancellations, corrections and absent approvers
- Forgetting data migration until the week of launch
- Treating sign-off as the end of thinking, when new facts should still be able to change the document
What to do next
Start with sections 1 to 3 and the core workflow in section 4. That is enough to begin a serious conversation with a development partner, and how to choose a custom software development partner covers that step. If the system replaces spreadsheets, how to replace business spreadsheets with software explains how to map what they do first.
When there is no time to write the document inside your team, a product discovery workshop produces it with you. Our custom software development page explains how we build from it. You can also send us a draft and we will mark what a team would need clarified.
Common questions
What is the difference between an SRS, a PRD and a BRD?
A business requirements document states what the business needs and why. A product requirements document describes what the product should do for its users. A software requirements specification adds the detailed functional and quality requirements a team builds and tests against. Small projects often combine all three in one document, which is fine as long as each level is present.
Do agile teams still need a requirements document?
Yes, in a lighter form. Agile work replaces a large specification written up front with a stable statement of goals, scope, constraints and quality requirements, plus a backlog that is detailed just before each piece is built. What agile removes is false precision, not the need to write things down.
How long should a software requirements document be?
As long as the risk requires. A focused internal tool may need ten to twenty pages. A system under regulation needs more. Length is a poor measure. A better one is whether an engineer who has never met you could estimate the work from it.
Who should sign off the requirements?
The person accountable for the business result, the person who will own the system day to day, and the technical lead who must build it. Each is confirming something different, namely that it is worth doing, that it describes the real work and that it can be built.
Can requirements change after sign-off?
They can and they will. Sign-off sets a baseline, so that every later change is visible, priced and agreed instead of slipping in unnoticed. A project where requirements never change is usually one where nobody is learning anything.
