A request comes in: "we need an Excel export of orders". The technical team builds it. Three weeks later nobody uses it, because the real need was to know every morning which orders were going out late. The file was simply the solution the person had pictured. Translating business needs into technical requirements is about avoiding exactly that: state the problem before the tool, then turn it into something a technical team can build and check.
Over twenty years of projects I have spent a good share of my time on both sides of that table, first on the client side and then on the delivery side, and today I work alone: I design and build things myself. So I cannot hide behind "the business wasn't clear" or "the developers didn't understand". Here is the method I use, what it has saved me from, and where it falls short.
01Why business needs get lost between the business and the technical team
The business and the technical team do not talk about the same things. The business talks about customers, lead times, margins and mistakes that cost money. The technical team talks about fields, feeds, APIs and edge cases. In between, everyone translates in their head, and each translation loses a little meaning.
Three losses come up almost every time. First, the request is phrased as a solution (an export, a button, an email alert) and the reason disappears. Second, a word does not mean the same thing to everyone. "Confirmed order" means paid for finance and picked for the warehouse. Third, the document changes and nobody knows which version is the reference.
On an integration between an ERP and an online shop, the specification moved at almost every meeting. I kept it evolving version after version, numbered and dated, so that everyone was talking about the same document. I turned that into a way of writing an integration specification: it was never a skills problem, it was a problem of shared reference.
02Write the need before the solution
The rule I follow comes from a serious place. The UK government's Service Manual asks that a need focus on the user's problem rather than a possible solution, with a simple example: needing a reminder, not needing an email or a letter. The same page treats any opinion that does not come from users as an assumption to be proven.
In practice, when someone hands me a solution, I go up one level with a single question: "what happens if we don't do it?". The answer almost always gives the real need. For the Excel export it would have been: "I find out about delays when the customer rings".
The format I use fits on three lines:
- when… (the situation that triggers the need);
- I need to… (what the person has to be able to do);
- so that… (the outcome that actually matters).
It is close to the user story format, and the Service Manual guide on writing user stories says something I agree with: the most important part is the goal, and if you are struggling to write it, you should reconsider why you think you need that feature.
03Turning a business need into technical requirements, in five steps
This is the sequence I follow, on a project of a few weeks as well as on a one-off request. It fits well into scoping a digital project in a week.
1. Listen to the people who live with the problem
Before writing anything, I talk to the people involved, one at a time. Nielsen Norman Group describes well what these stakeholder interviews bring: history, constraints, solutions already tried, and what success looks like in concrete terms. The follow-up question that helps me most is the simplest one: "can you give me an example?". One real example is worth ten generalities.
2. Write the need in their words
I write the needs in the business's own vocabulary, then read them back with the people concerned. If they do not recognise themselves in the sentence, I have translated too early.
3. Fix the vocabulary and the reference data
I keep a short list of the words that matter, with their definition and the tool that holds the truth. It is the dullest step and the one that has helped me most. Mixing centimetres and millimetres between two tools is enough to distort an entire render: since then, the unit and the source of every piece of data are written down in black and white.
4. Derive the technical requirements, and keep the link
For each need, I write what the system has to do, then note which need each requirement comes from. The Service Manual calls this traceability: needs are broad and stable, stories are more precise, and each story keeps track of the need it serves. When someone asks why a field exists, the answer is in the document.
5. Write how you will know it is done
Every requirement gets an acceptance criterion, written as "it's done when…". This is where the business and the technical team really agree, because a criterion can be checked. When the subject allows, I also show a mock-up: presenting several directions at the same level of finish often settles a decision that pages of text cannot. I cover that in the article on clickable prototypes.
04Make the business rule testable
For a business rule to reach the technical side intact, I have found nothing safer than turning it into a test. At Moonworkers, my payroll company for small UK businesses, contribution rules come from HMRC texts. Rather than summarising them in a document, I wrote an "oracle" from those texts that recalculates the results independently. It replayed 896 cases and found four one-penny errors, all caused by a rounding rule. I tell the full story in the article on the test oracle.
No specification review would have caught those one-penny gaps. The rule was right on paper; it was its translation into code that drifted, at the moment of rounding.
You do not need to go that far to get something out of it. A list of concrete examples, input and expected result, signed off by the business, already works as a contract. The technical team can replay it, and the business can read it.
05Statement of needs, supplier brief, specification: who writes what
I often see these three documents mixed up. This is how I separate them:
- The statement of needs gives the problem, the goal, the constraints and what is out of scope. The business writes it first, with someone asking the questions.
- The supplier brief says what is expected from the supplier: scope, deliverables, deadlines, acceptance testing. The commissioning party writes it.
- The specification says how the system behaves, field by field. The technical team writes it, and the business reviews it.
On a small project, all three fit in one document. The order does not change.
That leaves the question of who decides. The Scrum Guide is clear: the Product Owner is one person, not a committee, may represent the needs of many stakeholders, and is the one who makes backlog items clear and understood. The developers, on the other hand, decide how they turn them into working software. That split between the what and the how is exactly what a good statement of needs respects. Henrik Kniberg's video, Agile Product Ownership in a Nutshell, sums up the role in a quarter of an hour, between stakeholder demands, the backlog and prioritising by value.
In my content machines I have applied the same logic. The brief blocks writing until the angle and the list of what the text will not claim are written down. A reviewer's feedback becomes written rules rather than corrections made by hand. It is a statement of needs applied to myself.
06What this go-between role does not fix
A writing method does not replace a decision. If two departments disagree on the goal, even a very careful document will only make the disagreement more visible. That is useful, but someone then has to decide, and it is not the person holding the pen.
It also has a cost. Fixing the vocabulary, tracing each requirement, writing the criteria: for a small change it is out of proportion. I keep the full version for subjects where a mistake is expensive, such as calculations, data exchanges between tools, or what the customer sees.
Finally, I do not claim that a go-between role is enough to restart a dialogue between an IT department and the business that has been stuck for years. It helps put everyone back on the same document. It does not repair a relationship.
07Where to start on Monday
Take the last request that arrived as a solution. Ask it "what happens if we don't do it?", then rewrite it on three lines: when, I need to, so that. Add two "it's done when…" criteria and show the lot to the person who made the request. You will soon see whether you were talking about the same thing.
If you would like help scoping a project like this, my services describe how I work, and the project portfolio shows what I have built. Happy to talk it through.