A method organised around practical checks.
Each step gathers the facts to establish before moving to the next.
A requirements specification has a single purpose: to obtain proposals that can be compared. Not complete proposals, not appealing proposals — comparable ones.
This is harder than it looks, because every vendor responds with its own vocabulary, structure and strengths. Without an imposed framework, you will receive four fifty-page documents discussing different things, and you will choose on instinct.
This guide provides a method and template. It applies to warehouse, transport, maintenance or sales-management projects — the structure is the same.
What a requirements specification is not
It is not a list of features. A feature list is the most common and least useful format. Every vendor ticks every box. You obtain four green tables and no information.
It is not a description of your current organisation. Describing everything you do today in detail produces a quote to reproduce the existing operation — including its flaws.
It is not a confidential document. A vendor that does not understand your activity can offer nothing but a catalogue. Withholding information results in an imprecise response.
What a requirements specification must contain
Five sections, in this order. Thirty to forty pages are more than enough — and twenty are often better than one hundred.
SECTION 1 — Why this project
One page. This is the shortest and most decisive section.
WHAT IS NOT WORKING TODAY
Three to five concrete difficulties, described as situations.
Example: ‘On average, we discover a stock variance three
weeks after the movement that caused it.’
WHAT IS TRIGGERING THE PROJECT NOW
Growth, a new site, a new customer, a regulatory
obligation, the end of a tool’s life or the departure of a key person.
WHAT WE EXPECT IN TWELVE MONTHS
Two or three verifiable outcomes.
This section enables an honest vendor to tell you, from the first reading, that its product is not suitable. That is a service, and it cannot be provided if you do not say why you are consulting vendors.
SECTION 2 — Your activity in figures
This is the section vendors read first, because it determines everything: architecture, load and price.
---------------------- ----------------------- ----------------------- Data Value Three-year horizon
Number of sites
Area per site
Number of locations
Active items
Receipts per day (average / peak)
Orders per day (average / peak)
Lines per order (average)
Concurrent users
Mobile terminals
Operating hours
Seasonality (strong month / weak month) ----------------------- ----------------------- -----------------------
The ‘peak’ column is the most important. A system is sized for peaks, not averages. A warehouse processing 400 orders a day on average and 1,800 in November needs a system capable of handling 1,800.
The ‘three-year horizon’ column prevents undersizing. If you plan to open a second site, say so, even if it is outside the project scope.
SECTION 3 — Your processes, one page each
This is the heart of the document. One process, one page, using the following template:
PROCESS · [name]
CURRENT FLOW
Five to ten steps, using action verbs, stating who does what.
VOLUMES
Number of occurrences per day, average duration, people assigned.
MANAGEMENT RULES
The automatic decisions the system will have to make.
Example: ‘Location assignment follows turnover:
class A in the lower zone, aisles 1 to 4.’
SPECIAL CASES
Real exceptions, not every imaginable exception.
WHAT CAUSES US PROBLEMS
One to three sentences. This guides the response.
WHAT MUST BE PRESERVED
The practices that matter to you and are non-negotiable.
The processes to cover depend on your scope. For a warehouse: carrier reception, receiving, putaway, replenishment, picking, checking, shipping, stocktaking and returns. Nine pages.
The final heading — what must be preserved — is the one that best protects your projects. A vendor that knows what is non-negotiable will say whether it can do it, or whether custom development will be needed. Discovering that after signature is expensive.
SECTION 4 — Your constraints
Product constraints. Batches, serial numbers, dates, temperatures, hazardous properties, unusual formats and regulated products.
Regulatory constraints. Mandatory traceability, required documents, data-retention periods and periodic inspections.
Customer constraints. Labelling requirements, imposed exchange formats, service commitments and tracking portals.
Technical constraints. Existing systems to retain, existing equipment (terminals, printers, automation), available infrastructure and internal hosting policy.
Human constraints. Teams’ confidence with IT, languages spoken, staff turnover and the ability to release people for the project.
The final category is almost always absent from requirements specifications, and almost always the one that explains failures.
SECTION 5 — What you expect from the response
This is the section that makes proposals comparable. Without it, everything else is lost.
MANDATORY RESPONSE STRUCTURE
Process coverage
For each of our processes described in section 3, state:
Standard / Configuration / Custom development / Not covered
If configuration: what, in one sentence
If custom: estimated effort in days
Handling of points identified as problematic
For each ‘what causes us problems’ item, explain concretely how
the proposed solution addresses it.
Architecture and sizing
Based on our peak volumes.
Implementation approach
Phases, durations, milestones and deliverables.
Effort expected from us
Number of days by profile (management, operations, IT),
broken down by phase. A quantified response is required.
Data migration
What is migrated, how, with what effort, and what
remains our responsibility.
Detailed budget
Licences or subscription: by user, site and module
Implementation: by phase
Custom developments: line by line
Training
Annual maintenance
Cost of an additional site
Cost of ten additional users
Cost of an average enhancement after go-live
Comparable references
Two customers of a similar size and sector who can be contacted.
What you cannot do
The points in our requirements specification that fall outside your
scope or experience.
Point 9 always causes hesitation. Yet it is the most useful part of the consultation: a vendor that answers honestly gives you valuable information, and a vendor that answers ‘nothing’ gives you another kind.
The last two lines of point 7 — cost of an additional site and cost of an enhancement — determine your five-year bill. They are never negotiated as well as they are before signature.
The comparison method
Once the responses arrive, resist reading them from start to finish. Build a single table.
--------------- -------------- -------------- -------------- -------------- Criterion Weight Vendor A Vendor B Vendor C
Standard coverage (% of processes)
Number of custom developments
Effort required from our teams (days)
Implementation duration
Total five-year budget
Cost of an additional site
Quality of references
Understanding of our problems ---------------- -------------- -------------- -------------- --------------
Set the weights before reading the proposals. This is the only protection against reconstructing a scoring grid afterwards so that it favours the candidate people already preferred.
Three lines deserve particular attention:
The number of custom developments is the best indicator of project risk. Every customisation brings a delay, a maintenance cost and an upgrade constraint.
The effort required from your teams is the most underestimated item. A vendor that announces twenty days when the others announce sixty is not doing better: it has not measured, or it is not telling you.
The five-year budget often differs from the initial budget in the opposite order. The cheapest at signature is regularly the most expensive in the end.
The demonstration: how not to be lulled
A standard demonstration shows a product at its best, with clean data and a rehearsed scenario. It teaches you nothing.
A useful demonstration follows your scenario, using your data.
Prepare a test data set before the demonstration:
twenty of your real items, with their particularities;
three of your real orders, including one complicated case;
one exception you encounter every week.
Then ask:
Process this order end to end, screen by screen.
Show us the exception. What does an operator do?
Change this management rule in front of us. Who can do it, and with what training?
A user makes a mistake at this stage. How is it corrected?
Show us the screen a picker will see on their terminal.
Questions 3 and 4 are the most revealing. The ability to change a rule without calling the vendor determines your autonomy for the next ten years. And error handling is the best indicator of product maturity: young software handles the standard case well.
The timeline
---------------------------------- ----------------------------------- Stage Realistic duration
Writing the requirements specification 3 to 6 weeks
Consultation (time given to 4 weeks minimum vendors)
Analysing responses 2 weeks
In-depth demonstrations 3 weeks
Reference visits 2 weeks
Negotiation and contracting 4 to 8 weeks ----------------------------------- -----------------------------------
That is around five months from launch to signature. The timeline can be compressed, but every stage removed reappears later, generally during acceptance testing.
Reference visits are the stage most often sacrificed. They deliver the most information per hour invested: an operator that has used the product for two years will tell you in one morning what no demonstration can show.
Three costly mistakes
Consulting too many vendors. Beyond four, the analysis becomes superficial and helps no one. Three serious candidates are better than eight files skimmed over.
Not involving operations in the writing. A requirements specification written by management and IT describes a theoretical warehouse. Team leaders know what actually happens, and only they know it.
Negotiating price before deciding scope. A discount obtained early in negotiations is always recovered later, through custom development or implementation days. Fix the scope, then discuss the price.
A final comment
The best requirements specification we ever received was twenty-two pages long. It described eight processes, clearly stated what was wrong and asked nine precise questions.
The worst was two hundred and forty pages. It was an extract from a standard feature list, purchased as-is. No one in the company had read it in full.
Length measures nothing. The quality of a consultation is measured by the number of questions vendors cannot answer from a catalogue.
