The single most common thing we hear at the start of a conversation is some version of: I don’t know how to explain this properly.
You almost certainly do. What you have been told is that describing software requires a specification — a document with numbered requirements, user stories and acceptance criteria — and that producing one requires skills you do not have. That is true of the document. It is not true of the description.
Here is what actually needs to be true for someone to build the right thing.
1. Who uses it, and what are they trying to get done?
Not job titles. The specific person, at the specific moment they open the thing.
Weak: “Managers and staff will use it.”
Strong: “A dispatcher at 6am, working out which of eleven drivers can take an emergency job that just came in.”
The second version contains a screen, a sort order, and an urgency. The first contains nothing.
2. What happens today, and where does it hurt?
Describe the current process honestly, including the ugly parts. The spreadsheet. The shared inbox. The person who knows how it really works. The workaround everyone uses and nobody documented.
The pain is the requirement. If you tell us the process without telling us which step ruins people’s day, we will build all the steps equally well — including the ones that were never the problem.
3. What must be true for it to be worth having?
One or two sentences. If the thing did nothing else, what would make it worth using?
Weak: “It should improve efficiency.”
Strong: “A driver should never have to phone the office to find out what they are doing next.”
That single sentence tells us the driver’s view is the centre of the product, that it has to work on a phone, that it has to be current, and that it has to work in bad signal. Four decisions from one sentence.
4. Who is allowed to see what?
The question people skip, and the one that most often forces a rebuild.
Can a driver see other drivers’ jobs? Can a customer see the price you paid your supplier? Can a branch manager see other branches? Can someone who has left still get in?
You do not need to design a permission model. You need to say who must not see something, because that is where the expensive constraints live.
5. What happens when things go wrong?
Real processes are mostly exceptions. The happy path is the easy part.
- What if the customer cancels after the job has started?
- What if two people edit the same record at once?
- What if the payment fails?
- What if the file is 400MB?
- What if someone approves it by mistake?
You know these answers — they are what your team does today. Saying them out loud is worth more than any diagram.
6. What does it have to talk to?
Your accounting system, your CRM, your supplier’s portal, your payment provider, the calendar everyone actually uses.
Most of the value in internal software is that it stops people retyping things from one system into another. Naming the systems early also surfaces the hard news early — if something is a closed product with no way in, everyone should know that before planning around it.
What you do not need to do
You do not need to describe screens. If you have a picture in your head, say it — it is useful. But the screens follow from the answers above, and describing them first often locks in a worse design than the one the constraints would have produced.
You do not need to know what is possible. That is our problem. Ask for what you want; we will tell you what it costs and whether there is a cheaper way to get ninety per cent of it.
You do not need to be consistent. You will contradict yourself. That is normal and it is useful — contradictions are where the interesting requirements hide.
You do not need to get it right. You will be wrong about something, and the entire process is designed around finding that out in week one rather than month six.
A worked example
Here is a complete, sufficient description. It is four sentences.
I need my drivers to see tomorrow’s jobs on their phone, tick them off as they go, and have the customer get an invoice the moment a job is done. Right now the dispatcher texts them the night before and half of them lose it. Drivers must not see each other’s pay rates. It has to work when they have one bar of signal in a basement.
That is enough to start. It contains the user, the moment, the current pain, a hard permission constraint, and an environmental requirement that changes the architecture.
Nobody wrote a specification. Somebody just explained their business.