Writing business
requirements
Write the business requirements well. Scope them small. Everything else, including the technology, gets easier.
Scroll, click, or use the arrow keys to move through.Scroll, or use the arrows and dots to move through.
All of the value is in the business requirements.
AI is very good at applying technology to a well thought out scope. It cannot supply the scope.
The technical requirements, the database, the build plan, the code, the deploy: those are largely automatable once the rules exist. The part that is not automatable is deciding what the thing does, for whom, and what counts as working.
That is where the time goes.
AI makes a process faster, not better.
A bad process automated is more bad, faster. The errors arrive sooner and in greater volume. Software doing it makes them harder to question.
Writing the requirements is where the process itself gets examined. Most of the value people attribute to an AI project was created in the hour someone sat down and described how the work actually happens.
Everyone in the room can read it, argue with it, and decide whether it is worth building.
Technology belongs as a source. It does not belong as a step or a tool.
In: the source
The invoice records in the accounting database. The contract files in the shared drive. The deals in the CRM. Naming it precisely is what establishes whether the data can be reached at all.
Out: the step or the tool
The nightly job that queries the table. The framework it gets built in. The store the text is indexed into. Those follow from the requirements rather than preceding them.
Written in, build decisions settle the architecture before anyone has established what the thing does. They also stop the people who know the work from reading the document.
One testable sentence.
Overdue invoices over thirty days appear in the list, each with a drafted email naming the invoice number and the amount, and the totals reconcile with the accounting export.
That sentence is what ends the build. Without one, finished is a matter of opinion. The opinion moves every time someone new looks at the output.
The smallest version that is useful.
Most bad projects start with requirements that are enormous and never say what the first working version is.
The goal is chasing overdue invoices. Version one is a list of who is overdue and a drafted email for each, from an export somebody pastes in. That is useful on Monday.
- Read from accounting directly
- Send automatically
- Escalate at sixty and ninety days
- Run on a schedule
- A dashboard
Every one of those is real. None of them is version one. Answer for now, not for eventually.
One goal, written down, with small steps against it.
Each step gets its own one-page document. Each step is useful on its own before the next one starts.
The goal has to be written down. On a real project it lived in a chat history instead. The documents recorded a rule without recording why the rule existed, so nothing could be checked against it.
The build plan serves the business requirements, not the other way round.
One: business requirements
What it does, for whom, the inputs, the rules, the outputs, and what done means. Written by the business.
Two: technical requirements
Where it runs, how it runs, security and access. Follows from document one, and is often a pointer to a standard.
Three: the build plan
The stages, in order, and which requirement each one satisfies. Written by the AI and read by you.
The plan is checked against document one at every stage. When the two disagree, the plan is wrong.
Write document one well and the rest of it gets cheap.
Six parts, one page, technology only where it names a source, and a version one small enough to be useful on its own. AI will apply technology to that scope all day. It cannot tell you what the scope is.