How to write software requirements if your expert is busy
Filip Papranecfounder of Digitaliko
Software requirements do not have to be written by the expert who knows the process. Someone else writes them up from a short conversation, the expert reads the draft and says yes or no. One page is enough for the first version, and the most important line on it says how you will know it is done.
Below: why the brief often never gets written, what it must contain, a five-step method and when to freeze it. The article is for owners and department heads whose best process person has no time to write.
Why does the brief never get written?
Almost every company has someone who knows exactly how a process should work. They know which customer wants their invoice done differently and what must never be overwritten in the spreadsheet. They run that process all day.
That is exactly why they have no time to describe it. The supplier waits for the brief. The expert waits for a free afternoon. It never comes, and the process keeps running by hand.
With AI, development got faster. This waiting did not. Today the bottleneck is often not programming but the fact that nobody can say precisely what should be built. Fred Brooks wrote it back in 1987:
The hardest single part of building a software system is deciding precisely what to build. No other part of the work so cripples the resulting system if done wrong.
The answer is not to send the expert a requirements template. They will not fill it in, for the same reason they never wrote the document. The answer is to take the writing off their hands.
A conversation instead of a document
An expert can talk about their work without any preparation. Let them show how they do it and ask questions. Someone else turns the conversation into a draft, and the expert only reads it. They will find time for that.
A conversation over real work works best. The expert opens the email, the spreadsheet or the program and shows the latest case. Along the way they mention things they would never put in a document, because to them they are obvious.
A prototype is even better than a document. When the expert clicks through the first version, they say within minutes what is wrong. On paper, that would take a week of comments.
What must a software brief contain?
The brief for a first version fits on one page. Each part answers one question you ask the expert in the conversation:
| Part of the brief | Question for the expert | What a good answer looks like |
|---|---|---|
| How it works today | Show me the latest case from start to finish. | An order comes in by email, gets retyped into a spreadsheet, then into invoicing. |
| What the system should do | Which step costs you the most time or mistakes? | Retyping the order from the email into the spreadsheet. |
| Data | Where do you get the information and where do you enter it? | From the email and the price list, entered into the orders spreadsheet. |
| Who uses it | Who works with it and who only looks at the result? | Two people in the office; the manager looks at the overview. |
| Exceptions | When do you do it differently? | Regular customers get a different price; orders above a limit need the manager's approval. |
| What stays out of the first version | What can wait? | The link to the warehouse and a mobile version. |
| How you will know it is done | When will you say it works? | The order is in the spreadsheet without retyping and a person only checks it. |
The "what stays out of the first version" row matters as much as the others. Without it, the first version keeps growing until it becomes a whole system. And the last row decides whether the brief can be fulfilled at all.
How do you write a brief step by step?
The whole method takes the expert a few hours spread over a week, not a week of writing:
01
One-hour conversation
The expert shows the latest real case and answers questions. The conversation is recorded or noted down; the expert writes nothing.
02
A one-page draft
Someone else writes the brief from the conversation, following the table above. Within two days, while everyone still remembers the details.
03
Yes or no
The expert reads the draft and marks what is wrong. They correct it, they do not start over.
04
One line on when it is done
You phrase it together so that it can be checked. Without it, the brief is not finished.
05
A prototype to click through
The expert clicks through the first version on sample data and says what is missing. That is the last correction to the brief.
The second step makes the difference. Whoever writes it up has to know how to ask questions and must not fill gaps with guesses. Where an answer is missing, they write down a question, not an estimate.
When should you freeze the brief?
A brief that changes every day is not flexibility. It is a brief written during construction. With people you could get away with it, because a developer noticed the change and asked. An AI agent does not ask. It builds what is in front of it, even if something else was true yesterday.
After that you can change as much as you like. The changes are visible, and everyone working on it knows what counts.
What does this look like in practice?
A good brief is usually shorter than people expect. In invoice processing in accounting it came down to one step: an invoice arrives by email as a PDF and someone retypes it by hand. The goal was simple to state: the invoice is entered without retyping.
- Processing one invoice. Previously 10 to 15 minutes of retyping by hand.
- under 1 min
A brief narrowed down like this can be built fast and tested on real data. Which step to pick first is in our article Which business processes should you automate first?. If the process lives in a spreadsheet today, see also When is Excel no longer enough for a business?
Is your brief ready?
Tick what you already know about the process you want to hand over to a system:
When this is not enough
- Nobody does the process the same way twice. If everyone handles every case differently, agree on the method first. Software will not unify what people have not unified.
- It is a whole system at once. One page is enough for the first version of one process, not for replacing an entire business system. Split a bigger project into smaller steps.
- Someone who was not in the conversation decides. If the brief is approved by management who do not run the process, invite them at least to click through the prototype.
Want a brief without the writing?
With a process demo we go through the work with the person who does it. From you: an hour of their time and one meeting where we click through the prototype together. Within 10 working days you see how a system would do your manual work.
If you are building a new product rather than an internal process, start with the one-page brief for the first version. If you’d rather talk first, book a 15-minute intro call.
Who is that person in your company whose brief everyone has been waiting on for six months?
In short
- The expert does not have to write the brief. An hour of conversation, a draft by someone else and their yes or no are enough.
- One page is enough for the first version: how it works today, what the system should do, data, exceptions and what can wait.
- The most important line says how you will know it is done.
- One place, one person who says “this is what counts”, and a date after which a change is a new task.
Frequently asked questions
Who should write software requirements?
Not necessarily the person who knows the process. Their job is to explain the work and confirm the draft. Someone else can write it up from a short conversation: an analyst, a supplier or a colleague who knows how to ask questions.
How long should a software brief be?
One page is enough for the first version: what a person does today, what the system should do, where the data comes from, who uses it, what stays out of the first version and how you will know it is done. Nobody finishes reading a long brief.
What is the most important part of a brief?
The line that says how you will know it is done. For example: an order from an email lands in the system without retyping and a person only checks it. Without that line, a brief can be worked on forever.
What if the requirements change during development?
Changes are normal. What matters is one place where the brief lives, one person who says "this is what counts", and a date after which every change becomes a new task instead of an edit to the old one.
Can you start without a brief?
You can start with a prototype. The person who does the work clicks through it and says straight away what is wrong. A clickable prototype is often a better brief than a document, because it shows what is missing.
Ask AI about this article
The AI also draws on our other articles and experience from real projects.
ChatGPTClaudePerplexity
