CentriWebA software requirements document is a plain-language description of who will use the software, what each person needs to do with it, the rules it must follow and how you will know it works. Written well, it is three to six pages that let a developer quote a fixed price or a tight range without guessing, and let you compare two quotes on the same footing.
What a software requirements document is for
It does four jobs. It lets developers estimate from the same information, so the quotes you get back can be compared. It shows you the gaps in your own thinking while changing them is still cheap. It becomes the yardstick for testing the finished work. And it gives both sides something to point at when a change request arrives mid-project.
It is not a design, and it is not a technical plan. You are describing the business problem and the behaviour you need. The developer chooses how to build it.
The ten sections to include
You do not need a template with fifty headings. These ten cover what a developer needs to quote, and each can be a few lines.
- The problem and why now. What is going wrong today, who feels it, and what it costs you in time, money or missed work. Two or three sentences.
- Who uses it. List every type of person: staff, managers, customers, outside suppliers. Note roughly how many of each.
- What each person needs to do. One line per task, such as “an office admin enters a new job and assigns it to a crew”. This is the core of the document.
- The rules. Calculations, approvals, limits and exceptions. “Anything over a set amount needs a second person to approve it” is a rule. Write down the set amount.
- The data. What gets stored, where it comes from today, and what already exists that must be moved over.
- Connections. Other systems it must read from or write to, such as accounting software, a CRM, a payment provider or a calendar.
- Outputs. Reports, emails, texts, invoices and exports, and who receives each one.
- What is not included. Features you have thought of and are deliberately leaving for later. This line protects the budget more than any other.
- Limits and conditions. Devices people will use, countries it will run in, privacy rules that apply to the data, who must be able to see what, and any hosting requirement.
- What done looks like. The tests you will run on the finished work, written before it is built.
Worked example: a builder approving variations
Take a small residential builder who approves changes to a contract (called variations) by email. Customers sometimes dispute them months later because nobody can find the approval. Here is how a few lines of a requirements document might read. The details are invented for the example.
- Problem: variations are approved by email, are sometimes lost, and are invoiced late because the office does not know they were approved.
- Users: site supervisors (about five), the office admin (one), the owner (one), customers (one per active job).
- Task: a supervisor records a variation on a phone, with a description, a photo and a price. The customer receives a link to approve or decline it. The approval is stored against the job with the time and the customer’s name.
- Rule: a variation cannot be invoiced until the customer has approved it. If the price is above an agreed limit, the owner approves before it goes to the customer.
- Connection: approved variations are passed to the accounting software as invoice lines.
- Out of scope for version one: progress claims, supplier orders, and customer logins beyond the approval link.
- Done means: a supervisor can record a variation on site with no signal and send it once back in range, the customer can approve it from a phone, and the office can see every variation for a job and whether it is invoiced.
Notice how much a developer can already see: the users, the device, the awkward case with no signal, the rule that drives the invoicing, and the edge of the project. A builder reading this can also see exactly what they are not getting.
Write requirements a developer can test
A requirement is useful when two people could look at the finished software and agree whether it is met. Vague words are the problem. “Simple”, “fast”, “flexible”, “intuitive” and “user friendly” all mean different things to different people.
| Vague | Testable |
|---|---|
| The system should be fast. | The job list opens in under three seconds with 500 jobs loaded, on an average office computer. |
| Staff can manage customers easily. | An admin can add a customer, edit their details and see their past jobs from one screen. |
| It should be secure. | Staff see only their own region’s jobs. Only the owner can see pricing and margins. |
| It should integrate with our accounting software. | When a variation is approved, it appears as a draft invoice line in the accounting software within five minutes. |
If you cannot make a requirement testable, that is a sign you have not made the decision yet. Make the decision, or mark it as an open question and say who will answer it and by when.
Sort what you need into three piles
Once the tasks are listed, mark each one:
- Must have: the business cannot use the software without it.
- Should have: it matters, but there is a workaround for a while.
- Later: good ideas that belong in version two.
Be strict with the first pile. A good test is to ask whether you would still launch without it. If the answer is yes, it is not a must. A smaller first release also gets real people using the software sooner, which is when you find out what you actually needed. Our guide to what a first version costs and how long it takes goes through that trade.
Mistakes that make quotes drift
- Describing the solution instead of the problem. “A dashboard with six charts” locks in a design before anyone knows whether a chart is the right answer. Describe what the person needs to know and when.
- Leaving out the exceptions. Most of the cost in custom software sits in the awkward cases: a part-paid invoice, a customer with two addresses, a job that changes hands. Ask the people who do the work what goes wrong, not just what normally happens.
- No sample data. A real example of every form, report and spreadsheet in use today tells a developer more than a page of description. Remove private details first.
- Nobody owns decisions. Name one person who answers questions and signs off. A document written by a committee tends to contradict itself.
- Skipping the people who do the work. The owner knows what they want reported. The admin knows what is actually typed in each day. You need both.
- Mixing present needs with a wish list. Keep the wish list in a separate section so it does not get priced as a requirement.
What to do with the finished document
Read it aloud to someone who does the job and ask them to find what is missing. Then send it to two or three developers and ask each to reply with three things: a price or range, the assumptions behind it, and the questions they would want answered. The quality of those questions tells you more about a developer than the price does. For how to read the price itself, see our guide to what custom software costs.
Also ask who will own the finished code and the data, and put the answer in writing. Our guide to who owns the code explains what to look for.
Most projects that go badly were unclear at this stage, so it pays to get it right: see why software projects fail for the patterns. If you would rather not write the document alone, CentriWeb builds custom software such as portals, web apps and internal tools, and a 30 minute call is a reasonable place to turn a rough list into a first draft of this document, whether or not we end up building it.