A software requirements document explains what your software must do, for whom, and how you will know it works, without dictating how it is coded. Write it in plain language: the problem, the users, the features as user stories with acceptance criteria, the data, the integrations and the constraints. A good one lets different developers quote the same thing.
You do not need to be technical to write one. You need to be specific. The template further down gives you a structure you can copy and fill in.
Why bother writing a requirements document?
A requirements document turns ideas in your head into something a team can price, build and test against. Without it, every supplier quotes their own interpretation, and you find the gaps after paying for them.
It helps you:
- Compare quotes fairly, because everyone is pricing the same scope.
- Control scope, since anything not in the document is clearly a change.
- Test the result, using acceptance criteria you agreed in advance.
- Keep your team aligned, so the operations manager and the owner want the same thing.
It does not need to be long. A clear ten-page document beats a vague fifty-page one.
What sections should it include?
Eight sections cover almost every business software project. The table explains what each one is for and gives a short example.
| Section | What to write | Short example |
|---|---|---|
| 1. Background and goal | The problem, who has it, and what success looks like | "Job scheduling lives in three spreadsheets; we want one system and same-day job updates" |
| 2. Users and roles | Each type of user and what they may see and do | Admin, dispatcher, technician, customer |
| 3. Features as user stories | What each user needs to do and why | "As a technician, I want to see today's jobs on my phone so I know where to go" |
| 4. Acceptance criteria | How you will check each story works | "Jobs assigned before 8am appear on the technician's list by 8am" |
| 5. Data | What information is stored, imported and exported | Customer records, job history, photos, invoices |
| 6. Integrations | Systems the software must connect to and what passes between them | Accounting software for invoices, SMS for reminders |
| 7. Non-functional needs | Speed, security, privacy, hosting, devices, accessibility | Works on mid-range Android phones; data hosted in Australia |
| 8. Out of scope and priorities | What is deliberately excluded and what matters most | No customer app in phase one; reporting is a should-have |
How do you write good user stories?
A user story names the user, the action and the reason in one sentence: "As a [user], I want to [action] so that [benefit]." The reason is the part people skip, and it is the part that helps developers suggest simpler solutions.
Good examples:
- As a dispatcher, I want to drag a job onto a technician's calendar so that I can rebalance the day when someone calls in sick.
- As a customer, I want to reschedule my booking online so that I do not have to phone during work hours.
- As an owner, I want to see this week's completed jobs by technician so that I can spot who is overloaded.
Weak examples, and why:
- "The system should be user-friendly." No user, no action, nothing to test.
- "Add a dashboard." Dashboard of what, for whom, to make which decision?
- "Integrate with WhatsApp." To send what, triggered by what, to whom?
If you cannot test a requirement, it is a wish, not a requirement. Rewrite it until you can.
What are acceptance criteria and how detailed should they be?
Acceptance criteria are the specific checks that prove a user story is done. They turn "it works" into something both sides can agree on.
A simple format is Given / When / Then:
- Given a customer has a booking more than 24 hours away,
- When they choose a new available slot,
- Then the booking moves, the old slot is freed, and both the customer and the assigned staff member get a confirmation.
Add criteria for the awkward cases too: What if the slot is less than 24 hours away? What if no slots are free? These edge cases are where estimates go wrong when they are missing. Two to five criteria per story is usually enough.
How do you prioritise requirements?
Label every story must-have, should-have, could-have or won't-have-this-time (the MoSCoW method). It forces honest choices and protects the first release.
- Must-have: without it, the software cannot replace the current process.
- Should-have: important, but there is a workaround for a few months.
- Could-have: nice, low-impact, first to go if time runs short.
- Won't-have (this time): recorded so it is not forgotten, but explicitly excluded.
A useful test: if more than about half your stories are must-haves, you have not prioritised yet.
What does the free requirements template look like?
Copy this outline into a document and fill in each heading. Delete anything that does not apply; keep the headings that do.
SOFTWARE REQUIREMENTS DOCUMENT Project name: Version / date: Owner (decision-maker): 1. BACKGROUND AND GOAL - The problem today (in 3–5 sentences): - Who is affected: - What success looks like in 6 months (measurable if possible): 2. USERS AND ROLES Role name | What they need to do | What they must NOT see or do ... 3. USER STORIES (grouped by role) ID | As a... | I want to... | So that... | Priority (M/S/C/W) US-01 | US-02 | 4. ACCEPTANCE CRITERIA (per story) US-01: - Given... When... Then... - Edge case: 5. DATA - Records to store (e.g. customers, orders, jobs): - Existing data to import, its format and rough volume: - Exports or reports needed: - Retention and deletion rules: 6. INTEGRATIONS System | Direction (in/out/both) | What data | Trigger | Access available? (Y/N) 7. NON-FUNCTIONAL REQUIREMENTS - Devices and browsers: - Expected users and volume: - Security (sign-in, two-factor for admins, permissions): - Privacy and compliance (e.g. DPDP Act, Privacy Act 1988, GDPR): - Hosting location: - Accessibility: - Languages: 8. OUT OF SCOPE AND PRIORITIES - Not included in this phase: - Top three priorities if budget or time is tight: 9. CONSTRAINTS AND ASSUMPTIONS - Budget range: - Target launch date (and whether it is fixed): - Assumptions the estimate depends on: 10. OPEN QUESTIONS - Question | Who answers | By when
Section 10 matters more than it looks. Writing down what you do not know yet is honest, and it tells suppliers exactly where the risk sits.
What mistakes make requirements documents fail?
Most failed requirements documents are either too vague to price or so prescriptive they block better solutions. Aim for clear outcomes, not instructions on how to code.
Common mistakes:
- Describing screens instead of needs. "A blue button top right" constrains design; "a dispatcher can reassign a job in two clicks" describes the need.
- Copying a competitor's feature list. You inherit their priorities, not yours.
- Leaving out the edge cases. Refunds, cancellations, duplicates and missing data are where the effort hides.
- Forgetting the admin side. Someone has to manage users, fix mistakes and update settings.
- Ignoring existing data. Migration is real work and belongs in scope.
- Writing it alone. Ask people who do the job daily to review it; they will add what you missed.
Who should write it: you or the developer?
You should own the content; a developer or analyst can help structure it and fill technical gaps. The best documents come from both sides working together.
If you write a first draft using the template, a discovery phase can then test it against real constraints, check integrations and turn it into a priced plan. Our guide to the software discovery phase explains how that works, and the step-by-step development process shows where the document is used at each stage. A detailed document also makes a fixed-price contract realistic; see our comparison of fixed price, time and materials and dedicated team contracts. And if you are earlier in the journey, start with what custom software involves for a growing business.
Frequently asked questions
How long should a software requirements document be?
Long enough that two developers would price the same thing. For a small internal tool that might be a few pages; for a multi-role platform, considerably more. Clarity matters far more than length.
Do I need technical knowledge to write one?
No. Describe what users need to do and why, in plain language. Leave technology choices to the developers, but do record constraints such as hosting location, devices and compliance needs.
What is the difference between a requirements document and a scope of work?
The requirements document describes what the software must do. A scope of work, usually prepared by the supplier, adds how they will deliver it: phases, timeline, price, assumptions and responsibilities. The first feeds the second.
Can requirements change after the document is signed off?
Yes, and they usually do a little. Treat the document as the baseline: log each change, estimate its cost and impact, and decide deliberately. That keeps changes visible instead of letting scope drift.
Should I include designs or wireframes?
Simple sketches help explain complex flows, so include them if you have them. Avoid detailed visual designs at this stage; a design phase will do that properly once the requirements are agreed.
Turn your draft into a plan
If you have filled in even half of the template, you are ahead of most projects we see at the start. Send it over, rough edges and all, and we will review it with you and come back with a fixed-price quote. Examples of what we have shipped are on our work page.