Most software that disappoints doesn’t fail because it was badly built. It fails because it was built to the wrong brief, or to no brief at all. The developer built what they understood, the business needed something else, and nobody found out until the money was spent.

The fix costs almost nothing: write down what you need before you pay anyone. You don’t need special training or templates. You need a few honest pages, in your own words.

Why it matters

  • Quotes become comparable. Three suppliers quoting from the same document can be compared fairly. Three suppliers guessing can’t.
  • The price holds. Most price rises come from things nobody mentioned at the start.
  • You can check the result. When the software arrives, you test it against your own list, not against someone’s memory of a meeting.
  • You think it through. Writing it down surfaces the awkward cases while they’re still cheap to handle.

What to write down

1. The problem, in one paragraph

What’s going wrong today, and what would be different if the software worked? “We lose orders because they arrive by WhatsApp, phone and email, and nobody sees all three” is a perfect start.

2. Who will use it

List each kind of person: customers, staff, managers, drivers, guards. For each one, note what device they’ll use and where. A driver on a budget phone in a moving vehicle needs something very different from a manager at a desk.

3. What each person needs to do

Write simple sentences in this shape: “As a [person], I need to [do something], so that [reason].” For example:

  • As a customer, I need to see my order’s status, so that I don’t have to call.
  • As a manager, I need to see all of today’s orders on one screen, so that I can plan deliveries.

4. The rules your business follows

Prices, discounts, approvals, opening hours, who can see what. These rules are where most of the hidden work lives, so write down every one you can think of.

5. What must never go wrong

Losing a payment, showing one customer another’s details, a gate letting in someone it shouldn’t. Name these clearly. They decide how carefully each part must be built and tested.

6. What’s out of scope

Say what the software will not do, at least for now. It’s the cheapest way to keep a project on budget.

7. How you’ll know it’s done

A short list of checks you’ll do before you accept it. For example: “A new member of staff can place an order without help.”

Keep it plain

Don’t try to sound technical. Your job is to describe your business; the developer’s job is to turn that into software. Plain language is easier to check, and harder to misunderstand.

When to get help

If the project is large, or several departments are involved, it can pay to have someone help you do this properly. That’s what requirements engineering is: asking the questions, watching how work really happens, and turning it into an agreed list before anyone builds. It’s also the second stage of how we work. Tell us what you need, and we’ll start with the questions.