Software Requirements Document: What To Include
If you have asked three developers for a quote and received three wildly different numbers, the problem is usually the brief rather than the developers. This is what a requirements document needs to contain for an estimate to mean anything.
Discuss your projectWhy vague requirements produce useless quotes
A developer pricing an ambiguous brief has three options: pad heavily to cover what they do not know, quote low and raise change requests later, or guess. None of those serves you, and you cannot tell which one you received by looking at the number.
The specific things that make a brief unquotable are predictable. How many user roles there are, and whether each sees different records — this single question can change a build's cost severalfold. Which external systems it must connect to, and whether those have usable APIs. Whether existing data must be migrated, and in what state it is. And what has to be true for the project to be considered finished.
You do not need a technical specification. You need to answer the business questions precisely enough that the technical consequences are determinable. The sections below are what we would want before quoting, and what we would suggest you provide to anyone else.
Sections worth including
In rough order of how much they affect an estimate.
- The problem, in business terms. What happens today, where it goes wrong, and what success would look like in something you could measure. A developer who understands the problem will propose better solutions than one implementing a feature list.
- User roles, and what each can see and change. Be exact. "Admins and users" is two roles; "admins, team leads who see their own team's records, users who see only their own, and an auditor with read-only access to everything" is four, and costs considerably more.
- The core workflows, step by step, in the order they happen. Three or four of these are worth more than thirty bullet-point features.
- Integrations, named, with whether you know an API exists. An integration with a modern documented API is days; one with a system whose documentation is a PDF from 2017 is weeks.
- Data to migrate: what, how much, where it lives now, and how clean it is. Honestly — understating this does not make it cheaper.
- Volumes and concurrency. Ten users or ten thousand; a hundred records or ten million. Architecture decisions depend on this and getting it wrong in either direction is expensive.
- Explicit exclusions. What is deliberately not in version one. This section prevents more disputes than any other.
- Constraints: deadlines that cannot move, platforms you must support, compliance requirements, technologies your team must be able to maintain.
- Who decides. The single most useful line in any brief is the name of the person who can resolve a question without convening a committee.
Things that commonly go wrong
Solutions in place of requirements
"We need a dashboard with these twelve charts" states a solution. "Our managers cannot tell which jobs are late" states a requirement, and may have a better answer than a dashboard.
Everything marked essential
If nothing can be deferred, nothing can be prioritised, and the first release is the whole system. A must-have, should-have, nice-to-have split is the most valuable editing you can do.
No empty or error states described
What a new user sees before there is any data, and what happens when something fails. These are real screens and real behaviour, and omitting them understates the work.
Reports as an afterthought
"Plus reporting" at the end of a brief can be a quarter of the build. Name the questions the reports must answer and it becomes estimable.
Silence on permissions
Who may see what is a data-model question, not an interface question, and it is expensive to add afterwards. It belongs in the brief.
An unexplained deadline
If a date is genuinely fixed — a contract, a season, a regulatory change — say why. A developer can scope to a real constraint and cannot work with a date that is merely preferred.
Common questions
Related in Custom Software Development
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch