How do you write a software requirements specification?

What is a software requirements specification for?

It serves three purposes: clarifying your need for yourself, letting one or several providers quote on the same basis, and acting as a reference during the project to recall what was planned. It is not meant to decide, in the provider's place, how the software will be programmed.

A requirements specification isn't mandatory to make contact. A serious provider knows how to turn a problem into a written scope: that is the role of scoping. The document you prepare speeds up that scoping and makes the quote more reliable, but it doesn't replace it.

What a requirements specification must contain

The essentials fit into a few sections. Describe real situations rather than abstract functions: “the technician fills in the report on site, without a network, and the manager approves it the next day” is more useful than “reporting module.”

• The problem to solve today, and what you want to achieve
• The users: who will use the software, how many, under what conditions (office, field, without a network)
• The main tasks, described as a typical day
• The business rules and known exceptions
• The existing data to migrate (spreadsheets, old software, paper) and its state
• The tools the software will need to exchange data with
• Constraints: timeline, intended budget, confidentiality, hosting
• What is out of scope, at least for the first version

Requirements specification plan template to copy

Copy this plan into a document and fill in each section in your own words. Leave a section blank if you don't know: that's useful information for the provider, who will address it during scoping.

SOFTWARE REQUIREMENTS SPECIFICATION — [Project name]
Company: [name] · Contact: [name, role, email] · Date: [dd/mm/yyyy]

1. Context
   - The company's activity in two sentences
   - How the work is done today (tools, files, paper)
   - What's not working: errors, duplicate entry, lost information, delays

2. Objective
   - What the software must change, concretely
   - How you'll know it has succeeded

3. Users
   - Profiles (e.g. technician, manager, accountant, client) and headcount
   - Where they work: office, field, without a network, on which device

4. Typical days
   - For each profile: what they do, in order, with which information

5. Business rules and exceptions
   - Who can see, create, edit, approve what
   - Known special cases (and how they are handled today)

6. Data
   - Existing data to migrate: where it is, approximate volume, condition
   - Documents to produce: reports, exports, PDFs

7. Exchanges with other tools
   - Accounting, ERP, email, existing software: what, in which direction

8. Constraints
   - Desired timeline, fixed deadlines
   - Intended budget (range), confidentiality, hosting

9. First version
   - What is essential at launch
   - What can wait for a following version

10. Appendices
   - Example files, screenshots, current paper forms

Common mistakes

Most requirements specifications that cause problems do so for the same reasons. None are serious if spotted early.

• Describing a technical solution (language, database) instead of the problem
• Writing it alone, without the people who will use the software day to day
• Listing every conceivable feature without distinguishing what's essential
• Forgetting to migrate existing data, often the longest item
• Saying nothing about exceptions, even though they are what drives the cost
• Forgetting to state that the source code and accounts must be in your name

From the requirements specification to the quote

With this document, a provider can ask you the right questions, then propose scoping: a step where they come and see the actual work, gather the rules and examine the data before quoting. Be wary of a firm price given on the basis of a document alone, with no questions asked: it will be wrong one way or the other.

To compare several quotes afterwards, see the guide How much does custom software cost?. For the rest of the journey, the guide How do you get an app built? describes the steps, and the page Custom business software presents how we work.