You send three software companies a single sentence: "We want a system to manage the company." One quote comes back with a small number, another is several times higher, and the third asks for a meeting. You can't compare them, because each company imagined a different system. A simple requirements document of two or three pages solves a large part of this problem, and you don't need technical experience to write one.
Why do you need a requirements document before asking for a quote?
A quote is built on what the developer understands from your request. The clearer the request, the more comparable the quotes become and the fewer surprises you get after signing.
The document helps you first. Writing it forces you to agree with your partners and department heads on what you actually want, and this is often the stage where it turns out the need is smaller than you thought, or that off-the-shelf software is enough, as we discussed in custom software or off-the-shelf.
What goes into a software requirements document?
These sections cover most business systems. Write them in everyday language, and a good developer will ask you about the technical details.
- About the company: what you do, how many employees you have, your branches and countries.
- The current situation: how the work gets done today, and what breaks, gets delayed or goes missing.
- Users: who will use the system, and what each role needs to see and do.
- Processes: the steps of each process from start to finish, such as from a client's order through to payment collection.
- Data: what you record today and where, with samples of the files and paper forms in use.
- Integrations: the software the system needs to talk to, such as accounting, the online store or the fingerprint attendance device.
- Constraints: the rough budget, the target date, where the data should be hosted, and the language.
How do you describe what the system should do?
The easiest format is "As a [role], I want to [do something], so that [outcome]." These are called user stories, and they tie every requirement to a person and a reason.
For example: "As the sales manager, I want to see contracts ending within thirty days, so that I can contact clients before they expire." That sentence is clearer to a developer than "contract alerts", because it tells them who sees the alert, when, and why. You'll find this case in detail in organizing client contracts and renewals.
Also write down the exceptions that happen in your business: the client who pays in installments, the order cancelled after it was invoiced, the employee covering for a colleague. These cases take the most development time, and leaving them out is the most common reason the price goes up later.
What should you attach to the requirements document?
Attach the files and forms your team really uses: an Excel sheet, a paper order form, an invoice, a monthly report. These samples show a developer the data fields and their rules faster than any description.
Replace real data with sample data before sending, especially client names, phone numbers and amounts. If you have a simple sketch of the workflow, even hand-drawn on paper, take a photo and attach it. It also helps to list the software you use today and its versions, because whether the system can connect to it affects both the design and the price.
How do you prioritize requirements?
Sort the requirements into what the system can't work without and what can wait for a second phase. This sorting protects your budget more than any price negotiation.
| Category | Example from a sales system |
|---|---|
| Essential for the first version | Recording the client, the quotation and the invoice |
| Second phase | Sales rep performance reports |
| Later, if needed | A mobile app for clients |
A small first version that works beats a big system that runs a year late. Splitting the project into phases does more to control cost than anything else, and we went into it in what determines the cost of custom software.
Which mistakes make a requirements document useless?
- Drawing screens in detail while leaving out a description of the work itself. Write what you want to happen, and leave screen design to the specialists.
- Copying a feature list from another product without asking whether you need it.
- Describing only the ideal case and skipping the exceptions mentioned above.
- No decision-maker involved. If the manager doesn't read and approve the document, the requirements will change halfway through the project.
What should you ask the software company after sending the document?
Ask the company to restate its understanding of the project in its own words, and to split the quote into phases showing what each one includes and excludes. A company that asks no questions at all about your document probably didn't read it closely.
Also ask them to spell out what happens after delivery: hosting, support, changes, and ownership of the code and data. Over the long run, these items are where the cost difference comes from.
Don't wait for the document to be complete before sending it. It's a starting point for the conversation, and it will develop during the analysis phase with the team that builds the system.
If you've started your document, send it to us and we'll reply with our questions on it and a first estimate of the phases. We also help write it from scratch as part of the analysis phase in our custom software and systems service.
Questions our partners ask
Do I need technical experience to write a requirements document?
No. Write how your team works and what you want to change, in your own everyday language. The technical details are the software company's job during the analysis phase.
How many pages should the document be?
Two to five pages is enough for most business systems at the start. Clarity matters more than length, and real samples from your files help more than explanations.
Should I sign an NDA before sending the document?
If it contains trade secrets, yes. Either way, use sample data in the attachments instead of your real clients' data.
Written by the Visual Innovate team, the people who build, host and follow up systems, websites and apps for our clients in Jordan, Saudi Arabia, Oman and Egypt.
