What a buyer has to write is not a specification. It is the problem. And the problem is the one thing a vendor cannot write for you — you are the only person standing where it happens.
This is a guide to the requirements and the RFP a buyer prepares before commissioning software, organised around a question that comes before "what do I write": what can I write, and what can't I? The whole commissioning process is covered in the complete guide to commissioning system development; money is covered in market rates and total cost of ownership. This article stays on the documents a buyer writes before work starts.
1. The real failure is not the deadline or the budget
First, the reason requirements deserve your time, in numbers.
Nikkei Computer's project survey (1 March 2018 issue) found that of 1,745 system introduction/replacement projects, 52.8% were successes and 47.2% were failures. A "success" there had to satisfy three conditions: schedule, cost, and satisfaction.
In the same magazine's 16 October 2014 survey, where success meant "kept to the originally planned quality, budget and delivery date (QCD)," the success rate was 75%.
Put the two definitions side by side:
| Definition of success | Rate | Survey |
|---|---|---|
| Kept to QCD (quality, budget, delivery) | 75% | Nikkei Computer, 16 Oct 2014 |
| Schedule, cost, and satisfaction | 52.8% | Nikkei Computer, 1 Mar 2018 (1,745 projects) |
Different years, different samples — you cannot simply subtract one from the other. But both point the same way:
The deadline held, the budget held, and the people who had to use it were not satisfied.
That is the closest thing to what a failed commission actually looks like. Nothing crashed. Nothing overran. What got built was not what was wanted — and that is not a technical problem. It is a question of what was communicated before anyone started.
IPA's data puts the median project duration at 10.1 months (N=1,396). Where those ten months end up is decided by the documents exchanged in the first few weeks.
So the order doesn't go wrong
Free checklist: 20 questions that gauge a vendor's real technical strength
2. The four things only a buyer can write
Requirements sound like an intimidating technical document, and that is why people freeze. The part a buyer writes is not technical. It is the facts of the business.
Split it this way:
| Written by | Content | |
|---|---|---|
| Facts of the business | Buyer | Who, when, what hurts, how it is worked around today |
| Design of the solution | Vendor | Which screens, data structures and processes solve it |
A buyer who writes the solution too has just discarded the expertise they are paying for. A buyer who withholds the business facts leaves the vendor guessing. "That's not what I meant" is almost always a failure of this handoff.
Here are the four, concretely.
2-1. Who uses it — roles and headcount
"Our staff will use it" is not enough. Break it down by role, with numbers.
Sales desk, 3 people (daily / desktop). Warehouse staff, 8 people (daily / phone, wearing gloves). Accounting, 1 person (month-end only / desktop). Owner, 1 person (weekly / phone).
No vendor can guess that the warehouse staff wear gloves. Knowing it changes the button sizes and the input method. Adding "when, on what device" to each role raises the precision of every proposal you get.
2-2. What hurts right now — symptoms, not solutions
This is the most important item and the easiest to get wrong.
| ❌ Written as a solution | ✅ Written as a symptom |
|---|---|
| "We want an inventory management system" | "We phone the warehouse to check stock, which costs 30 minutes a day, and because the number is only true at that moment we discover shortages after accepting an order two or three times a month" |
| "We want to put customer records in a database" | "Each rep keeps their own customer list in Excel, and when someone left we could not hand it over" |
| "We need it to work on phones" | "Staff have to come back to the office to enter anything, so reports land a day late" |
Handed the right-hand column, a vendor can propose something the left-hand column would never have surfaced — perhaps not an inventory system at all, but simply showing the live warehouse count on the order screen. The cheaper answer only appears if you describe the symptom.
2-3. How you work around it today
Every problem has a workaround stuck to it: duplicate entry, a handwritten note, an Excel macro only one person understands, overtime before the monthly close.
The workaround is the real requirement. Writing them down reveals two things at once:
- How much it actually hurts (30 minutes daily versus once a month)
- Which steps disappear on migration — and whether some other process quietly depends on them
Skip this, and you get the failure where the system is built correctly and the floor cannot let go of the workaround, so you end up running both.
2-4. What you are not asking for
A sentence that narrows scope is worth more than one that widens it.
Out of scope: accounting-software integration, a native mobile app (web only), multi-site support (head office only), migrating data older than three years.
With this written down, every vendor prices the same thing. Without it, each one silently assumes something different and the quotes stop being comparable. If you plan to collect competing bids, this item is mandatory — see also how to run a competitive bid.
3. A minimum RFP
Thicker is not better. Three to five pages is plenty. What matters is not coverage but whether a vendor has what they need to make a judgement.
Seven items:
1. Background and objective
- Where the business stands, and what this system should move (revenue / time / risk)
2. Current process and what hurts
- Everything from 2-1 to 2-3
3. Scope, and what is explicitly out of scope
- Everything from 2-4
4. Users and volume
- Headcount by role; expected record counts (orders per month, SKUs, …)
5. Budget range and target timing
- A range, not "TBD"; timing with a reason ("before the autumn peak")
6. What you want proposed
- Team, phases and milestones, cost breakdown, assumptions and exclusions, maintenance scope
7. Selection criteria and schedule
- What you will weigh, and when you decide
Should you state a budget? Yes
People hide the budget for fear of being taken advantage of. It backfires. With no range to aim at, a vendor proposes generously to avoid being wrong, every bid comes in high, and none of them are comparable.
Given a range, a vendor designs to it. Write "3–5M yen, highest-value parts first" and you get a prioritisation back — which is the single most useful thing a proposal can contain.
Say how you want the proposal shaped
Ask explicitly for a cost breakdown and for assumptions and exclusions. Fail to ask, and a single total arrives on a page, and you are left comparing estimates whose contents you cannot read.
4. What not to write — over-specification
The most expensive habit in an RFP is specifying technology without a reason.
"Please use MySQL for the database."
Write that, and a vendor holding a better-suited option quietly prices MySQL. The range of proposals collapses, and you can now only receive answers from inside your own knowledge — which is precisely what you were paying them to exceed.
Where a constraint is real, write the reason rather than the instruction.
| ❌ Instruction only | ✅ With the reason |
|---|---|
| "Use MySQL" | "Our core system runs on MySQL and needs a nightly feed" |
| "Build it on AWS" | "Internal policy requires data to stay in-country" |
| "Build it in React" | "Someone in-house will make small changes later and they read React" |
With the reason on the page, a vendor can offer several ways to satisfy the constraint. With only the instruction, you get one. And an instruction you cannot justify is usually something you heard somewhere, not a requirement of your business.
The same holds for screens. "Put this button here" produces worse design than "this task should take three clicks or fewer."
5. Where ambiguity is fine, and where it is not
Requirements do not all need to be nailed down. Some parts must be; others are better left open.
| Settle before commissioning | Fine to leave open |
|---|---|
| Scope, and what is out of scope | Detailed screen layout |
| Roles and permissions (who sees what) | Button labels and colours |
| Kinds and volumes of data | Sort order and filters on lists |
| Legal and internal-policy constraints | Fine formatting of printed output |
| Acceptance criteria (next section) | Future enhancements |
The left column is what forces a redesign if changed later. The right column is what you should decide after seeing something running.
Note that permissions sit on the left. "We'll separate the roles later" can mean changing the data model itself. Conversely, trying to freeze screen layouts up front burns weeks and buys very little precision.
And — where something is unsettled, say that it is unsettled. Hide it while asking for a fixed price and the vendor either pads for risk or bids low and bills later. Both cost you. Contract shapes are covered in fixed-price versus time-and-materials.
6. Write acceptance criteria before you sign
The most deferred item, and the one that causes the most conflict.
Put "what counts as finished" in writing before the contract is signed. Leave it until after launch and it gets decided by whoever holds the stronger position.
The trick is not to list features. Write it as the business making one full lap.
| ❌ A list of features | ✅ Traced through the business |
|---|---|
| "Has order-entry functionality" | "An order taken by phone and entered by the sales desk appears on the next morning's shipping list" |
| "Has inventory functionality" | "Confirming a shipment decrements stock, and the order screen shows the new figure" |
| "Has permission management" | "Signed in as warehouse staff, orders belonging to another company are not visible" |
The right column is the acceptance script. Nobody has to improvise on the day, and the vendor knows exactly what they are aiming at. Both sides gain.
As the third row shows, security can be written as a business check too. "Another company's data is not visible" verifies the permission design — the single most expensive thing to fix after the fact.
Summary: the buyer's job is to hand over facts
Three points.
- The real failure is "on time, on budget, and nobody is happy." 75% success under a QCD definition, 52.8% once satisfaction counts. That gap is a requirements failure.
- Buyers write the facts of the business; vendors design the solution. Who, when, what hurts, how it is worked around — nobody else can write those four.
- Write reasons, not instructions. A reason gets you options; an instruction gets you one answer.
Requirements definition is not the work of producing a technical document. It is the work of putting into words what actually happens on your floor. Do that, and three to five pages will attract genuinely good proposals.
There is a pre-commissioning checklist to help you organise before you start writing. If you would rather work through "what should we write in our case" together, the free 30-minute DX assessment covers taking stock of the problems and putting them in priority order.