Writing a software requirements specification: 7 steps and a template

Before you have an application developed, you need to be able to explain it to someone who doesn’t know your business: what it must do, for whom, and why. That is the whole point of a software requirements specification. Written well, it aligns your team, lets providers price the project on the same basis and serves as the reference right up to delivery.

You don’t need to be an IT specialist to write one: it describes your business, not the technology. Here is our seven-step method, a template outline to copy, and the mistakes we come across most often.

What a software requirements specification is for

A requirements specification describes the need: the “what” and the “why”. The “how” (technologies, architecture, hosting) is the provider’s job, set out in its technical specifications. You will also hear it called a requirements document, or a functional specification.

This document does three jobs:

• Aligning your team: management and users agree on what matters.
• Comparing proposals: every provider prices the same thing, and the differences in price can be explained.
• Checking what is delivered: it is the basis for acceptance testing, which checks that the software does what was asked for.

For a fixed-price project, it also becomes the basis of the price: the clearer it is, the more reliable the quote, as we explain in our article on the cost of custom software.

How to write a requirements specification in 7 steps

1. Start from the problem, not the solution

Begin with what isn’t working today. “We want a mobile app” is a solution. “Our technicians fill in their reports on paper, then someone re-keys them at the office” is a problem: it leaves the door open to several answers, some of them simpler.

Then turn each problem into a measurable goal: time spent, number of errors, lead times. Once the software is live, you will know whether the project has delivered on its promise.

2. Describe how things work today

Explain how the work gets done today, step by step: who does what, with which tools and which files. Note the friction points: re-keying, waiting, recurring errors.

Hunt down the exceptions: sentences that begin with “except when…” often hide the most important business rules.

3. Identify the users and their roles

List the types of user who will use the tool: management, sales, accounts, customers, partners. For each one, specify what they can see or do, and where they work: at the office, on the move, in the field.

These answers weigh heavily on the design. For the CRM/ERP of a Sydney law firm, a project led by our founder, they resulted in two structural choices: different access depending on each person’s role, and apps on desktop, iOS and Android.

4. Write the requirements as scenarios

This is the heart of the requirements document. Rather than a list of features, describe concrete situations with a simple formula, the user story of agile methods: “As a [role], I want [action], so that [benefit].” For example: “As a salesperson, I want to turn a signed quote into an order in one click, so that I don’t have to re-key anything.”

Give each scenario a success criterion: how will you know it works? These criteria feed straight into acceptance testing.

5. Prioritise, without making everything a “must have”

Rank each scenario: must have for the first version, should have, could have, or won’t have this time. That is the spirit of the MoSCoW method. If everything is a must have, nothing is, and the first version never arrives.

Also write down what is out of scope: this short list prevents many misunderstandings and protects your budget.

6. List the constraints, the data and the tools to connect

Gather everything that frames the project:

• the tools in place: those to keep, replace or connect to the future software (accounting, email, CRM, payments);
• the existing data: files, spreadsheets or old software to migrate, with an example of each;
• security and confidentiality: sensitive data, access rights, a record of who did what, the GDPR;
• the platforms: computer, phone or tablet, and any need to work offline;
• the timeline and budget: the target date for a first version, and an indicative range.

Giving a budget range is not a trap: it allows the provider to propose a solution that fits your situation, rather than an ideal answer that is out of reach.

7. Have it reviewed, then keep it alive

Have the document reviewed by the key users and by the person who will make the decision. Then date it and number its versions: it will change during the project, and that is normal.

A software requirements specification template to copy

Here is the outline we recommend. A few lines per section are enough to get started.

1. Background: your company, your business, what is driving the project.
2. Goals: what needs to change, and how to measure it.
3. Current situation: today’s process, the tools, the friction points.
4. Users and roles: who uses the tool, and what each person can see or do.
5. Scenarios: the requirements ranked by priority, with their success criteria.
6. Business rules: calculations, statuses, exceptions, documents to produce.
7. Data and integrations: what has to be migrated, and the tools to connect.
8. Constraints: security, confidentiality, platforms, hosting, accessibility.
9. Out of scope: what the project will not do, or not yet.
10. Timeline and budget: the target dates and the indicative budget.
11. Organisation: the project lead, the key users, who approves what.

In an appendix, attach real examples, anonymised if necessary: quotes, invoices, forms, screenshots of your spreadsheets.

Five mistakes to avoid in a requirements specification

• Imposing a technical solution without explaining the need. You miss out on the provider’s ideas, which are sometimes simpler.
• Trying to cover everything. A document that is too long doesn’t get read. Clear scenarios are worth more than an endless list of features.
• Using vague words. “Simple”, “fast”, “intuitive”: everyone understands them in their own way. Replace them with a criterion you can check, for example “a new user creates their first record without any training”.
• Writing it alone, without the users. Only they know the exceptions and the everyday workarounds.
• Forgetting what comes after. Specify from the outset who will develop the software further, who will host it, and who will own the code and the data.

Complete the specification with a scoping workshop

Even a well-written specification leaves questions open. A scoping workshop deals with them before development starts: a few working sessions that bring together the project lead, the key users and the provider. They are used for three things:

1. Asking the missing questions: edge cases, volumes, unwritten rules.
2. Weighing each requirement against its cost, and looking for something simpler.
3. Setting the order of deliveries, starting with a useful first version.

We do this work as an audit, proposed at the end of the discovery call and carried out on the basis of a quote. You come away with a clear scope and a costed proposal for your custom software. And if you are comparing several offers, here is our advice on choosing an IT provider.

Frequently asked questions

Who should write the requirements specification?

You, with your teams: it is your business that the document describes. Appoint one person to hold the pen and consult the users. A provider can help you structure it, but the need must come from the company.

How long should a software requirements specification be?

As short as possible, as long as the goals, scenarios and priorities are clear. For a first version, a few well-structured pages are often enough.

Is a requirements specification compatible with agile methods?

Yes. Agile doesn’t do away with scoping: it avoids freezing everything at the start. The specification sets the goals, the scope and the priorities; the detail of each feature is worked out at each iteration, with regular demos to correct course as early as possible.

In short

A good software requirements specification doesn’t describe a solution. It describes your problem, your users, your scenarios and your priorities, in words everyone understands. Start from how the work is really done, keep it short, prioritise decisively and make it a living document.

Do you have a first draft, or just a few notes? That is enough to start. Book a free 30-minute discovery call: we go through your notes with you and look for the simplest answer to your need.