How to write a software requirements brief: six headings that make proposals comparable
If three agencies send three proposals that do not line up, the problem is not the agencies — it is the brief. A brief is not a technical document but a decision document: what belongs in it and what does not.
If you described the same need to three agencies and got three proposals that do not line up, the agencies are not the first place to look. All three understood something different — because what you described changed a little each time.
That is what a brief is for: making agencies price the same thing. It is not a technical document but a decision document, and writing it is a job for the person who knows the business, not for a developer.
What belongs in it, and what does not
Write down: what will exist, who will use it, and the conditions under which it counts as done.
Leave out: how it will be built. Database choice, framework, architecture — these are the agency’s field, and specifying them does two things: it ties the hands of an agency that could have proposed something better, and it moves responsibility to you when the result disappoints.
One exception: if compatibility with an existing system is mandatory, say so. Not “use PostgreSQL” but “our data lives in PostgreSQL today and is not moving.”
The six headings
1 · Business goal and success measure. What problem does this software solve, and how will you know it did? “Cut the phone traffic around order entry in half” is a hundred times more useful than “a modern order system”.
2 · User roles. Who signs in, who sees what, who can change what. A permission matrix is not a feature to bolt on later; leave it out at the start and it distorts the data model.
3 · Critical flows. Not all of them — write out the three to five most used, step by step. “The customer places an order” is not enough: which screen starts it, what happens in which state, what they see when stock runs out.
4 · Integrations and who owns them. Which systems it talks to, whether those systems are documented, who obtains access. When you are not the counterparty to an integration — a bank, an e-invoicing provider, a courier — put the application lead time in the brief too. This is where timelines slip most often.
5 · Data. Do you have existing data, is it migrating, in what format? Moving a five-year Excel archive is a project in itself, and forgetting it means the bill arrives later.
6 · Acceptance criteria. The conditions under which you will sign off. Make them measurable: not “it should be fast” but “the product list loads in 3 seconds on a 3G connection”. A criterion you cannot measure is an argument at delivery.
Write down what is out of scope
This is the most commonly skipped section of a brief and the one that saves the most money.
“No mobile app in this project”, “multi-language is phase two”, “accounting integration is out of scope”. Leave those sentences out and each one becomes a mid-project argument about what was implied — the single biggest cause of budget overruns.
Who writes it
Ideally you do; nobody knows your business better. If you cannot translate it into technical terms, that is normal, and the answer is this: discovery is bought as a small, separate engagement.
Discovery produces a written scope document, and that document is yours — you can use it to get quotes from other agencies too. An agency that refuses this is selling you dependency, not a document. It is the first question to ask in a proposal meeting.
The brief is only one step of the process; the whole sequence, from defining the need to handover, is in how to commission software.
Once the brief is ready, the next step is the contract: what to check in a software development contract.
If you want to map the scope together and end up with a document you can take to other agencies, let’s set up a call. How the price attaches to that document is covered in the pricing article.
