Nobody owns the requirements anymore.Copy link

There was a time when somebody owned the requirements.

Not a committee. Not a process. A person. In defence contracts, in banking systems, in anything where the cost of getting it wrong was high enough to concentrate minds, there was a requirements engineer. Sometimes called a systems analyst, sometimes a business analyst with actual teeth. The job was to sit between the people who needed the thing and the people who built the thing, and make sure both sides understood what was being asked for, what was being promised, and where the gaps were. Before a line of code was written.

That role didn't disappear overnight. It got hollowed out, one cost-cut at a time.

The slow erosionCopy link

Agile was the accelerant. Not the cause, but it gave management the vocabulary to justify what they already wanted to do: move faster, with fewer people doing the upfront thinking. The requirements engineer became a product owner. The product owner became a proxy. The proxy became a developer with a Jira ticket and a best guess.

I've watched this play out for thirty years. The pattern is remarkably consistent. Company starts with a dedicated requirements function. Finance notices it's expensive. Someone argues that requirements work can be "embedded" in the development team. The dedicated role gets merged, then diluted, then quietly dropped. The developers absorb it because someone has to, and they're the ones who'll be blamed when the build is wrong.

The problem is that developers are optimised for building, not for asking "should we build this at all?" Those are different disciplines. A good requirements engineer asks awkward questions early. A developer under delivery pressure skips the awkward questions and writes the acceptance criteria at 3am the night before the sprint review, because the product owner went quiet again three weeks ago and the demo is tomorrow.

This isn't hypothetical. This is Tuesday.

The invisible handoverCopy link

What gets lost when nobody owns requirements isn't paperwork. It's accountability.

When a dedicated role owns the requirements, there's someone whose reputation is on the line for whether the build matches the need. Someone who catches the contradiction between what marketing promised and what engineering is actually delivering. Someone who notices that requirement 14 conflicts with requirement 7, before both are halfway built.

Without that ownership, contradictions survive until integration. Gaps surface in UAT, or worse, in production. And the post-mortem blames "communication" or "alignment," which are polite ways of saying nobody was responsible for making sure the specification was coherent before work started.

The Standish CHAOS reports have been tracking software project outcomes for decades. The top factors in project failure are consistently requirements-related: incomplete requirements, lack of user involvement, unrealistic expectations. Not technology failures. Not bad developers. Requirements. The discipline we decided we could do without.

And then AI showed upCopy link

Now AI has arrived, and it's filled the vacuum in the worst possible way.

Coding agents are writing acceptance criteria. Not because anyone asked them to, not because they're good at it, but because someone has to and they're the ones generating the code. The AI looks at a vague ticket, infers what the requirements probably are, builds something that matches its inference, and presents a working demo. The demo compiles. It runs. It looks plausible. And buried inside it are dozens of decisions that nobody made consciously. Edge cases resolved by statistical likelihood. Business rules inferred from training data. Schema choices that will haunt the team for years, made in milliseconds by a model that has no concept of the business it's building for.

The developer-as-accidental-product-owner has become the AI-as-accidental-requirements-writer. Same structural failure, automated.

Product owners and CEOs can now spring up a prototype in an afternoon. The smart ones recognise that's a prototype. The rest ship it. And the requirements that should have governed the build were never written, never reviewed, never agreed. They were hallucinated by a language model and baked into the architecture before anyone thought to check.

What happens when ownership comes backCopy link

I've spent the last year rebuilding this from first principles.

Not the tooling. The discipline. Starting from the position that requirements are a first-class engineering concern, not a bureaucratic overhead to be optimised away. That someone (or something) needs to own them with the same rigour that we expect from test coverage or deployment pipelines.

The difference is immediate and measurable. When requirements are explicit, traceable, and owned, the build gets smaller. Not because the scope shrinks, but because the waste disappears. No more building features that contradict each other. No more discovering in QA that the acceptance criteria were invented by the developer. No more six-hour debugging sessions that turn out to be specification bugs, not code bugs.

When I gave this discipline back to AI-driven builds, the effect was striking. The AI stopped guessing. It stopped inferring business rules from training data. It built what was specified, and flagged what wasn't. The last twenty percent, the part where AI-generated code goes subtly wrong, shrank. Not because the AI got smarter, but because the inputs got honest.

From what I've seen, the projects that fail aren't under-engineered. They're under-specified. The engineering was never the bottleneck. The thinking before the engineering was.

The methodologyCopy link

This is what RCF, the Requirements Confidence Framework, is built to solve.

Not by adding process. By restoring a discipline that the industry spent two decades stripping out, and making it work at the speed AI now demands. Requirements that trace from business need to test verification. Acceptance criteria that exist before the code, not after. Ownership that's explicit, not assumed.

The labour economics have flipped. Writing code is now the cheapest part of the stack. Which means, for the first time in my career, there's real room to invest in the part that was always the actual problem. The specification. The structure. The thinking.

Nobody owns the requirements anymore. Somebody should.

RCF is how. More at stravica.ai/rcf-methodology.