A software requirements document that gets you an accurate quote is short, plain and specific. It says what problem you are solving, who will use the software, what each of those people needs to do, what information it stores, what it must connect to and what is out of scope. Add your deadline, a budget range and how you will judge success. A few clear pages written in your own words will get you better quotes than a thick specification full of guesses.
Most quotes go wrong for one reason. The developer pictured one thing, the business pictured another, and nobody found out until the invoice arrived. A good brief closes that gap before anyone writes a line of code.
What a software requirements document is
In large projects the formal version is called a software requirements specification. The IEEE Computer Society describes it as a description of what the software should do from the user’s point of view, split into functional requirements (what it does) and non-functional ones (how well, how fast, how securely). It acts as an agreement between the business and the team building the software.
A small or medium business rarely needs the full formal version to get a quote. You need the same thinking in a lighter form: a brief. The developer’s job is to turn your brief into a detailed written scope after a discovery session. Your job is to give them enough truth about your business to make that scope accurate.
What to put in your software requirements document
1. The problem, in one paragraph
Describe what is going wrong today, not the software you imagine. “Quotes take two days because pricing lives in three spreadsheets and only one person knows how to combine them” tells a developer far more than “we need a quoting system”. If you can say what the problem costs in hours, errors or lost sales, include it.
2. Who will use it
List the types of people, not their names: sales staff, managers, technicians, accounts, customers, suppliers. Note roughly how many of each and whether they will use it on a desktop, a phone or both. Roles drive permissions, and permissions drive a surprising share of the work.
3. What each person needs to do
Write short sentences in the form “As a [role], I need to [action] so that [reason].” For example: “As a technician, I need to photograph a finished job and get the client’s signature on my phone so that accounts can invoice the same day.” Ten to thirty of these usually cover a first version. They are easy to write, easy to price and easy to test later.
4. The information it will hold
List the main things the system keeps track of: clients, jobs, products, bookings, invoices, documents. Flag anything personal or sensitive, such as ID numbers, health information or bank details. Under POPIA that information needs extra care, and it affects how access, logging and hosting are designed. Mention where the data lives today and roughly how much of it needs to move across.
5. What it must connect to
Name every system it needs to talk to: Sage or Xero, your CRM, a payment gateway, a booking engine, email, WhatsApp, your website. Say which direction the data flows and how often. Integrations are one of the biggest swing factors in any quote, and our guide to business systems integration explains why.
6. What is out of scope
This is the section most people skip and the one that saves the most money. If the first version doesn’t need a mobile app, reporting beyond three basic reports, or a customer login, say so. A clear “not now” list stops quotes from padding for things you didn’t want.
7. Your constraints
Give a deadline and the reason for it, such as a season, a contract or a financial year end. Give a budget range. Mention any rules you must follow, from POPIA to industry regulations, plus anything fixed, like “must work on the tablets we already own”.
8. How you will know it works
Describe what success looks like a month after launch. “Quotes go out the same day.” “No more month end spreadsheet.” “Clients stop phoning to ask for statements.” These become acceptance checks, so both sides agree on what done means.
An outline you can copy
- Company name, contact person and who signs off decisions
- The problem today, in one paragraph
- Users and roles, with rough numbers and devices
- What each role needs to do, as short “As a … I need to … so that …” sentences
- Information the system holds, with personal data flagged
- Systems it connects to and which way the data flows
- Out of scope for the first version
- Deadline, budget range and fixed constraints
- What success looks like after launch
- Attachments: the spreadsheets, forms, screenshots and reports you use today
Those attachments are gold. A messy spreadsheet or a photo of a paper job card shows a developer your real process faster than any description.
Say a plumbing firm in Wellington wants a job card app. A useful brief would explain that six technicians fill in paper cards, that the office retypes them into Xero each evening, that clients sometimes dispute call-out times, and that the first version only needs jobs, photos, signatures and a draft invoice. That one paragraph already answers half the questions a developer would ask.
Gaps that make quotes jump later
- Describing an app you have seen instead of your own process. “Like a well known app, but for our industry” leaves every important detail to guesswork.
- Forgetting the admin side. Someone has to add users, change prices and fix mistakes, and those screens take real time to build.
- Leaving out data migration. Moving years of records from old files is its own piece of work.
- Vague reporting. “Good reports” can mean one screen or forty. List the reports you actually open each month.
- Open-ended wording such as “and anything else we might need”. A fixed price needs a fixed scope.
What happens after you send it
Our process starts with discovery. We read your brief, ask the questions it raises and, where it helps, watch the process in action. Then you get a written scope and a fixed price, with ownership and licensing set out in writing. Larger platforms are scoped in phases, and most first versions go live in 4 to 10 weeks. Our post on what custom software costs in South Africa explains what moves the number.
Questions people ask
How long should a software requirements document be?
For a quote, two to six pages is plenty for most business tools. Length matters less than being specific. One clear page beats twenty vague ones.
Do I need technical knowledge to write one?
No. Write about your business, your people and your problems in plain language. The technical choices are the developer’s job, and a good one will ask follow-up questions.
What is the difference between a brief and a scope?
You write the brief to explain what you need. The developer writes the scope after discovery to state exactly what will be built, for what price and by when. The scope is the document you sign.
Should I share my budget?
Yes, as a range. It lets the developer suggest what fits, such as a smaller first version or a phased plan, instead of quoting for something you were never going to approve.
Got a half-written brief, or just a spreadsheet and a headache? Send what you have to [email protected] or use our contact page, and we’ll reply within one working day. You can also read the FAQ or see what we build.