How to write a software requirements document that gets you comparable quotes

You send the same idea to three suppliers in a two-paragraph email. You get back €25,000, €70,000 and €140,000. None of them is wrong. Each one priced a different system: the one they imagined while reading your email.

A requirements document fixes that. It is not bureaucracy. It is the cheapest way to make sure everyone quotes for the same thing, and that you get the system you had in mind.

The numbers back it up. In a study by the Project Management Institute, when projects did not meet their goals, inaccurate requirements management was the primary cause almost half the time (47 %), and 5.1 % of every dollar spent on projects was wasted because of poor requirements management.

What a requirements document is, and what it is not

It describes what the system must do and why. Not how. The how is the supplier’s job, and leaving them room to propose a solution is one of the things you pay them for.

In German-speaking countries the distinction even has names: the client writes the Lastenheft (what and why), and the supplier answers with a Pflichtenheft (how and with what), as defined in DIN 69901-5. Internationally, ISO/IEC/IEEE 29148 describes requirements engineering in detail.

For a medium-sized company, you do not need a hundred pages. Five to fifteen pages that answer the right questions are enough.

What goes in it

Section	What it answers	Example
Goal	Why the system, and how you will measure success	“Three people spend two hours a day typing orders from email. Goal: under 30 minutes.”
Current state	How it works today, with which tools	“Orders arrive by email and in Excel and are typed into the ERP.”
Users and roles	Who uses it and what they may do	“Sales creates orders, the warehouse confirms them, admins see everything.”
Processes	The main flows, step by step	“Order arrives, stock is checked, order is confirmed, invoice is sent.”
Data	What data, where it comes from, how much	“About 300 orders a day and 5,000 customers, imported from the ERP.”
Integrations	Which systems it must talk to	“ERP through its REST API, email, accounting.”
Non-functional requirements	Speed, security, availability, data protection, devices	“Sign-in with Microsoft 365, data stored in the EU, works on a tablet in the warehouse.”
Acceptance criteria	How you will check that it is done	“An order from email reaches the ERP within five minutes without manual entry.”
Scope of delivery	What is included besides the code	“Training, documentation, handover, the first three months of support.”
Priorities	What must be in the first version	Must, should, could

Write requirements that can be checked

The most common weakness is a requirement nobody can check. “Fast” means something different to you, to the supplier and to a user on a slow connection. Every requirement should be something you can test at acceptance:

Vague	Checkable
The system must be fast	The order list loads in under two seconds with 10,000 orders
User-friendly	A new warehouse worker confirms an order without training, in under a minute
Secure	Sign-in with Microsoft 365 and two-factor authentication; every change to an order is logged with user and time
Integration with the ERP	New orders reach the ERP within five minutes; if the ERP is down, they are retried and an admin is notified

What to leave out

• Screen designs down to the pixel, unless they really matter. Describe what the user needs to do, not where the button goes.
• Technology choices without a reason. If you have one, write it down: “must run on our SQL Server”, “our team maintains .NET”. Otherwise, let the suppliers propose.
• Every exception in the first draft. Mark open questions instead. A good supplier will ask about them, and the answers make the document better.

Must, should, could

Mark every requirement with a priority. Must: without it, the system is useless. Should: important, but there is a workaround. Could: nice to have.

This does two things. The quotes become comparable, because everyone prices the same first version. And you get a natural first release: only the musts, in production quickly, with the rest following once users have seen it.

How detailed the document needs to be also depends on the contract. With a fixed price, it becomes part of the contract and needs far more detail. More on that in our article on fixed price or time and materials.

Let AI write the first draft

Writing the document is often what stalls a project for months. AI shortens it considerably. Record a conversation with the people who do the work today, or write down the process in your own words, then give it to an AI assistant together with the table above. Ask for a draft and a list of open questions.

You still read and correct every line, because only you know the business. But correcting a draft takes hours, and writing from a blank page takes weeks. One rule: do not paste confidential data into a public chat tool. Use the version your company has approved, with your data protection settings.

What happens next

Send the same document to three suppliers and ask each to answer requirement by requirement: how they would solve it, what it costs, and what is unclear. In German-speaking countries, that answer is the Pflichtenheft.

Then compare the answers, not just the totals. A supplier who asks good questions has read the document. One who asks none has priced a guess. Realistic price ranges are in our article on what custom business software costs.

How we work

This is exactly where we often start. ProCoding is a .NET studio in Split, Croatia, and we build business applications in .NET and Blazor, and bring AI into business processes. In a short analysis we go through your processes with the people who know them, write the requirements document with you and give an estimate in ranges. The document is yours, and you can ask other suppliers to quote on it too. The first step is a free 30-minute call.

Sources

• Requirements Management: A Core Competency for Project and Program Success, PMI’s Pulse of the Profession, Project Management Institute, August 2014
• Lastenheft, Wikipedia (definitions from DIN 69901-5)
• ISO/IEC/IEEE 29148:2018, Requirements engineering, ISO