In the AI Era, How a Business Spec, a Requirements Document, and Engineering's Own Planning Differ

A requirements document answers "what must be true." The business team's spec answers "why are we doing this." And engineering does its own planning, which answers "how will this get built." Three documents, three authors, three lifespans — and plenty of teams hand all of it over as one lump.

Something new has been added lately. Thanks to AI, business teams build their own HTML mockups in half a day. That's a good change, and it widens the gap between how the two sides read progress. The screens click through, so the business side sees something nearly done; engineering starts over from that point. Neither is wrong. One whole stage sits in between, and only one side can see it.

This post assumes a small new-build project. Simple operational changes — copy edits, value changes — don't need the stages below.

A Requirements Document, a Business Spec, and Engineering Planning

Framing it as "spec versus requirements document" only gets you half the picture. Three documents are actually in motion.

	Business spec	Requirements document	Engineering planning
Question answered	Why, and for whom	What must be true	How it gets built
Written by	Business (marketing, sales)	Business and engineering together	Engineering lead or planner
Core content	Background, audience, success criteria	Behavior, data, screen states, exceptions	Structure, legacy integration, data model, blast radius, sequence
Read by	Decision-makers, stakeholders	Engineering, QA, operations	Engineering, QA
Changes when	Strategy changes	Continuously through implementation	Technical assumptions change
Settles arguments about	Why we did this at all	Whether this behavior is right	Why we built it this way

Business planning serves marketing and sales. It decides what to win in the market and what to promise to whom. Engineering planning serves engineering. It decides what attaches where and in what order so the same goal can stand up in code. Both are planning, and neither is an abridged version of the other.

The document in the middle is what joins them. A business spec goes quiet once approved; a requirements document stays alive to the last line of code. The checklist for a spec engineers can start from was ultimately an argument that a requirements document has to live inside the business spec.

None of this means you need three files. Plenty of teams now write each screen's purpose and requirements directly into the HTML mockup and hand over one artifact, and on a small job that's faster. What has to be separated is the questions, not the files. One file is fine as long as someone reading "why" can skip past "what must be true" — the sections just have to be distinct. Mixing only becomes expensive as the volume grows, and at that point the files split on their own.

What Engineering Planning Actually Does

Going straight from mockup and requirements into code almost never happens on new builds. In between, engineering plans again. It reads what arrived and asks first: if we build it exactly like this, what breaks?

Deciding how it attaches to legacy

New features always land on top of something already running. Where member data comes from, whether the existing permission model gets reused or replaced, how existing records migrate, what happens to the twelve other screens reading that same table. The business documents don't contain these questions, and there's no reason they should. It's the invisible half.

Deciding blast radius and sequence

The same requirement is a different size of job depending on where you change it. Adding one screen is nothing like touching a shared module and pulling regression tests for every feature that uses it. Choosing between those, and deciding whether it ships in one pass or two, is what engineering planning is. The schedule comes out of here.

The output isn't a rewrite of the requirements document — it sits on top of it. Where the document says "completed items drop out of the default filter," engineering planning decides whether that filter runs at query time or needs an index, and notes that the month-end batch reads the same view, so it comes along for the ride.

Email Alone Lets the Contradictions Hide

Plenty of teams compress all three into one email. When it's short, that's the fastest option, and most requests genuinely are. The trouble starts as the volume grows.

• Nobody reads all of it. Past forty lines, people scan for the lines that touch them. How to order a request so that works is in work email etiquette.
• Contradictions go unseen. "Only admins can edit" on line 12 and "authors can edit within 24 hours" on line 31 coexist peacefully in prose. On a screen, the same button shows up twice and someone notices immediately.
• Sentences paper over ambiguity. "Let them edit directly from the list" doesn't distinguish inline editing from a modal from a detail page. The writer had one in mind; the reader pictured another. The gap surfaces after it's built.

How one line changes three times

In practice it moves like this.

The original email — "Let the owner change the status directly from the list."

After the mockup is on screen — "Ah, a dropdown. Does a completed item stay in the list? What if two people change the same item at once? For someone who isn't the owner, is the control hidden, or visible but disabled?"

The requirements document — "Status changes from the list use a dropdown. Visible only to the owner and admins; the control is hidden for everyone else. Completed items drop out of the default filter but remain under 'Show all.' On concurrent edits the later save is rejected and the latest value is reloaded."

Engineering planning — "Status changes get their own endpoint rather than another field on the existing order API. Rejecting concurrent edits reuses the version column we already have. The completed-item filter reads the same view as the month-end batch, so that regression suite is in scope."

The first line and the last line are the same requirement. Only the last one can produce a date. Skip the middle and those questions don't disappear — they come back after implementation.

A Mockup Says What Prose Can't

This is where a mockup earns its place. It used to require borrowing a designer's or engineer's time; now the business team makes it. Talking with a screen in front of everyone changes the resolution of the questions. "Where does this button go?" is a question nobody asks in a document review.

What a mockup settles

Everything visible. Information structure, the order of the flow, screen states (empty list, loading, error), branches, terminology. Empty states in particular almost always get left out of prose and are impossible to skip in a mockup.

