On this page
- 01A software requirements specification template without sixty pages
- 02Specification or functional design: the difference
- 03The filled-in example: a planning board for 14 trucks
- 04Ownership, data and contracts across borders
- 05An RFP template for software development
- 06Which template or route fits your question
- 07Mistakes in a specification
- 08Starting your specification this week
A software requirements specification says, in plain words, what you want built: which problem the software solves, who uses it, what it must do and how you will know it is done. This software requirements specification template gives you one in ten parts, in Word and Excel, with a priority per requirement and a filled-in example: a planning board for a haulage company. Free, no email address needed.
Written well, the specification does three jobs. It forces you to choose what really matters. It lets a developer quote a fixed price instead of an estimate in hours. And at delivery it becomes the bar: when every Must requirement works, the project is done. That matters most when the team building it sits in another country, as it does when you hire a nearshore software development partner. With the specification done, our software development contract template gives you the clauses to sign it under.
A software requirements specification template without sixty pages
The formal standard for this document is ISO/IEC/IEEE 29148, which replaced the old IEEE 830. It is thorough and long, written for large programmes with a team of analysts. A company with 20 or 200 people needs something a manager can write in a week and a developer can price in a day. This template keeps what a developer needs to quote a fixed price: the problem, the people, the requirements with a priority, the data, the integrations, the rules, what is out, the timing and the test that says it is done.
| Part | The question | In the example |
|---|---|---|
| 1. Why | which problem, what it costs | morning planning takes 90 minutes |
| 2. Who | which roles, how many people | 2 planners, 19 drivers, owner, accountant |
| 3. What | requirements with a priority | 7 requirements, 3 of them Must |
| 4. Screens | what you picture | week board, job detail, driver app, admin |
| 5. Data | what lives where, who changes it | a spreadsheet with Staff and Fleet tabs |
| 6. Integrations | which software it talks to | a monthly export for the accountant |
| 7. Rules and ownership | who sees what, who owns the code | a driver sees only his own jobs |
| 8. Out of scope | what is left out on purpose | no payroll, invoicing or route map |
| 9. Timing and budget | when live, who decides | live before 1 March |
| 10. Done | the test | one week next to the spreadsheet |
Start with part 1, not with the screens. A specification that opens with a dashboard sketch forgets why you build, and then every screen looks equally important.
Specification or functional design: the difference
Buying software produces a stack of documents. They look alike but answer different questions, and different people write them.
| Document | Written by | What it says | When |
|---|---|---|---|
| Requirements specification | you | what the software must do, and why | before you ask for prices |
| Functional design | the developer, with you | every requirement worked out in screens and rules | after approval, before the build |
| Technical design | the developer | how: architecture, database, hosting | during the build |
| Quote | the developer | what is delivered, price, timing | after the specification |
| Contract | both | ownership, warranty, maintenance, data protection | before the start |
The specification is the only one you write, and the only one free of technical terms. Skip it and the developer guesses; a developer who guesses adds a margin for what he does not know. When the quote arrives, lay it next to your specification: every Must should come back in it. Once the template is filled in, the software development cost calculator gives a first range for it.
How to write the specification
- Start with the problemWhat does it cost today, in hours or mistakes? A specification that starts with screens forgets why you build.
- Write requirements as sentencesAs a planner I want to drag a job to another driver, so that I do not plan mistakes. The developer learns who uses it and why.
- Give every requirement a priorityMust, should, could or not now. Only the musts go into the first version.
- Say what is out of scopePayroll, invoicing, an integration that can wait. What you exclude does not come back as a discussion on the invoice.
- Write the test firstHow will you see it works? With the real data of one week, tested by the people who use it every day.
The filled-in example: a planning board for 14 trucks
The example is a fictional haulage company with 14 trucks and 19 drivers. Planning lives in one spreadsheet that one person keeps, changes go through WhatsApp and phone calls, and every morning the planner needs an hour and a half to get the day right. Now and then a driver goes to a job that was already cancelled.
The goal fits in one sentence: a planning board everyone sees live, with every change on the driver's phone at once. Success when morning planning drops under half an hour. Then come the requirements, each as a sentence with a role, a wish and a reason.
| ID | Requirement, short | Priority |
|---|---|---|
| R1 | the week as a board, drivers as rows | Must |
| R2 | drag a job and see a conflict | Must |
| R3 | tomorrow's jobs on the phone at 6 pm | Must |
| R4 | report a problem with a photo | Should |
| R5 | the week plan as a PDF | Should |
| R6 | monthly export per customer | Could |
| R7 | the trucks' GPS on the board | Not now |
Why is GPS on Not now? Because the board works without it, and a telematics integration would double the price and the lead time of the first version. Writing it down tells the developer you thought of it, and nobody argues about it later.
We did not pick that example at random. For a haulage company in Belgium we built a platform with a planning board, a driver app in three languages and fuel management; see DA Logistics. A second haulier runs on the same core with its own fuel model: see Zuco Logistics. If your case is a transport business, start at transport software.
Ready to send to a developer?
- Part 1 says in one sentence what the problem costs and how you will see it is solved
- Every role is in it, with the number of people
- Every requirement is a sentence with a role, a wish and a reason
- At most half of the requirements are Must
- You know where every piece of data lives today and who changes it
- What is out of scope is written down
- Ownership of the code and a data processing agreement are asked for
- The test of part 10 is written, with real data
Ownership, data and contracts across borders
Hiring a developer in another EU country is normal, and Belgium shares a time zone with most of your neighbours. Three points belong in part 7 or in the contract that follows, and they matter more when the developer sits under another country's law.
Who owns the code? Under Belgian law software is protected by copyright. When an employee writes it as part of the job, the employer holds the rights unless agreed otherwise. When you hire an agency or a freelancer, the rights stay with the maker unless you agree a transfer. Such a transfer is proven in writing, read narrowly, and must state the payment, scope and duration for each way the work will be used. So write down what you want: the source code and the rights on delivery, or a broad licence. Other countries have their own rules; put it in the contract either way.
Who processes the personal data? If the developer stores or hosts data about your staff or customers, it is a processor under the GDPR, and you sign a data processing agreement: the developer acts only on your instructions, secures the data, uses no other processor without your written consent, and returns or deletes everything when the work ends. Say in your specification where the data must live; EU hosting keeps this simple.
Who carries the risk? The new EU rules on product liability cover software too; see what the product liability directive means for a custom build. Ask your developer how they test, back up and roll back a release.
An RFP template for software development
Send the same specification to three developers and it becomes your request for proposal. They quote on the same thing, and you compare prices instead of interpretations. Add three lines on top: your budget range, the date you need it live, and the date you want the proposals. A developer who asks back about your data or your test has read it. Rates still differ a lot between countries; web developer hourly rates and the guide on the best countries to outsource software development help you read the numbers.
| Priority | Meaning | In the quote |
|---|---|---|
| Must | no launch without it | in the fixed price |
| Should | important, with a workaround | in the price or as an option |
| Could | nice if time and budget allow | a separate option |
| Not now | postponed on purpose | not priced, but named |
An honest rule: if more than half of your requirements are Must, you have not chosen yet. In the example it is three out of seven.
Which template or route fits your question
- Choose this specification template ifyou are having something built that your team uses every day: a planning board, a client portal, a web application or your own platform.
- Choose a package first ifyour process looks like that of a thousand other companies. Read build vs buy software and CRM vs ERP before you commission anything.
- Choose the website brief ifyou need a site to win customers rather than a tool to work with: the website brief template asks the questions that set a site's price.
- Choose the quote template ifyou are the supplier and have to price a job: the quote template adds up lines and VAT.
- Choose AI first ifthe work is reading, sorting or writing rather than planning: estimate the running cost with the AI cost calculator.
Mistakes in a specification
- Describing screens instead of work"A blue button top right" says nothing about what the planner wants to achieve.
- Everything on MustThen the developer cannot leave anything out and the price becomes a guess.
- Forgetting the exceptionsWhat happens when a driver calls in sick at 6 am? That is where the real work is.
- No testWithout part 10 a project is never done, only over.
- Ownership left openWithout a written transfer, the code stays with its maker.
- Leaving out the people who use itHave a planner and a driver read it before it goes out.
Starting your specification this week
- Write part 1 in five sentences: the problem, what it costs, and how you will see it is solved.
- Ask two colleagues to note for one week what they do in spreadsheets or on paper.
- Fill in the requirements list in Excel and give every row a priority.
- Write the test of part 10 before anyone quotes.
- Send it to two or three developers and compare what they ask back. Replacing spreadsheets with one system? Read what an ERP holds before you specify your own.
What buyers ask before a build
How long should a requirements specification be?
For a first version, three to five pages plus the requirements list. Forty pages usually describe what screens look like instead of what they must solve.
What is the difference with a functional design?
You write the specification: what and why. The developer works out the functional design with you after approval: every screen, every rule, every exception.
Can I use it as an RFP?
Yes. Add your budget range, the go-live date and a reply date, and send the same file to every developer you invite.
Does it matter that the developer is in another country?
Less than you think, if ownership, data processing and the acceptance test are written down. That is what parts 7 and 10 are for.
