Where requirements break, and who gets to fix them

We keep one rule on every spec we work on: a question is not answered when someone replies in the thread, it is answered when the answer is in the spec. Threads get resolved and forgotten, and the spec is what the next person builds from.

That rule holds inside the repository, and it stops at the edge of it. The business requirement the spec was written from usually lives somewhere else, in a document owned by the founder or by whoever runs the process, approved and finished as far as everyone who signed it is concerned.

Then we write the spec, and the questions start.

The spec is where a requirement breaks

Writing a spec means turning each sentence of a requirement into something a developer can code and a tester can check. That is a different act from writing the requirement, and it is unforgiving. A sentence like "the reviewer checks the submission before it goes out" survives a read-through by three senior people without anyone stopping on it. It does not survive the first attempt to build it: which reviewer, what may they change, who else sees the submission while they hold it, and what happens when they do nothing for a week.

That last kind of question is the one that usually arrives in a pull request comment, and the requirement has no answer for it. Nobody was careless. The case never came up while the requirement was being written, because prose lets you describe a process without deciding what it does at the edges.

We find these while we review and negotiate the spec, before anything is coded, which is where they should be found. The cost is not the finding. It is the round trip that follows.

An approved document with no way back

The requirement processes we are handed tend to have the same shape: someone compiles the requirement, a second person approves it, a third signs it off, and the approved version is filed and treated as final. It is a clean chain, and it runs in one direction. Nothing in it says what happens when the spec exposes a hole three weeks later.

So one of two things happens, and neither is good. Either the answer lands in the spec alone, in which case the approved requirement quietly stops describing what is being built and the person signing off on the spec is checking it against a document that is out of date. Or every answer re-enters the chain at the top, and a clarification a developer asked in four minutes takes two more approvals to settle.

The first failure is the worse one, because nobody notices it until an approver asks why the spec contains something they never agreed to.

Sort the question before you route it

Not every question about a requirement is a change to it. Three kinds arrive, and they deserve different paths.

• A clarification makes a requirement precise without changing what the business needs. It belongs in the spec, and that is the end of it.
• A change adds, removes or alters what the business needs, or changes how a rule is read. The requirement document changes with it, and is approved again for the part that changed.
• A new requirement is not an answer at all. It goes back into whatever decides what gets built next.

Most questions are the first kind. A team that does not separate them treats all three as changes and waits, or treats all three as clarifications and drifts away from the document everyone signed.

Put each decision where the information is

The harder half is who answers. In most of these processes, the person who compiles the requirement, talks to everyone and writes the document holds no decision at all. Every answer they give is provisional until someone senior confirms it, so the person who knows the requirement best cannot settle a question about it, and the questions queue behind whoever can.

We do not argue that the requirement owner should own every decision. In a regulated business, a senior sign-off on how a rule is read is not bureaucracy, it is the person carrying the liability doing their job. What we argue for is smaller than a reorganisation: name who decides each kind of question.

• The person who writes the requirement decides clarifications.
• The accountable approver decides changes to scope, and approves the finished spec.
• Whoever owns the regulatory reading decides that reading.
• Whoever decides what gets built decides what enters.

The senior approver stays the only person who can change what gets built. What goes away is the queue of small questions in front of them, which was never their job in the first place. This is the same lever as rules instead of a management layer: the decision gets cheap once someone has written down who owns it.

What the waiting costs

The time spent getting a requirement into a buildable state comes out of the same budget as the coding. Every round of questions is a day the product does not move, and the rounds multiply when an answer arrives after the spec has already been written around a different reading of the same sentence. A requirement that arrives with a route for its questions puts more of the month into the product, which is the only part of this anyone outside the process can see.

Acceptance criteria are part of the same cost. Written at the end, as a check on the finished spec, they arrive after the team has already built to a bar nobody stated. We ask for them in the requirement itself, in business terms: what each user has to be able to do, and which regulatory outcome has to hold. Each one becomes a key result in the spec, and shipping means showing each key result working, in a spec that shrinks as it ships.

The question worth asking about your own process is not whether requirements get approved. It is who can answer a question about an approved requirement without booking a meeting. If that is nobody, the requirements are not approved. They are frozen.