What a mockup leaves blank

Everything behind the screen. Who wins when two people edit at once. What happens when someone without permission types the URL directly. How much survives if the network drops mid-save. How three years of existing records migrate. Whether the screen still loads at 100,000 rows.

	What a mockup answers	What a mockup leaves blank
Scope	The visible	The invisible
Examples	Flow, empty states, button placement, wording	Concurrency, permissions, failure paths, migration, performance
How you check	Look at it	Ask engineering
Where it gets settled	Stages 1–2	Engineering planning

The value a mockup created is that it finishes the left column fast enough to leave time for the right one. It did not remove the right column.

"It Looks Nearly Done" — Because One Stage Is Invisible

This is where the two sides' reading of progress splits.

From the business side, the screens work, buttons lead somewhere, numbers appear. Everything visible is essentially finished. So "why does rebuilding this take two months?" is a natural question.

From the engineering side, that screen is a shell with every assumption removed. The data is hardcoded, nobody is logged in, nothing saves, nothing ever fails. And before any code gets written, engineering planning takes up a whole stage — where this meets legacy, what breaks alongside it, what order it ships in.

The catch is that this stage produces nothing the business side can see. The screens don't change, so it looks like nothing happened. Both sides are honestly reporting what they observed; one is counting visible completeness and the other is counting invisible agreements and design. That isn't a question of effort or skill. It's one stage nobody named out loud.

Five Stages

Stage	Business team	Engineering	Done when
1. Intent	Spec, mockup, draft requirements	Produce a question list	The question list exists
2. Definition	Answer questions, set priority	Raise constraints, exceptions, alternatives	The requirements document is signed off
3. Engineering planning	Review and accept scope adjustments	Decide structure, integration, blast radius, sequence	The plan and the schedule exist
4. Build	Answer questions within a day	Build	Acceptance criteria pass
5. Review	Verify against acceptance criteria	Explain assumptions that changed	Next-version requirements are written

Writing stage 3 into the table clears up a surprising amount on its own. The schedule arrives at the end of stage 3, not stage 2. Ask "so when will it be done?" the day the requirements document is signed off and engineering genuinely doesn't know yet.

More important than the table are four things agreed out loud before any of it starts.

1. The mockup is a picture of the requirements, not a draft of the product. The code doesn't get reused. Say this up front and "why didn't you use what I built?" never comes.
2. What isn't in the mockup is still a requirement. Failure paths, permissions, empty data, migration. Stage 1's question list exists to surface these.
3. When the mockup and the requirements document disagree, the document wins. Mockups change dozens of times during discussion; "the screen I saw yesterday" is not a reference point.
4. Engineering planning decides how, not what. If requirements wobble here, you're back at stage 2, and that round trip eats more schedule than anything else.

Decisions that changed get recorded separately. Neither document shows the past, so "why did we do it this way?" is guaranteed three months later. That's what a decision record is for.

Two Places AI Earns Its Keep

• Business side, to the AI: after building the mockup, give the same AI one more instruction. "List the states and exceptions this screen leaves undefined. Don't implement anything." You're collecting engineering's stage-1 questions before they ask them. Don't forward that list as-is — split it into what you can answer yourself and what engineering has to answer.
• Engineering side, to the AI: feed the mockup and documents you received to an AI and ask for three piles — confirmed, assumed, absent. A person then trims that into the stage-1 question list that goes back to the business team. Send the AI's questions unedited and the business side gets questions it has no way to answer.

One caution. An AI-built mockup looks more finished because it's prettier. Nobody mistakes a hand-drawn wireframe for a product; a screen with correct spacing and color is another matter. The higher the fidelity, the earlier and more explicitly agreement number one needs to happen.

Attachment — A Working Guide for the Business Side (Download)

The above is condensed into a single page the business team can use directly: prompt examples for each of the three documents, the six things that always come back if omitted (permissions, empty states, failure, concurrency, existing data, both extremes), how to write acceptance criteria, and a pre-send checklist.

Download the business spec / requirements / mockup writing guide (.md)

It's Markdown, so you can paste the whole thing into an AI chat and say "follow this guide." Adapt it to your own terminology and approval flow.

Wrapping Up

• Planning doesn't belong to either side alone. It isn't only the business team's job and it isn't only engineering's — each has planning of its own. Business planning serves marketing and sales; engineering planning serves implementation. The requirements document sits between them and owns "what must be true." That isn't a demand for three files — it's a demand that the three questions stay distinct, even in one.
• What follows a mockup is engineering planning, not code. A mockup closes out the visible fast — flow, empty states, wording. Permissions, concurrency, failure paths, existing data, and legacy integration are all still open, and a separate stage decides them. It gets skipped because it produces nothing the business side can see.
• So the schedule arrives after engineering planning, not after requirements sign-off. Ask "when will it be done?" the day the requirements document is signed and engineering genuinely doesn't know yet. Knowing just this one thing removes most of the gap between how the two sides read progress.

Agree on one sentence before any of it starts and both the requirements document and the engineering plan get easier — the mockup is a picture of the requirements, not a draft of the product.