Skip to content

Template

Software requirements specification template

Ten parts in plain English, from why to done, with a requirements list in Excel and a filled-in example.

Free, no e-mail address. Yours to adapt and share.

The filled-in software requirements specification of a planning board for a haulage company: the why, the roles and seven requirements with their priority

By , Founder and CEO

What is in the file

Write the specification in Word, part by part, with the filled-in planning board next to it. Each requirement goes into the yellow cells of the Excel list, with a priority from the dropdown and how you test that it works.

  1. 01Word: your specificationTen parts, each with the question it answers: why, who, what, screens, data, integrations, rules and ownership, out of scope, timing and budget, and the definition of done.
  2. 02Word: the filled-in exampleA fictional haulage company with 14 trucks and 19 drivers replacing its spreadsheet planning with a planning board, written the way we write a specification.
  3. 03Excel: requirements listThirty empty rows in the form role, I want, so that, with a priority list (Must, Should, Could, Not now) and a column for the acceptance test.
  4. 04Excel: example and how-toThe seven requirements of the planning board, R1 to R7, each with its acceptance test, and a tab that explains how to fill in the list.
On this page
  1. 01A software requirements specification template without sixty pages
  2. 02Specification or functional design: the difference
  3. 03The filled-in example: a planning board for 14 trucks
  4. 04Ownership, data and contracts across borders
  5. 05An RFP template for software development
  6. 06Which template or route fits your question
  7. 07Mistakes in a specification
  8. 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.

PartThe questionIn the example
1. Whywhich problem, what it costsmorning planning takes 90 minutes
2. Whowhich roles, how many people2 planners, 19 drivers, owner, accountant
3. Whatrequirements with a priority7 requirements, 3 of them Must
4. Screenswhat you pictureweek board, job detail, driver app, admin
5. Datawhat lives where, who changes ita spreadsheet with Staff and Fleet tabs
6. Integrationswhich software it talks toa monthly export for the accountant
7. Rules and ownershipwho sees what, who owns the codea driver sees only his own jobs
8. Out of scopewhat is left out on purposeno payroll, invoicing or route map
9. Timing and budgetwhen live, who decideslive before 1 March
10. Donethe testone 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.

DocumentWritten byWhat it saysWhen
Requirements specificationyouwhat the software must do, and whybefore you ask for prices
Functional designthe developer, with youevery requirement worked out in screens and rulesafter approval, before the build
Technical designthe developerhow: architecture, database, hostingduring the build
Quotethe developerwhat is delivered, price, timingafter the specification
Contractbothownership, warranty, maintenance, data protectionbefore 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

  1. Start with the problemWhat does it cost today, in hours or mistakes? A specification that starts with screens forgets why you build.
  2. 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.
  3. Give every requirement a priorityMust, should, could or not now. Only the musts go into the first version.
  4. 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.
  5. 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.

IDRequirement, shortPriority
R1the week as a board, drivers as rowsMust
R2drag a job and see a conflictMust
R3tomorrow's jobs on the phone at 6 pmMust
R4report a problem with a photoShould
R5the week plan as a PDFShould
R6monthly export per customerCould
R7the trucks' GPS on the boardNot 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.

PriorityMeaningIn the quote
Mustno launch without itin the fixed price
Shouldimportant, with a workaroundin the price or as an option
Couldnice if time and budget allowa separate option
Not nowpostponed on purposenot 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

  1. Write part 1 in five sentences: the problem, what it costs, and how you will see it is solved.
  2. Ask two colleagues to note for one week what they do in spreadsheets or on paper.
  3. Fill in the requirements list in Excel and give every row a priority.
  4. Write the test of part 10 before anyone quotes.
  5. 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.

Custom software

How VBS turns your specification into software

We read your specification with you, ask about the exceptions it does not cover yet, and build the Musts first. Every requirement gets the test from part 10, so you see for yourself when it is done. That is how we built the platform DA Logistics runs on every day: some thirty drivers and 34 vehicles, a planning board, a driver app in three languages and fuel tracking. Zuco Logistics runs on the same core and went live in one afternoon. We work from Ghent, Belgium, in English and in your time zone; see custom software or bring your specification to a call.

Tell us where you stand.

A few sentences will do. We reply within 24 hours with a proposal for a first call.

Optional, if you prefer a call.

What do you want to achieve, and what is already there?

We only use your details to reply to you.