RCF and requirements-driven development

Requirements-driven development (RDD) traces requirements through code and tests. RCF adopts that approach with a specified artefact chain, one test case per acceptance criterion and links maintained in the repository through the build cycle.

RCF inherits RDD’s requirements-first approach: record requirements, trace them to code and verify against them. These practices predate RCF.

This page explains RCF’s differences from RDD and where classical RDD remains the better choice. The spec-driven development page compares practices developed around AI code generation.

What requirements-driven development is

RDD includes two established approaches.

The first is the heavyweight strand: the world of software requirements specifications, application lifecycle management tools like IBM DOORS, the requirements database that has anchored regulated software for decades, and formal traceability. Visure’s account of RDD lays out the full lifecycle, from requirements elicitation through analysis, specification, implementation with verification, and on into maintenance, with a requirements traceability matrix holding the whole thing together and end-to-end coverage as the explicit goal. This strand has deep regulatory standing. It’s where you find DO-178C for aerospace, ISO 26262 for functional safety, IEC 62304 for medical devices. When a regulator wants to see that every line of code traces back to a requirement and forward to a test, this is the tradition that answers.

The second strand is lighter and looks nothing like a DOORS database. Ken Pugh, who has written on this for years, equates “requirement-driven development” directly with behaviour-driven development, acceptance-test-driven development, and specification by example. In that reading, RDD just means driving the build from the external behaviour the requirement describes, expressed as executable acceptance tests. Phase2 frames the same idea as making sure you build the right thing rather than just building the thing right, with requirements vetted through testing as the work goes rather than signed off once at the start.

Both approaches prescribe a process and require traceability. RDD ranges from lightweight BDD to regulated ALM systems. RCF falls within that range.

What RCF is doing differently

RCF makes three specific changes to the RDD approach.

First, the chain is specified down to the artefact, with the cardinality pinned. RDD prescribes a requirements lifecycle and tells you to maintain traceability, but it leaves the granularity of the artefacts and the exact mapping between them to the team and the tool. RCF names the chain explicitly: a PRD at the top, then a requirement, then a story, then an acceptance criterion, then a test, and it binds the acceptance criterion to a single test case one to one. The one-to-one mapping is the key constraint. A traceability matrix tells you a requirement is covered somewhere. A one-to-one binding tells you exactly which test case proves exactly which criterion, and refuses to let a criterion exist without one. The binding reaches into the code as well: the file that implements a criterion is a resolvable node in the same graph, anchored back to that criterion, so the criterion-to-code link a traceability matrix records as a row is one RCF’s own validation walks and rechecks against the working tree.

Second, RCF keeps the chain in the repository, versioned with code. Heavyweight RDD often keeps it in an ALM tool, matrix or database. The Phase2 piece describes how separated requirements lose alignment with the product. RCF’s build cycle enforces links within the same commit history.

Third, RCF aims to reduce heavyweight RDD’s tooling overhead. Electronic Design asks whether RDD is too challenging to be worth it and argues its difficulty is justified by mature processes linking requirements, architecture, code and tests. RCF seeks those connections through the repository and build cycle with less overhead than ALM. This comparison does not apply to lightweight BDD, which already has little overhead. Relative to BDD, RCF adds the chain up to the PRD and business decision, plus the one-to-one AC-to-case constraint.

When classical RDD is the right reach

Classical RDD remains the better choice in these cases.

If you’re building regulated or safety-critical software, reach for classical RDD with a proper ALM platform, not RCF. The aerospace, medical, and functional-safety standards expect specific traceability artefacts and a documented lifecycle that auditors already recognise. The ALM vendors have spent decades building tooling that produces exactly those artefacts and stands up to certification. RCF has none of that regulatory acceptance yet. If a DO-178C or IEC 62304 audit is in your future, the mature tradition is the responsible answer and RCF is not.

Teams with a working ALM toolchain may face switching costs greater than RCF’s benefits. RDD has a mature, vendor-neutral tooling ecosystem. RCF is younger and has no comparable tooling market. A maintained Visure or DOORS matrix is more established than RCF’s build-cycle enforcement.

Teams served by BDD or acceptance-test-driven development may not need more structure. RCF adds value when traceability must extend above acceptance tests to the PRD and business decision.

When RCF is the right reach

RCF fits teams that need requirements-first discipline without a full ALM system, and want the chain versioned with their code.

The silo-and-drift failure occurs when separately maintained requirements stop describing software. RCF places the PRD and chain beside code so traceability is maintained through the build. This suits teams whose main working environment is the repository.

RCF also fits teams that require one test case per criterion as an enforced rule. A matrix can record partial coverage. In RCF, an acceptance criterion as a contract is incomplete without its case. The structure supplies a specific coverage constraint.

RCF adapts RDD for coding agents. The spec-driven development page covers this separately. Keeping the chain in git gives human reviewers and agents a precise, traceable target.

Is spec-driven development the same as requirements-driven development?

No. Spec-driven development is the AI-era practice of making the spec the primary artefact and generating code from it. Requirements-driven development is the older discipline of anchoring everything to requirements and verifying against them. One is about how code gets produced; the other is about where intent lives. RCF joins them: the spec derives from the requirements, and the criterion-derived tests decide whether the code is right.

The honest summary

RDD has decades of regulatory use and a mature, vendor-neutral tooling ecosystem. It remains appropriate for regulated and safety-critical work. Teams already using mature ALM tools may gain too little to justify switching.

RCF specifies artefacts and their cardinalities, keeps them in the repository and enforces links through the build cycle. It requires less overhead than heavyweight ALM but has a younger, narrower tooling ecosystem. The methodology lineage records RDD as a foundation of this work.