How to Write a Software Requirements Document (With a Template)

Related: How to Protect Your IP When You Outsource Software Development

The quality of a software quote depends almost entirely on the quality of the brief behind it. A vague brief produces either a padded quote, because the developer is pricing in the unknowns, or a cheap quote followed by a long list of extras.

A clear requirements document fixes both. Here is how to write one.

Four principles

1. Describe problems and outcomes, not solutions. "Customers need to see their order status without calling us" is a requirement. "Add a React status widget" is a design decision, and probably not yours to make.
2. Make every requirement testable. If someone else could not check whether it was delivered, it is not specific enough.
3. Prioritise. Not everything can be essential. Rank it.
4. Say what is out of scope. This section prevents more disputes than any other.

Vague versus clear

• Vague: "The system should be fast."
  Clear: "Search results appear within 2 seconds for a catalogue of up to 50,000 products."
• Vague: "Users can manage their account."
  Clear: "Users can change their email, password and delivery address, and download their invoices as PDF."
• Vague: "It should be secure."
  Clear: "Staff sign in with two-factor authentication. Customers can only ever see their own orders."
• Vague: "Integrate with our accounting."
  Clear: "When an order is paid, create a matching invoice in our accounting system within 5 minutes."

The template

Use these sections in this order. Skip any that genuinely do not apply.

1. Summary

One paragraph. What problem does this solve, for whom, and why now.

2. Goals and success measures

How will you know it worked? Use numbers where you can. "Cut phone enquiries about order status by half within three months."

3. Users and roles

Every type of person who will use it, and what each is allowed to do. For example: customer, support agent, warehouse staff, administrator. A permissions table works well here.

4. Key journeys

Walk through the most important tasks step by step, from the user's point of view. A common format is:

As a [role], I want to [action] so that [outcome].

Five to fifteen of these usually covers the core of a product.

5. Functional requirements, prioritised

Everything the software must do, each labelled:

• Must: launch is pointless without it
• Should: important, but launch could happen without it
• Could: nice to have if time allows
• Won't, this time: agreed as out of this phase

If more than about half is "must", you have not really prioritised.

6. Data

What information is stored, where it comes from, who can see it, and how long it is kept. Note any existing data that needs importing, and what shape it is in.

7. Integrations

Every external system it connects to: payment, email, accounting, CRM, shipping. For each, note who owns the account and whether API access exists. Missing API access discovered halfway through a project is a common and expensive surprise.

8. Non-functional requirements

• Expected users and traffic, now and in a year
• Speed expectations for key pages or actions
• Availability: what happens if it is down for an hour
• Security and privacy rules, and any regulations that apply
• Accessibility standards
• Supported devices and browsers
• Languages and currencies

9. Out of scope

List what this project will not include, explicitly. Mobile apps, a second language, migrating old data, an admin reporting suite. Anything someone might reasonably assume is included but is not.

10. Assumptions and open questions

What you are assuming to be true, and what you do not know yet. Writing unknowns down is honest, and it lets a developer price the risk properly instead of guessing.

11. Constraints

Budget range, deadline and the reason for it, any required technology or hosting, and anyone who must approve decisions.

12. Acceptance

How you will decide the project is finished. Ideally, a list of checks that must pass.

Common mistakes

• Designing the solution. Describe the need and let the people building it propose how.
• Everything is a must. Then nothing is, and the first budget conversation gets painful.
• Forgetting the admin side. Someone has to manage users, fix mistakes and handle refunds. Those screens are real work.
• Forgetting what happens when things fail. A card is declined. An email bounces. A file is too large.
• Length over clarity. A clear five page document beats a vague fifty page one.

Why this matters for price

A fixed quote is only as good as the scope behind it. With a clear document, a developer can price accurately and commit to the number. Without one, you get a padded price, a long list of change requests, or both. See fixed price versus time and materials.

We turn rough briefs into written scopes before quoting on every project. If you have an idea and not yet a document, start there with us. Also see how to build an MVP.