Quick answer: A software requirements document describes what a system must do and the conditions it must work under, so that everyone, from the business owner to the developers and testers, shares the same picture before code is written. A useful one covers the purpose and scope, the users, the functional requirements written as clear, testable statements or user stories, non-functional requirements such as performance and security, integrations, data, constraints and assumptions, and how the result will be accepted. Keep it specific, prioritised and readable by non-technical people.
Why a requirements document matters
Most failed or over-budget software projects do not fail because the developers could not code. They fail because people had different ideas about what was being built. The client imagined one thing, the developer understood another, and the gap only appeared when the software was nearly finished.
A software requirements document, sometimes called an SRS (software requirements specification), closes that gap early. It helps you:
- Get accurate quotes, because suppliers price the same scope
- Spot conflicts and missing pieces before they become expensive
- Give developers and testers a reference to check against
- Decide what to build first and what can wait
- Settle disagreements with a document rather than memory
If you are still at the earlier stage of describing a website rather than an application, our guide to writing a website brief may be a better starting point.
Brief, requirements document or specification?
These terms get mixed up. A rough way to tell them apart:
- Brief: goals, audience, budget and the general idea. Short and high level.
- Requirements document: what the system must do and how well, without dictating how it is built.
- Technical specification or design: how the developers will build it, including architecture, database design and technology choices.
A business owner can usually write most of a requirements document with help. The technical specification is the development team’s job.
Before you write: gather the inputs
- Talk to the people who will use the system. Staff, customers, managers. Ask what they do today, what slows them down and what would help.
- Map the current process. Draw the steps, handoffs, spreadsheets and emails involved. Many requirements come from pain points in this map.
- Collect examples. Forms, reports, invoices, screenshots of tools you like or dislike.
- Define success. What will be different, and how will you measure it? Hours saved, errors reduced, faster responses.
What to include
1. Purpose and background
Explain in a few paragraphs why the project exists, what problem it solves and what the business gains. Readers who understand the purpose make better decisions when details are unclear.
2. Scope
List what is in scope and, just as important, what is out of scope. “The first release will not include a mobile app” or “Payroll stays in the existing system” prevents assumptions later.
3. Users and roles
Describe each type of user: customers, office staff, managers, administrators. For each, note what they need to do and what they should not be able to see or change. Simple user personas can help make these groups real.
4. Functional requirements
This is the heart of the document. Functional requirements describe what the system does. Two common formats work well:
Numbered “shall” statements:
- FR-12: The system shall allow office staff to create a quote from a customer record.
- FR-13: The system shall email the customer a PDF of the quote when it is marked as sent.
User stories with acceptance criteria:
As a field technician, I want to see today’s jobs on my phone so that I know where to go next.
Acceptance criteria: jobs are listed in time order; each job shows address, customer name and phone; tapping the address opens maps.
User stories suit teams working in short iterations. Numbered statements suit fixed-scope contracts. Either is fine, as long as each requirement is clear and testable. Our comparison of agile vs waterfall explains how the approach affects the format.
5. Non-functional requirements
These describe how well the system must work:
- Performance: for example, search results should appear within two seconds for typical queries.
- Availability: when the system must be online and how quickly it must recover from failure.
- Security: login rules, password policies, data encryption, audit logs.
- Usability and accessibility: devices and browsers supported, accessibility standards.
- Scalability: expected number of users and records now and in a few years.
- Compliance: data protection rules that apply to your data.
6. Integrations
List every system the software must connect to: accounting, CRM, payment gateway, email, existing databases. For each, note what data moves, in which direction and how often. Integrations are often where effort is underestimated.
7. Data
What data will the system store? Where does existing data come from, and does it need to be imported? Who owns it, and how long must it be kept?
8. Reports
List the reports and dashboards people need, with the questions each one answers. Example layouts help.
9. Constraints and assumptions
Budget limits, deadlines, required hosting, technology the business already uses, and anything you are assuming to be true. Writing down assumptions lets others challenge them.
10. Acceptance criteria and sign-off
Describe how you will decide the software is finished: who tests it, against which requirements, and what counts as a pass.
11. Glossary
Define business terms and abbreviations. Words like “job”, “order” or “account” can mean different things to different teams.
How to write good requirements
A good requirement is:
- Clear: one meaning only. Avoid words like “fast”, “easy” or “user-friendly” without a measure.
- Testable: a tester can check whether it is met.
- Necessary: it supports a real business need.
- Feasible: possible within your budget and constraints.
- Prioritised: marked as must have, should have, could have or will not have this time. This MoSCoW method helps when budgets get tight.
Compare these:
- Weak: “The system should be easy to use for staff.”
- Better: “A new staff member should be able to create and send a quote without help after a 30 minute training session.”
Describe what is needed, not how to build it. “Customers can pay by card online” is a requirement. “Use a particular payment plugin” is a design decision, unless there is a business reason, which you should state.
Keep it readable
- Use headings and numbered requirements so people can refer to them
- Add simple diagrams for workflows and screens
- Keep sentences short
- Put long examples in an appendix
- Use a shared document with version history so changes are tracked
A document nobody reads is worse than no document, because it gives false confidence.
Common mistakes
- Too vague: “manage customers” without saying what managing involves.
- Too detailed too early: designing every screen before the core workflow is agreed.
- Missing non-functional requirements: fine features, but slow or insecure.
- No priorities: everything marked essential, so nothing can be cut.
- Ignoring existing data: the import from old spreadsheets turns into a project of its own.
- Never updating it: requirements change. Record changes and their effect on cost and timeline.
Using the document with suppliers
A clear requirements document makes quotes comparable and helps you choose the right pricing model. Our guide to fixed price vs time and materials explains how scope certainty affects that choice. The document can also be referenced in your web development contract as the agreed scope.
If budget is limited, use the priorities to define a first release that delivers the core value, then build the rest in phases. That is the idea behind an MVP.
FAQ
How long should a requirements document be?
As long as it needs to be. A small internal tool might need ten pages. A complex platform may need many more. Clarity matters more than length.
Should a developer write it for me?
A good development partner can run discovery workshops and write it with you. You still need to supply the business knowledge and approve it.
Can requirements change after signing off?
Yes. Use a simple change process: describe the change, estimate its effect on cost and time, and approve it before work starts.
Start with clarity
A well-written software requirements document saves money, time and arguments. It turns ideas into something everyone can agree on and test against. If you are planning a custom application and want help shaping requirements into a workable plan, see our custom development services.
