Requirements define what the product must do and why. In RCF, code and tests are checked against
those requirements.
Last updated
Requirements govern every downstream artefact in RCF. Code can be regenerated from a good
specification, but code alone cannot recover the original specification and its intent.
Many projects treat code, tests or developers’ memories as the source of truth. Requirements are
updated after implementation and consulted infrequently.
Without agreed requirements, disagreements about behaviour depend on influence or memory. Existing
implementation becomes its own justification. Teams must reconstruct an audit trail from code when
asked to show that a control is in place.
What it costs when requirements are decorative
Requirements that do not govern the work undermine three capabilities: resolving disagreements,
controlling scope and verifying completion.
First, an agreed requirement lets engineers check whether the requirement needs correction or the
implementation fails to meet it. Without that reference, disagreements depend on recollections of
earlier conversations.
Second, recorded scope makes additions identifiable. If scope exists only in a developer’s memory, a
reviewer cannot reliably distinguish required work from scope creep.
Third, completion must mean that every requirement is met and every acceptance criterion passes. A
running demo and an outdated requirements document make it easy to overstate progress.
Why code can’t be the source of truth
Code describes how the software works. It does not record why a function was requested. Those
reasons need a durable record that survives edits, refactors, deletion and replacement.
An agent generates a plausible interpretation of its prompt. If the prompt omits intent, the agent
fills the gaps with assumptions. The resulting code does not establish that those assumptions were
approved.
Why tests can’t be the source of truth either
Tests state expected behaviour, and passing tests provide evidence that it occurs. That makes tests
useful evidence, but does not make them the product specification.
A test case describes a specific behaviour. A requirement describes a business goal. The
relationship must be explicit and traceable. Tests can all pass while the product is wrong if they
describe what was built rather than what was requested.
What “source of truth” actually means
In RCF, the source of truth is the PRD’s requirements list. Concretely,
that means three things.
Intent & architecture → FBS → tests · AC → CN
When behaviour is disputed, check the requirement. If it does not answer the question, update and
commit it before changing the code.
Every user story links to a requirement. Every acceptance criterion belongs to a story. Each test
suite implements one criterion, and a Code Node links the implementation to its criteria. Work
without a requirement must either be justified by adding a requirement or removed from scope.
Work is complete when every acceptance criterion passes and traces back to its requirement. A
running demo or a passing CI run alone does not establish completion.
The cost of doing this properly
Writing a useful PRD takes time before coding starts. This initial requirements work can resemble
waterfall.
The PRD remains editable. Requirements can be added, retired and restated as the product develops,
with every change recorded in a commit. Someone must own the statement of what the product is.
Without that ownership, unwritten requirements emerge later as bugs, missed deadlines and rework.
The chain retains decisions, makes changes to intended behaviour visible and connects failures to
the requirements they affect. Checking whether the product still meets its requirements becomes a
query rather than a reconstruction from memory.
