How to Write a Software Requirements Document Developers Can Quote From

Here are two sentences a business might send to five software companies: "We need a portal where our customers can place orders, track deliveries and download invoices. It should be simple and mobile-friendly." Each company now has to guess how many kinds of user there are, where delivery data comes from, what an invoice contains and which systems the portal must talk to. They will guess differently, and the quotes will be too far apart to compare. A good software requirements document replaces those guesses with facts, so every vendor is pricing the same system.

This article covers what to put in one, how to write requirements a developer can estimate, and what to leave out. You do not need to be technical to write it. You need to know your business, and you already do.

What the document is for, and what it is not

At the quoting stage, a requirements document has one job: to let a developer estimate the work without guessing. That means describing what the software must do, for whom, and under which constraints. It does not need to say how to build it. Choosing the database, framework and hosting is the developer's job, and a vendor who accepts your technical choices without a single question is not necessarily doing you a favor.

It also does not need to be long. For a small or mid-sized business system, 6–15 pages is usually plenty. A 60-page document in contract language is harder to quote from, not easier, because the parts that matter get buried.

The sections a software requirements document needs

1. Background and goal. Two or three paragraphs: what your business does, what problem this software solves, and how you will know it worked. "Cut the time our staff spend re-typing orders from email" is a goal. "A modern portal" is not.
2. Users and roles. Every type of person who will use the system and what each one is allowed to do: customer, sales rep, warehouse staff, admin. Roles drive a surprising share of the work.
3. Features as user stories. The main body. One feature per item, written from a user's point of view, each with acceptance criteria (more on this below).
4. Data. What the system stores (customers, products, orders, documents), roughly how much, and where that data lives today. If you are moving off spreadsheets or an old system, say so and attach a sample.
5. Integrations. Every system this one must talk to, by name: accounting software, payment gateway, courier, ERP, email or SMS provider. For each, say what information flows in which direction. An unnamed integration is one of the most common reasons quotes differ wildly.
6. Non-functional requirements. Platforms and browsers, number of users, expected busy periods, languages, accessibility, data protection rules you operate under, and your expectations for backups and availability.
7. Out of scope. What this project will not include. This short section prevents more disputes than any other.
8. Constraints. The deadline and why it exists, a budget range, systems or technologies you must keep, and who on your side makes decisions.
9. Content and assets. What you will supply (logo, brand guidelines, product data, copy) and what you expect the vendor to produce.
10. Open questions. Things you have not decided yet. Listing them is far better than hiding them, because an honest vendor will price them as ranges instead of guessing.

On budget: many businesses leave it out, hoping to see who quotes lowest. Including a range usually gets you better proposals, because a vendor can suggest what fits inside it instead of pricing an imaginary ideal version. A clear document matters most of all if you want a fixed price, for the reasons covered in how fixed-price and time-and-materials contracts handle changing scope.

Writing requirements a developer can estimate

The difference between a requirement that can be quoted and one that cannot is usually detail. Compare these two:

Vague: Customers can track their orders.

Estimable: A logged-in customer sees a list of their orders from the last 12 months with a status (received, packed, dispatched, delivered). For dispatched orders it shows the courier's tracking number and a link to the courier's tracking page. Statuses come from our warehouse system and should update at least every 15 minutes. Customers never see another company's orders, and within one company only users marked as company admin see all of that company's orders.

The second version answers the questions a developer would otherwise guess at: which statuses, where the data comes from, how often, what the courier part involves, and who can see what. It is longer, but it takes minutes to estimate instead of a round of emails.

For the features that matter most, add acceptance criteria in a Given/When/Then shape. The format comes from behavior-driven development, and the Gherkin reference explains it plainly: Given describes the starting context, When describes the action, and Then describes the expected outcome. For example:

Given a customer has an order with status "dispatched"
When they open that order
Then they see the courier name and tracking number
And a link that opens the courier's tracking page

You do not need this for every line. Use it where a misunderstanding would be expensive: pricing rules, permissions, payments, and anything involving money or other people's data. The same criteria later become the checklist you use to accept the finished work.

Mark priorities so vendors can price options

Label every feature as must (the system is useless without it), should (valuable, but you could launch without it) or later (a future phase). Then ask vendors to price the must and should groups separately.

Say you run a coffee roastery supplying 150 cafes, and your portal list has 14 features. Placing orders, order history, choosing a delivery day and downloading invoices are musts. Saved favorite orders and a standing weekly order are shoulds. A phone app and loyalty discounts are later. Priced this way, you can see what the must list costs on its own and decide whether the shoulds are worth adding now. Without labels, every vendor makes that call for you, each one differently, and the totals stop being comparable.

Mistakes that make quotes unreliable

• "Like Uber, but for…" A comparison tells a developer the general idea and nothing about scope. Uber has years of features you do not need. List the ones you do.
• Solutions instead of problems. "We need a chatbot" skips the question of what you are trying to achieve. Describe the problem and let vendors propose.
• Integrations revealed late. Mentioning in week six that invoices must sync with your accounting system is how fixed prices turn into change requests.
• No volumes. Fifty orders a day and fifty thousand orders a day are different systems. Give rough numbers, even if they are guesses, and say they are guesses.
• Screens as the only spec. Wireframes help, and even a phone photo of a paper sketch is useful. But a screen shows layout, not the rules behind it. Pair each screen with its rules.

Who should write it, and when to get help

You, or someone in your business who knows the process well, should write the first draft of the software requirements document. Nobody else knows your customers, your exceptions and your workarounds the way you do. Plain language is fine.

Before it goes out for quotes, have someone technical review it. They will spot missing roles, unstated integrations and requirements that sound small but are not ("works offline" is a classic). That review is exactly what an IT consulting engagement is for, and it is cheap compared with five vendors quoting five different systems.

If the document contains commercially sensitive details, ask vendors to sign an NDA before you share it. Most established companies will, and CodeSalen can sign one before the project starts. When the proposals arrive, keep these questions to ask a software development company next to you while you compare them.

Start with ten headings

Open a blank document and type the ten section headings from the list above. Fill in background, users and features first, even roughly, then integrations and out of scope. Leave anything you are unsure of under open questions. A rough document with honest gaps will get you better quotes than a polished one that hides them.

If you have a draft and want to know whether a developer could quote from it, send it over and we will point out what is missing.