How to Write Software Requirements Vendors Can Actually Quote

Send the same two-paragraph request to four software houses and you can easily get quotes ranging from Rp80 million to Rp400 million. Nobody has to be lying for that to happen. Each vendor filled the gaps in your request with their own assumptions, and those assumptions are what you end up comparing. A good brief closes most of the gaps before anyone estimates. It does not need to be long, and you do not need to be technical to write it. Below is what to put in it, what to leave out, and how it later turns into the scope of your contract.

Why the Same Request Gets Quotes Five Times Apart

Take a line like "we need an app for our sales team to record store visits". One vendor reads it as a simple form with GPS check-in and a photo upload, six weeks of work. Another assumes offline mode for areas without signal, a dashboard for area managers, route planning, and a sync with the accounting system. Both readings are reasonable. They are simply different systems, and the price follows the system.

Vague requests also push vendors into protecting themselves. A careful vendor adds 30 to 50 percent for the unknowns. A hungry one quotes low and plans to recover the margin through change requests. In our experience, a specific brief brings serious quotes much closer together, and what remains is a difference in team, quality, and support. That is the comparison you want to make.

You Probably Do Not Need a Formal SRS

SRS stands for Software Requirements Specification. The formal version follows a standard such as IEEE 830, since replaced by ISO/IEC/IEEE 29148, with numbered sections for functional requirements, interfaces, constraints, and traceability between them. Banks, government tenders, and large enterprise projects often require one, and in those settings it earns its keep.

Our honest view is that for most SMEs it is overkill. A 40-page SRS takes weeks to write, few people read it end to end, and it gives a false sense that everything has been decided. A brief of four to eight pages with the right sections gets you quotes you can compare, and the vendor you choose will expand it during discovery anyway. If a tender prescribes a format, follow it. Otherwise, start lean.

What a Useful Brief Contains

These sections cover almost every business system we are asked to quote, from internal tools to customer portals. The examples come from a fictional distributor with several branches.

For the main flows, the user story format forces you to say who does what and why: "As a [role], I want to [do something] so that [reason]". If that feels stiff, write a short scenario in normal sentences. Cover the unhappy paths too: stock is insufficient, the area manager is on leave, a payment fails halfway. Those cases are where estimates differ most.

Non-functional needs deserve real numbers. "Must be fast" means nothing in a quote. Twenty users during office hours and 5,000 customers during a Harbolnas flash sale are different systems. Availability works the same way: weekday office hours is cheap, round the clock at 99.9 percent uptime is not. Banking and fintech have OJK and Bank Indonesia rules on where data may be stored, so state them. Everyone else should note that the system holds personal data under UU PDP and say whether servers must be in Jakarta or Singapore is fine.

Acceptance Criteria Anyone Can Check

An acceptance criterion is a sentence that lets you answer yes or no when testing. "Reports should be easy to use" cannot be tested. "The area manager can filter the stock report by branch and date range, export it to Excel, and a report of 5,000 rows opens in under five seconds" can. Write them in plain language, as "when this happens, then that should happen", and you have done most of the work.

Two or three criteria per story are usually enough, and before quoting you only need them for the five most important flows. Keep them. The same sentences become your checklist during user acceptance testing at the end of the project.

What Not to Write

• Database design. Tables and columns are the vendor's job. Describe the information you need to record and report on, and let them model it.
• The framework or programming language. Choosing Laravel or Go for the vendor only narrows your options, unless there is a real constraint behind it.
• A list of 80 "nice to have" features. Every line gets estimated, so a long wish list inflates every quote and hides what you actually need.
• Adjectives without numbers, such as user-friendly, scalable, modern, or secure.
• Instructions like "make it like Gojek". Name the specific screen or behaviour you like, and why.

Constraints are a different matter and belong in the brief. "Our IT staff only know PHP and will maintain it after handover" or "it must run on our existing server at IDCloudHost" are facts the vendor needs, not design choices you are imposing.

Prioritise with MoSCoW

MoSCoW sorts every feature into four groups. Must have: the system is useless without it. Should have: important, but there is a workaround for a while. Could have: pleasant, and the first thing to drop. Won't have this time: agreed and written down as out of scope for now. The DSDM method that MoSCoW comes from suggests keeping Must items to no more than about 60 percent of the effort, so there is room to absorb surprises.

This is where many briefs go wrong. When everything is marked Must, the label stops meaning anything and the vendor is back to guessing. A useful test is whether go-live would wait for that feature. If it would not, it is not a Must. Ask vendors to price the Must and Should groups separately, so you can see what the first phase really costs.

Sketches Are Enough for Wireframes

You do not need a designer to show what you mean. A photo of a hand-drawn screen, a rough layout in Excalidraw, or a few frames on the free Figma plan are fine. Draw the three to five screens that matter most, such as the form your staff use all day and the report your director checks every morning.

Existing material often beats new drawings. Attach the Excel files your team uses today, photos of paper forms, sample reports, and screenshots of the WhatsApp group where orders get approved. They show the real fields and exceptions better than any description.

Writing the Brief Step by Step

1. 1Write the problem and the goal in half a page, including one or two numbers you want to change, such as hours spent per week or error rates.
2. 2List the roles and how many people are in each. Spend 30 minutes with one person from each role and note what they actually do today.
3. 3Write 5 to 15 user stories or scenarios for the main flows, plus what should happen when things go wrong.
4. 4Collect existing material: spreadsheets, paper forms, reports, screenshots, and any API documentation from systems such as Accurate or your payment gateway.
5. 5Add the non-functional needs with numbers, the budget range, the deadline, and which of the two is firmer.
6. 6Sort the features with MoSCoW and write acceptance criteria for the Must items.
7. 7Sketch the most important screens.
8. 8Give it to a colleague who was not involved. If they can explain the system back to you, it is ready to send.

If two vendors read your brief and picture the same system, the brief has done its job.

From Brief to Contract Scope

Once you choose a vendor, the brief is refined into a specification, usually during discovery, and attached to the contract as the scope. Anything outside it is a change request: you describe the change in writing, the vendor estimates it in days and Rupiah, and work starts only after you approve. A clear brief makes change requests rarer, and it makes the remaining ones less of an argument about what was "obviously included".

If you cannot find the time to write the brief, or the process is too tangled to describe alone, pay for a discovery phase instead. A vendor runs workshops with your team for two to four weeks and delivers process maps, wireframes, a specification, and a firm estimate. The price varies, but around 5 to 10 percent of the expected build cost is common. Make sure you own the output and can take it to another vendor. Sometimes discovery ends with the conclusion that you do not need custom software at all, because Accurate or Jurnal plus a small integration covers the need. That is still money well spent.

At Salamun Teknologi we receive briefs in every shape, from a WhatsApp voice note to a 60-page tender document. If yours is still rough, we are happy to read it with you and point out the gaps that would make quotes drift, before you send it to anyone, us included.