✦ Buying, cost and process
How to write a software requirements specification (with a template)
A software requirements specification is a written document describing what a system must do - its features, users, data, and the point at which each piece of work is considered done. It's the single most useful document you can bring to a first meeting with a developer, and this post is the template itself.
Haystak · 11 August 2026 · Updated 11 August 2026 · 8 min read
A software requirements specification, usually shortened to SRS, is a written document that says exactly what a piece of software needs to do, for whom, and how you'll know when it's done. It sits between your business problem and a developer's quote - the more precisely it's written, the more accurately the quote will match what actually gets delivered.
You don't need special software or training to write one. What follows is a working template, section by section, that you can fill in for your own project - this post is the template, not a description of one.
Why a requirements specification matters before you get quotes
Two developers quoting against a vague verbal brief will price two different projects and both will believe they're right. A written specification forces the ambiguity out before money changes hands, and it gives you something to hold a supplier to later if the delivered system doesn't match what was agreed.
It also protects you from scope creep working the other way - without a written baseline, it's hard to tell whether a change you're asking for is a genuine addition to scope or something that should have been included from the start.
The template: sections your specification should cover
Not every project needs every section in full detail - a small internal tool doesn't need the depth of a system handling regulated data - but this order covers what a supplier needs to quote and build accurately.
| Section | What goes in it | Typical length |
|---|---|---|
| 1. Purpose and background | Why this system is needed, what problem it solves, what exists today | Half a page |
| 2. Scope | What the system will and won't do - the boundary matters as much as the content | Half a page |
| 3. Users and roles | Who uses the system, what each role can see and do | One page |
| 4. Functional requirements | Each feature, described as a specific, testable statement | Bulk of the document |
| 5. Data requirements | What information is stored, where it comes from, how long it's kept | One to two pages |
| 6. Integrations | Other systems this must talk to, and what data moves each way | Half a page to a page |
| 7. Non-functional requirements | Performance, availability, number of users, accessibility, security | One page |
| 8. Acceptance criteria | The specific test that proves each requirement has been met | Alongside each requirement |
| 9. Out of scope | Explicitly what this project will not cover | A short list |
| 10. Assumptions and constraints | Budget ceiling, deadline, existing tech that must be used | Half a page |
How to write a good functional requirement
The functional requirements section is where most specifications fall down, usually because requirements are written as vague intentions rather than testable statements. Compare the two styles below.
- Weak: "The system should let staff manage orders easily."
- Better: "A sales user can create an order with a customer, at least one line item, and a delivery date. The system rejects submission if any of these fields are missing, and displays which field is missing."
- Weak: "The system should be fast."
- Better: "The order list screen loads within two seconds with up to 5,000 orders on screen."
The pattern is: who does what, under what condition, with what result. If a developer could build two different things from your sentence, it needs another pass.
How detailed should acceptance criteria be?
Acceptance criteria are what turns a requirement into something that can be tested and signed off, rather than argued about at the end of the project. Each functional requirement should have at least one, written as a condition that's either true or false - no room for 'it depends'.
- 01Write it from the perspective of someone testing, not someone coding.
- 02State the exact input and the exact expected outcome.
- 03Include the failure case, not just the happy path - what should happen if the input is wrong?
- 04Avoid subjective words like 'user-friendly' or 'intuitive' - replace them with something measurable or drop them.
Does the specification need to be finished before you get a quote?
No, and expecting it to be complete before talking to anyone is a common mistake. A first draft that's 70% complete, with clear gaps flagged, is usually enough to start a proper discovery conversation with a supplier. The specification typically firms up during that stage rather than arriving finished.
What matters more than completeness at this stage is honesty about the gaps - writing "we haven't decided how returns are handled yet" is far more useful to a supplier than guessing and hiding the uncertainty.
What happens to the specification once the project starts?
A good specification becomes a living reference during the build - the thing both sides point to when there's a disagreement about whether something is in scope. It's also the natural attachment to your software development contract, which should reference it directly rather than describing scope only in prose.
If requirements change during the build - and on a bespoke project, some usually do - the specification should be updated through a formal change process rather than silently, so both sides keep a shared, accurate picture of what's being built.
If you'd rather talk through a first draft than write the whole thing alone, get in touch and we'll help you turn it into something a developer can quote against properly. And if you want to see how this fits into a full project, our how we work page covers the stages either side of it.
✦ Where this fits
More on this from us: how we run a project.