Software requirements document: write this before a quote

Before you ask anyone for a software quote, write a short software requirements document yourself. One to three pages is enough. It should say who will use the system, the jobs it must do, what data you already have, what it must connect to, who will own the accounts and code, what "done" means, and your deadline and limits. Send the same document to every agency.

Without it, each agency fills the gaps with its own guesses, and you get three prices for three different projects. You can't compare them, and the cheapest one is usually the one that guessed smallest.

Why do vague briefs produce quotes you can't compare?

A brief that says "we need an inventory app" leaves an agency to decide how many users, how many branches, whether there's an admin side, whether stock comes from an existing spreadsheet, and whether it talks to anything else. Every one of those decisions moves the price.

The agency that wants the job most will assume the smallest version. The careful one will assume more and look expensive. Neither is lying. They're answering different questions, because you asked a vague one. We covered how to line up quotes once they arrive in how to read a software development quote. This post is the step before that: making sure the quotes describe the same project in the first place.

Do you need a formal requirements standard?

No. A formal one exists. ISO/IEC/IEEE 29148 is the international standard for requirements engineering, and it specifies the processes that produce requirements and the documents those processes produce, down to their content and format. It's written for engineering teams running large systems projects.

You're not running one of those. You're an owner or an operations lead who knows how the business works and needs a few honest pages that an agency can price. The agency's job is to turn your pages into a technical specification. Your job is to make sure nothing important is left for them to guess.

What goes in a one to three page requirements document?

Seven sections. Write them in plain language, in the words your staff already use.

Section	What to write	The question it answers for the agency
Users and roles	Every type of person who will log in, and roughly how many of each	How many separate apps or screens are we building?
Jobs the system must do	The tasks each role needs to finish, as short "I need to... so that..." lines	What does each screen actually have to do?
Data you have today	Where records live now: spreadsheets, an old system, paper files	Is there an import, and how messy is it?
Integrations	Anything it must connect to: payment gateway, accounting software, existing website	Which parts depend on someone else's system?
Ownership	Whose name the domain, store accounts, servers and source code will be in	What do we hand over at the end?
What "done" means	How you'll check each job works before you accept it	When is the project finished?
Constraints and deadlines	Launch date and why, budget range if you have one, devices staff use, languages	What can't move?

The next sections explain the three that owners most often get wrong.

How do you describe users and the jobs they need done?

Start with people, not features. List every role: customers, counter staff, branch managers, the accountant, you. A role that only views reports still counts, because someone has to build their screen and decide what they're allowed to see.

Then write the jobs. The GOV.UK Service Manual has a format that works well for this: "I need to... so that...", with an optional "As a..." at the front to name the role. Its advice is to focus on the user's problem rather than a solution, and to base each need on evidence rather than assumption.

So instead of "the app should send SMS notifications", write:

• As a branch manager, I need to know when stock of any item drops below a set level, so that I can reorder before we run out.
• As a customer, I need to know my order is ready, so that I don't come to the counter and wait.

The first version picks the solution for the agency. The second tells them the problem and lets them propose an answer, which might be an SMS, an app notification or a dashboard warning, at very different costs. Good agencies will ask about the "so that" part. That's where they find out what matters.

Go and watch the job being done before you write it. Ask the person who does it today. The step they skip when the office is busy is often the requirement the old system never handled.

What should you say about data and integrations?

Data is easy to underquote, because it is easy to assume it is clean.

Say where your records live now and how many rough years of history you have. Attach a sample with personal details removed: five rows of the customer spreadsheet, one page of the old system's export. The agency will see the duplicate names, the mixed date formats and the column someone uses for notes, and price the import honestly.

For integrations, name the actual product. "Connect to accounting" is a guess. The name of the accounting software you use, and whether it's on a server in your office or online, is a requirement. If you don't know, say so, and ask each agency to quote that part separately.

Who owns the accounts and the code?

Write down, before anyone quotes, that the domain, the hosting or cloud account, any app store accounts and the source code will be in your company's name. Then every quote has to price the same handover.

It matters most for mobile apps, where the store account decides who can publish updates. We explain the account side in publishing an Android app on Google Play from Nepal. If the agency publishes under its own account to get started, the document should say the app moves to yours on request. Ours does that free.

How do you define "done" before work starts?

The Scrum Guide uses a term worth borrowing: the Definition of Done. It describes it as a formal statement of the quality an increment must meet, and says it gives everyone a shared understanding of what was completed. Work that doesn't meet it can't be released.

You don't need to run Scrum to use the idea. For each job in your list, write how you'll check it. "Branch manager gets a low-stock alert within a day of the level being crossed, tested with three items at two branches" is a definition of done. "Stock alerts work" isn't.

Add the general ones too: which phones and browsers it must work on, whether it must work in Nepali, whether staff will be trained, and whether you get a test period before final payment. These are the items that turn into arguments at the end of a project when nobody wrote them at the start.

What about changes after the quote?

Your document will be wrong somewhere. Every project learns something once real users touch it. That's normal, and it's why the quote's change rule matters as much as its total.

A cheap fixed quote with no change rule is the most expensive kind. The first time you ask for something the agency thinks is new, the price conversation happens mid-project, when you have the least leverage. Ask every agency how changes work, in writing. Ours follows three steps: you request the change in writing, we send a time and cost estimate, and nothing is built until you approve it.

Frequently asked questions

Can I just send a list of features instead?

You can, but a feature list hides the users and the reasons. Two agencies will read "reports" differently. Roles plus "I need to... so that..." lines leave far less to interpret.

Should I include a budget in the requirements document?

If you have a range, include it. It lets an agency tell you which jobs fit and which should wait for a second phase, instead of quoting everything and leaving you to cut.

What if I don't know whether I need a website, a web app or a mobile app?

Write the users and jobs anyway, and leave the platform open. The jobs usually decide it. Our post on whether to build a website, web app or mobile app first walks through the choice.

How long should it take to write?

Most of the time goes into talking to the people who do the work, not into writing. Keep it to three pages. If it's longer, you're probably designing screens, which is the agency's job.

Get help with the brief

If you'd rather work through the document with someone outside the business, our consulting team can help you shape it before you go out for quotes, whether or not we end up building it. When it's ready, send it to us and we'll tell you what we think is missing.