Business Objectives to Code · Part 2 of 4
From Business Question to Approved Requirement
Requirements quality has always depended on who was in the room. Capturing expert judgment as governed, reusable assets makes it something an organization owns instead.
Hand the same short project brief to two analysts and you will usually get two requirement sets of noticeably different quality, and the difference will have very little to do with how fast either of them writes. The stronger set exists because the person who produced it knew which questions to ask before anything was written down. They knew to ask how tenants are isolated, what the target system already does by default so the requirements do not restate it, where the integration boundaries sit, and which innocent-sounding answer from the client quietly triples the scope. The weaker set comes from an analyst who did not yet know those questions were the ones that mattered. That gap is the real subject of requirements work, and it is why requirements quality has always been a function of who happened to be in the room.
The first article in this series followed a single requirement from an approved business objective all the way to running infrastructure and showed that the chain held because non-model code enforced the contract at every seam. This article goes inside the first stage of that chain, the stage where business questions become approved requirements. It is worth going in because this is where the chain is either made governable or lost. A requirement that does not trace to a business objective, or that reaches the build without a testable definition of done, cannot anchor anything downstream no matter how disciplined the later stages are. And the scarce input at this stage is judgment. Producing requirement text faster does not address the thing that actually determines whether the requirements are any good.
I built a requirements system to see whether that judgment could be made into something an organization owns rather than something that lives in a few senior heads and leaves when they do. This was my own method exercised on my own build, with no client and no employer engagement. I acted as my own client: the requirements came from real needs and from genuine research into the platforms involved, which is the same kind of source material a client engagement provides through RFPs, statements of work, call transcripts, and product documentation. What I wanted to test was narrow and specific: whether the expert reasoning that separates a strong requirement set from a weak one can be captured as reusable assets, enforced by software, and reused without decaying, so the quality floor stops depending on the seniority of whoever picks up the work.
Capturing the judgment that usually walks out the door
Two kinds of expertise decide the quality of a requirement set, and both are ordinarily trapped in individuals. The first is discovery instinct, the knowledge of what to ask. The second is platform knowledge, the understanding of how a given technology actually behaves and where it tends to surprise you. The system captures each one as an explicit, reusable asset rather than leaving it to be re-earned on every engagement.
Discovery instinct becomes a library of structured questions, organized by the areas a project has to cover, from business objectives and access model through catalog, payments, integrations, non-functional requirements, and governance. Each question is annotated with what its answer is for, which requirement or objective field it populates once it is answered. This is a senior analyst’s interview written down and made repeatable. An analyst working from it asks the questions that matter whether or not they would have known to ask them unprompted, which means the floor of what gets surfaced during discovery no longer rides on individual experience. The questions relevant to a particular technology can be surfaced only where they apply, so the list stays specific instead of becoming a generic checklist that people learn to ignore.
Platform knowledge becomes a set of profiles, one per platform, each recording the same structured things: how the system works by default, the non-obvious assumptions that would change scope if they turned out to be false, the client answers that recur and expand scope, and the effort drivers that dominate estimation for that kind of system. A profile is produced once through focused research, checked by a person against a review checklist, and validated against minimum-content bars before it is allowed into the library. After that, every analyst on every engagement that touches that technology inherits the knowledge in it. Someone working on a system they have never used personally scopes against its real defaults and surfaces its real risks, because the expertise is in the profile rather than in their memory. This is the concrete mechanism behind a phrase that is otherwise just aspiration. Expertise scales without quality decay when the expertise is captured as a governed asset and applied the same way every time, instead of being taught, imperfectly, from one person to the next.
Neither asset removes the human. An analyst still decides what the business actually needs, judges which of those deviations apply, and prioritizes. What changes is that they start from a floor built out of everyone’s accumulated judgment rather than from their own experience alone.
One standard, many engagements
The move that turns this from a personal practice into a repeatable system is a separation, and it is an operating-model decision more than a technical one. The methodology, the quality rules, the identifier conventions, and the captured knowledge all live once in a shared framework that analysts do not edit. Each engagement is a thin working space that holds only its own content and inherits everything else from the framework. The practical consequence is the one that matters to anyone running a team: a decision about the standard, made once in the framework, applies to every active engagement at once. When the definition of a good requirement improves, or a new platform profile is added, the improvement is not rolled out engagement by engagement and hoped into place. It is simply present everywhere the next time the work runs.
That same structure is what lets a single program hold together at a size that would otherwise collapse into inconsistency. A real program is rarely one requirement set. It is several coordinated efforts that share a client but each own their own scope, governance state, and requirements. The build I exercised this on was organized as four coordinated initiatives under one client identity, and three mechanisms kept them coherent. Every artifact carries an identifier namespaced to its initiative, so hundreds of requirements across four efforts never collide and every identifier reveals where it belongs at a glance. Each initiative carries its own governance state, so one can be locked for delivery while another is still in open discovery, rather than forcing the whole program to move at one pace. And each initiative explicitly names what belongs to a sibling, so the boundary between them is written down rather than assumed, which is what prevents the same requirement from being authored twice or falling into the gap between two teams. The question a technology leader asks about any approach like this is whether it survives a real program instead of a demo. Namespaced identity, per-initiative governance, and explicit boundaries are the specific answers to that question.
Approved means locked and traced
None of this is worth much if approval is informal, because the value of the whole downstream chain depends on the requirements being stable and connected to a reason once they are called done. Approval here is a governed state rather than a conversation. Each initiative moves through an explicit authoring phase, during which requirements can be freely proposed, drafted, and revised, and then through a deliberate lock for delivery, after which a requirement cannot be added, removed, or materially changed without an explicit, acknowledged exception. Underneath that lifecycle sit quality rules that block on the things that actually break a build. A must-have requirement with no testable acceptance criterion is not allowed through. A performance requirement stated as “fast” rather than as a measurable threshold is rejected until it carries a number. A requirement that does not trace up to a business objective and a user journey is blocked as well. There is no override flag for these, because an override flag is how quality quietly erodes under delivery pressure.
That last rule, that every serious requirement must trace to an objective and a journey, is the one that carries the most weight. It is the beginning of the traceability the first article followed all the way to a running resource. When the next stage compiles these requirements into specifications a coding model builds against, it can trust its inputs precisely because each requirement already carries its acceptance criteria and its link back to an approved business reason. The requirement layer is where that thread is either established or permanently missing, and a thread that is missing here cannot be reconstructed later.
The friction that usually makes this kind of discipline unsustainable is handled by putting it behind an ordinary editing surface. An analyst authors, validates, estimates, and governs requirements inside a VS Code extension I built for the purpose, without hand-editing structured files or running tools by hand, with model assistance for discovery and drafting confined to the project in front of them, and with the same quality rules and the same phase lock enforced through the interface. A person still approves. The extension removes the tax that normally makes analysts route around governance, which is what lets the governance actually hold.
The reason to care about any of this is straightforward. Requirements are the stage where the chain from a business objective to working code is made governable or lost, and the property that makes AI-assisted delivery trustworthy downstream is established here or nowhere. Capture the expert judgment as governed assets and a team produces sound requirements without depending on who is in the room. Separate the standard from the content and one improvement reaches every engagement. Lock and trace what gets approved and the next stage can build against it without inheriting ambiguity. The infrastructure article showed a model filling semantic slots inside a contract it could not rewrite. This is where that contract is written, and where the discipline that governs everything after it begins.