RCF and requirements-driven developmentCopy link

The honest place to start is that requirements-driven development (RDD) isn’t RCF’s rival. It’s RCF’s ancestor. If you put requirements first, trace them through to the code, and verify against them, you are doing the thing RDD named long before I started writing any of this down. Any methodology that claims requirements as its centre of gravity owes RDD an acknowledgement, and pretending otherwise would be both wrong and a bit graceless.

So this page isn’t a takedown. It’s an attempt to say, as plainly as I can, where RCF actually differs from the tradition it comes out of, and where the older tradition is still the better choice. The agent-era argument, the one about AI writing the code, belongs on the spec-driven development page, because that’s the framing that crystallised around AI. RDD predates all of that. It’s the classical, pre-AI requirements discipline, and it deserves to be compared on its own terms.

What requirements-driven development isCopy link

RDD is older and broader than most quick takes give it credit for, and it runs in at least two distinct strands.

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 strands are real RDD. Both are structured. Both prescribe a process and care about traceability. That matters for the comparison, because the easy and dishonest version of this page would set up a strawman where RDD is heavy ceremony and RCF is the nimble alternative. RDD at its lightest is BDD. RDD at its heaviest is a regulated ALM stack. RCF sits inside that range, not outside it.

What RCF is doing differentlyCopy link

If RDD already puts requirements first and already traces them, the reasonable question is what’s left for RCF to add. Three things, and I want to be careful to claim only what’s actually different.

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 its test suite one to one. That last bit is the load-bearing constraint. A traceability matrix tells you a requirement is covered somewhere. A one-to-one binding tells you exactly which test proves exactly which criterion, and refuses to let a criterion exist without one.

Second, the chain lives in the build, not beside it. In the heavyweight RDD strand, traceability typically lives in an ALM tool, a matrix, or a requirements database that sits alongside the code. That separation is where rot starts. The Phase2 piece names this directly: once requirements are released they quickly fall out of sync with the morphing vision, and the requirements team drifts into its own silo. RCF’s answer is to keep the PRD and the rest of the chain in the repository, versioned alongside the code, and to make the build cycle the thing that enforces the links. The chain isn’t a parallel artefact you maintain by discipline. It’s in the same commit history as the software, which is the design intent behind keeping it from rotting.

Third, RCF aims for that rigour without the tooling overhead the heavy strand often carries. The trade press has been worrying at this for years. An Electronic Design piece even asks outright whether requirements-driven development is too challenging to be worth it. To be fair to that article, its answer is no: it argues the difficulty is real but worth pushing through with mature process and tooling that links requirements to architecture to code to tests. That’s the heavy strand defending itself, and the defence is sound for the contexts it serves. The critique it’s answering is the one RCF takes seriously: that the full ALM apparatus is a lot of weight to carry, and most teams outside regulated industries quietly skip RDD because of it. RCF’s bet is that you can get the artefact chain and the traceability out of the repository and the build cycle, at lower ceremony than an ALM stack. That bet applies to the heavy strand. Against the lightweight BDD strand it doesn’t, because there’s almost no ceremony there to begin with. What RCF adds against BDD is reach, not less weight. The chain runs up to the PRD and the business decision, and the acceptance criterion binds to its test suite one to one, where BDD stops at the executable acceptance test. Whether that extra reach earns its place is the question I take up below.

When classical RDD is the right reachCopy link

There are cases where the older tradition is plainly the better choice today, and saying so is the price of being taken seriously on the rest.

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.

If you already run a working ALM toolchain and your team is fluent in it, the cost of switching to a younger framework probably outweighs what you’d gain. RDD’s tooling ecosystem is vendor-neutral and mature in a way RCF simply isn’t. RCF is younger, and there’s no tooling market behind it yet. A traceability matrix maintained in Visure or DOORS by a team that knows those tools well is a more proven bet than a chain held together by a build cycle that’s newer and less battle-tested.

And if your situation is well served by the lightweight BDD strand of RDD already, you may not need RCF’s additional structure at all. Where acceptance-test-driven development is keeping you honest about building the right thing, the extra layers of the RCF chain are only worth adding when the chain has to reach further up, to a PRD and a business decision, than BDD alone reaches.

When RCF is the right reachCopy link

Reach for RCF when you want RDD’s requirements-first discipline but the heavyweight tooling is more weight than your situation can justify, and you’d rather the chain lived in the repository than in a separate system you have to keep in sync by hand.

That fits the team that knows the silo-and-drift failure well: a requirements artefact that was right at sign-off and slowly stopped describing the software, because the document and the code lived in different places and only one of them was under version control. RCF’s answer is to put the PRD and the chain in the same repository as the code, so that traceability moves with the build instead of trailing behind it. That’s a smaller, more git-native shape than a full ALM deployment, and for teams that live in their repository it’s a more natural home for the requirements than a tool nobody outside the requirements team opens.

It also fits the team that wants the one-to-one acceptance-criterion-to-test binding as a hard constraint rather than a convention. A traceability matrix will happily record partial coverage and let you move on. The acceptance criterion as a contract is RCF’s way of refusing that: a criterion without a test isn’t done, and the binding is the joint where business intent meets verified behaviour. If you want that joint enforced by the structure rather than by a reviewer remembering to check, RCF gives you a more specific tool than RDD’s general instruction to maintain coverage.

And RCF is built with the agent era in view, which is the one place the classical tradition wasn’t looking. RDD is a pre-AI discipline and it never claimed otherwise. The argument about agents writing the code, and what requirements-first means when they do, is its own subject, and it sits on the spec-driven development page rather than here. The short version is that RCF tries to carry RDD’s requirements-first discipline into a git-native, agent-ready form, so the same chain that satisfies a human reviewer can give an agent a precise, traceable target. That’s the inheritance, brought forward.

The honest summaryCopy link

RDD has decades on RCF, regulatory standing RCF doesn’t have, and a vendor-neutral tooling ecosystem RCF can’t pretend to match. For regulated and safety-critical work, it’s the right answer today and RCF isn’t. For teams already fluent in a mature ALM stack, the switching cost probably isn’t worth it.

What RCF brings is narrower and, I think, still worth having: a chain specified down to the artefact with the cardinality pinned, kept living in the repository and enforced through the build cycle, at lower ceremony than the heavy ALM strand asks for. It’s younger, more opinionated, and without the tooling ecosystem that has grown up around RDD. Those are real costs. The methodology lineage places RDD where it belongs, as one of the foundations the trade has been building toward requirements-first work on for forty years. RCF is the latest step on that road, not a repudiation of the ones before it.