Have AI translate business needs into developer terms── Write requirements in business language, have AI restate them for system developers, mark its assumptions and read it back before building, and errors surface before any code exists

01The operator asked the AI to rewrite the requirements before building anything

In July 2026, the operator was preparing to have an AI build a system to support promotional material review. There were four things to ask for.

The first was to hold the review criteria inside the system. The second was a screen where users could paste reference documents chosen for the task at hand: the package insert, the regulator's review report, the risk management plan, or guides on proper use. The third was the ability to read the material under review whether it arrived as Word, PDF, PowerPoint or Excel. The fourth was a set of review conditions users could switch on, such as promotion of unapproved drugs, recommending off-label use, exaggerated claims and disparaging competitor products.

The operator also split the work. The criteria would wait until a component then being built was ready. The screen, the file reading and the conditions would be built first as the front end. Up to this point, everything was written in the language of someone who does promotional review for a living.

Then the operator held back from asking for code. The first request was to rewrite all of this in technical terms a system developer could understand. The record keeps the request, not the full rewrite the AI returned. This article is about that order of steps.

When people who know the business ask an AI to build something, which language should the requirements be written in? Write them in business language, have the AI rewrite them for developers, and read the rewrite yourself before anything is built.

02Rewriting splits each requirement into inputs, outputs and conditions

Business language and developer language describe different sides of the same requirement. Business language says what the thing is for. Developer language says what it receives, what it returns and under which conditions it runs.

Take "a screen where users can paste reference documents". For a reviewer, that is a complete instruction. For a developer, it is not. It does not say how many document types there are, whether users paste text or upload files, or whether a pasted document can be reused in the next review.

The table below shows the kind of detail a rewrite adds to the operator's four requirements. It is an illustration prepared for this article, not the AI's answer in the record.

Everything added is something the business side has already decided in their heads. The rewrite puts those decisions on paper. Anything not yet decided shows up at this point, before it can turn into a guess in the code.

03Most build errors start in the requirements, before any code is written

Japan's Information-technology Promotion Agency, in the second edition of its requirements definition guide for system users published in 2019, states that more than half of delays in system development come from failures in requirements definition. If a requirement is misunderstood when building starts, the gap is found only after something has been built.

Gaps found after building are expensive. The screen is rebuilt, the connected components are changed, and everything is tested again. A gap found at the requirements stage costs one corrected sentence.

One reason gaps appear is that the words do not cross over. To a reviewer, "off-label" needs no explanation, but many developers will not know it. In the other direction, terms developers take for granted, such as input validation or default values, are decisions the business side should make, and the business side often does not notice them.

Asking an AI for the rewrite adds one step between the two vocabularies. The business side can write in its own words, and developers can read in theirs. You do not need to find someone fluent in both every time; the AI can produce the first rewrite.

04A good rewrite has one interpretation and can be verified

There is an international standard for judging requirements: ISO/IEC/IEEE 29148. It lists nine characteristics that each individual requirement should have. Four of them matter most when business language is being rewritten.

The rewrite also has limits. First, the AI rewrites words, not business rules. Which review conditions to include and which documents count as the reference are decisions for the business side.

Second, the AI may fill missing details with guesses. If the rewrite contains numbers or behaviour that were not in the original request, such as a file size limit or a default selection, those are the AI's assumptions. Have it mark them as assumptions, and let the business side decide each one.

Third, keep the purpose sentence when the language changes. If the reason for a feature disappears, a developer can build something that meets every condition and still does not help the reviewer.

05Review conditions need both the regulatory item and a definition of the check

This method pays off most where business rules are detailed and developers do not know them. A system for promotional review is a clear case.

The review conditions the operator wanted overlap with the items in the guideline on sales information activities for prescription drugs, issued by Japan's Ministry of Health, Labour and Welfare in September 2018. The guideline lists prohibited conduct including false or exaggerated expressions, recommending use outside the approved indications, dosage and administration, and disparaging other companies' products to present one's own as superior. For comparative trials, it requires that the design and the results be shown accurately.

Those items alone are not enough for a developer. For each condition, someone has to decide what the check takes in and what it returns.

The same method works outside review systems. When you ask the IT department to change a document management system, request a quote from an outside developer, or add fields to the medical information enquiry log, the language of the people who use the system and the people who build it still differ.

In every case, interpreting regulations and company rules stays with the business side. The AI's rewrite only puts that interpretation into a form developers can read.

06The AI can write both languages but does not know your business assumptions

An AI is suited to this rewrite because it has seen both business documents and technical specifications. Writing requirements as functions, inputs, outputs and conditions is a common format in software work, and an AI can produce it.

Research supports this. In a 2024 paper, Lubos and colleagues had a large language model judge requirements against the ISO 29148 characteristics and propose improvements. The model found 74 to 89 percent of the existing flaws, and engineers rated 66 to 100 percent of its rewritten requirements as improvements. Its judgements did not match the engineers' at first; agreement rose substantially after the engineers read the model's explanations.

What the AI lacks is your business context. Anthropic's published guidance on prompting Claude advises treating it as a brilliant but new employee who lacks context on your norms and workflows, and explaining precisely what you want. It also notes that giving the context or motivation behind an instruction helps Claude deliver more targeted responses.

So the request for a rewrite should state the purpose and the reader. The purpose is what the system is for. The reader is a system developer. Even then, the AI will fill gaps in context with guesses, which is why someone from the business side has to read the rewrite.

07From tomorrow: write in business terms, have it rewritten, read it back, then build

There are five steps.

1. Write numbered requirements in business language. State what the system is for, who uses it, what it handles and what it decides, in everyday words. If the order of work or the split between parts is settled, write that down too.
2. Ask for a rewrite and name the reader. Ask for the content to be restated in technical terms a system developer can follow, and fix the format: function, inputs, outputs, conditions and the test that shows it is done, for each requirement.
3. Have assumptions and open questions listed separately. Ask the AI to mark any number or behaviour that was not in the original, and to list the points still to be decided.
4. Have it translated back and compare. Ask the AI to summarise its rewrite in business language again. Compare that with your original and have it fix any place where the meaning changed.
5. Build only the agreed version. Decide each assumption, then ask for development from that version. Keep the original requirements and the rewrite side by side.

The first and last steps are decisions for people. Steps two to four can be handed to the AI. Skip step four, and the AI's guesses become the specification, and the gap is found only after building.