How to write a requirements list before you buy business software

The usual way small businesses buy software goes like this. Someone sees a demo, it looks good, a few colleagues agree, and a contract is signed. Six months later the team is working around it with spreadsheets, because the system does what the demo showed and not what the business needed.

A short requirements list prevents most of that. It does not need to be a hundred pages. For most SME purchases, a few pages written in plain English is enough, as long as every line is specific and testable. Here is how I write one.

Start from the problem and the process

Before you list a single feature, write two short paragraphs. The first says what problem you are trying to solve and how you will know it is solved. The second describes the process the system will support, from the trigger to the end, and who does each step.

If the process has not been mapped, map it first. Requirements written without a process tend to be a wish list of features. Requirements written from a process describe what each step needs, which is what you are actually buying.

Sort into must, should and could

• Must: without this the system is no use to you. A product that fails a must is out. Keep this list short, ideally fewer than fifteen items.
• Should: important and expected, but you could work around it for a while. These are scored, not used to rule products out.
• Could: nice to have. Useful for separating two otherwise equal products, never a reason to choose a weaker one.

Be strict about musts. If everything is a must, nothing is, and you will either rule out every product or quietly ignore your own list.

Write requirements you can test

A good requirement describes what a person needs to do, in a specific situation, in a way a supplier can show you working. A bad one describes a feeling or a feature name.

A useful habit is to start each requirement with a role: 'A warehouse picker must be able to...', 'The finance manager should be able to...'. It keeps the list grounded in real work and makes it obvious who should test each item.

The areas people forget

Most lists cover the day-to-day screens well and miss the things that cause trouble later. Add a section for each of these.

• Data: what records you will hold, roughly how many, what has to be moved from the old system and who will clean it before it moves.
• Integrations: which systems it must exchange data with, in which direction, how often, and which system holds the master copy.
• Users: how many people, in which roles, what each role can see and change, and whether anyone works offline or on a phone.
• Reporting: the five or six reports or numbers you look at every week or month, written out so a supplier can build them in a demo.
• Security: sign-in with your existing accounts, multi-factor authentication, where data is stored, and what audit trail is kept of who changed what.
• Exit: how you get all of your data out, in what format, at what cost and with how much notice. This is the requirement most often skipped and most often regretted.

Score suppliers against the list

Put the requirements in a spreadsheet so every supplier is judged on the same lines. Copy these columns across the top of a sheet.

• Requirement: the testable sentence, one per row.
• Priority: must, should or could.
• Supplier columns: one per supplier, scored 0 for not met, 1 for met with a workaround or extra cost, 2 for met as standard.
• Evidence: how you know, such as 'seen in demo on our data' or 'supplier's written answer'.
• Notes: any cost, condition or concern.

1. 01

   Step 1: Apply the musts first

   Any supplier scoring 0 on a must is out, however good the rest looks.

2. 02

   Step 2: Total the shoulds

   Add up the scores on the should items for each remaining supplier. This usually separates the field.

3. 03

   Step 3: Use the coulds as a tie-break

   Only look at could items when two suppliers are close on the shoulds.

4. 04

   Step 4: Weigh against total cost

   Compare the shortlist on cost over three years, including licences, set-up, support, integration and the cost of leaving.

Demo on your own data

A supplier's standard demo shows their product at its best with their data. Ask instead for a scripted demo: send three or four real scenarios from your requirements list, with real, anonymised examples from last month, and ask each supplier to walk through them. The awkward order, the customer with special pricing, the job that changed halfway through. Score what you see, not what you are told.

Make sure the people who will use the system every day are in the room, not just the people signing the contract. They will spot the extra clicks and missing fields that a director will not.

Before you sign

Attach the requirements list, and the supplier's answers to it, to the contract or order form. If a supplier said a must was met as standard, that statement should be in writing. It costs nothing if they were right and protects you if they were not.

Writing the list will often make the decision clearer by itself. Sometimes it shows a product is right. Sometimes it shows that configuring or connecting what you already have would do the job, or that what you need is unusual enough to build. The build or buy check helps you test that before you start booking demos.