Requirements as the source of truthCopy link

On most projects, requirements aren’t the source of truth. The code is. Or maybe the tests. Or, more often than anyone wants to admit, the developer’s memory of a Slack conversation from three weeks ago. The requirements document, if it exists, is the thing that gets edited last and read least, well after the thing it’s supposed to describe has already been built.

That arrangement has consequences. When two engineers disagree about what a feature is supposed to do, the louder one wins. When a product owner asks why something behaves a particular way, the answer is “because that’s how it was built.” When a compliance or security officer asks for an audit trail showing a control is in place, the team reverse-engineers a story out of the code. None of this is anyone’s fault. It’s what happens when nothing else can be the source of truth, because nothing else is allowed to be.

What it costs when requirements are decorativeCopy link

A team that doesn’t treat requirements as load-bearing loses three things, always in the same order.

First, they lose the ability to argue cleanly. A disagreement about behaviour should be a disagreement about a requirement: is the requirement wrong, or is the code wrong against the requirement. Without a load-bearing requirement, every disagreement collapses into “what did we mean six weeks ago” and the person with the longest memory wins. That person is rarely the right person.

Second, they lose the ability to scope. Scope creep isn’t mainly a problem of people adding things. It’s a problem of people adding things that nobody can tell are additions. If “in scope” lives in the developer’s head, every PR is in scope. Nothing is creep.

Third, they lose the ability to ship honestly. “Done” should mean “every requirement met, every acceptance criterion green.” Without a load-bearing requirements set, “done” means “the demo runs.” Most management lies about the state of completion. That lie is easy when the thing you’d be lying against is a Confluence page someone hasn’t opened in a month.

Why code can’t be the source of truthCopy link

Code answers how, not why. Ask the code why a function exists and it shrugs. The function exists because somebody wrote it. The reasons sit somewhere outside the file, and they’d better sit somewhere durable, because the file will be edited, refactored, deleted, and rebuilt half a dozen times before the product retires.

With AI agents in the loop, this gets worse. A human writing code at least carries the intent in their head while they’re typing it. An agent doesn’t. The code an agent produces is a plausible interpretation of a prompt, not an execution of an intent. If the prompt was thin, the interpretation is a guess. The guess goes into the repo. Three months later, when somebody asks what the function does, the only honest answer is “an agent thought this”, which is not an answer at all.

Why tests can’t be the source of truth eitherCopy link

Tests come closer. A test is at least a statement about behaviour, and a green test is at least evidence that the behaviour happens. So you’ll hear people argue that tests are the spec, especially in the BDD lineage. They’re not.

A test is a statement about behaviour at the resolution of a single test case. A product requirement is a statement about behaviour at the resolution of a business goal. Those are different scales. The relationship between them needs to be explicit and traceable, not implicit and hopeful. Without that relationship, tests can be perfectly green while the product is wrong, because you wrote the tests for the thing you built rather than the thing you were asked to build. That happens. I’ve watched it happen.

What “source of truth” actually meansCopy link

In RCF, the source of truth is the PRD’s requirements list. Concretely, that means three things.

When there’s a disagreement about behaviour, the requirement is what gets checked. If the requirement doesn’t answer the question, the requirement is updated, deliberately, with a commit, and then the code follows. The requirement isn’t the trailing edit. It’s the leading edit.

When something gets built, it gets built against a requirement. Every user story points up to a requirement. Every acceptance criterion sits inside a story. Every test suite implements a criterion. If you can’t draw the line from the thing you’re building back to a requirement, you’re not building from the requirements. You’re building from somewhere else, and that somewhere else needs to be either promoted to a requirement or thrown out.

When something is reported as done, “done” means “every acceptance criterion green, traced back to its requirement.” Not “the demo runs.” Not “CI is green.” Done is a property of the chain, not a property of the artefact.

The cost of doing this properlyCopy link

Up front, requirements work is slow. Writing a PRD that survives contact with reality takes more time than the urge to start coding makes comfortable. The first stage of an RCF project looks deceptively like waterfall to anyone watching from the sidelines.

It isn’t waterfall. The PRD is a living document. Requirements get added, retired, restated as the product takes shape, and every change is a commit. What it shares with waterfall is the insistence that someone, somewhere, owns the statement of what the product is. That ownership is the whole point. The alternative is what I’ve watched teams do for thirty years: nobody owns it, and the cost gets paid in late nights, missed deadlines, and a backlog full of bug reports that are really just unwritten requirements catching up with the code.

The benefit comes later, but it compounds. Every requirement that’s load-bearing is a question that doesn’t get re-asked. Every acceptance criterion that traces back to a requirement is a slice of the product that can’t silently change shape. Every test that traces back to a criterion is an alarm that fires when something downstream breaks something upstream. You get a project where the cost of asking does this still do what we said it would is roughly zero, because the chain answers without anyone having to remember.

Where this idea cashes outCopy link

The rest of the methodology is the operational detail of making this practical. The document chain is the structure that connects requirements to code. Acceptance criteria as the contract is the joint between business intent and machine behaviour. Traceability is what you get to do, once the chain is in place, that you couldn’t do before.