Demise of Requirements Engineering

or Why "Requirements" Stopped Being the Center of Modern Development

Back in 2017, it seemed obvious: you had analysts, requirements engineers, architects, developers, testers, operations people. Everyone had a role, every role had its artefact, and the artefact moved down the chain.

Today that story is much harder to tell with a straight face.

Not because requirements disappeared overnight. Requirements engineering is still alive as a discipline, still taught, still standardised, and still actively published, including recent editions of foundational textbooks. And in some domains, requirements never stopped being structurally central at all: mission-critical, safety-critical, regulated, and compliance-heavy systems still depend on explicit external requirements imposed by law, regulation, contracts, certification schemes, and sector standards. Fun examples include: IEC 62304 for medical-device software, NASA safety-critical software requirements, and newer cybersecurity rules like the EU Cyber Resilience Act, and German KRITIS-style obligations.

Which got me thinking. If you look at it through Conway’s Law, the point is quadratisch-praktisch-gut: systems tend to mirror the communication structures and control logic of the organisations that build them, and that logic often shows up in law and bureaucracy as formal obligations. Politics, administration, and law often behave like design by requirements: the state has an agenda, that agenda becomes rules, the rules become compliance paperwork, the paperwork becomes software, and then you get to enjoy the UX equivalent of being fined by a PDF. Or if you wanna go full paranoid: government policy is simply architecture expressed as compliance paperwork.

That is to say: in a lot of serious software work, RE should no longer play the central role. We have newer and cooler toys now.

The old model assumed that knowledge could be translated step by step: Domain expert explains reality to an analyst -> Analyst translates that into an analytical model -> requirements Specialist reformulates it into requirements -> Architects turn those into a design -> Devs turn the design into code -> Ops turns code into a running system. That process was already better than building software on a knee, but it still had a fatal flaw: every handoff was a lossy translation.

This is a profound shit. Literally a broken telephone.

By the time the information reaches the people actually building the thing, what remains is often not the original understanding of the domain but a flattened, sterilised, bureaucratically approved imitation of it. Enterprise software is where this gets truly majestic. Business reality gets translated into legal language, then process language, then modelling language, then implementation language. Everyone sounds competent. Nobody is fully talking about the same world.

This is why Khononov’s Learning Domain-Driven Design hit so well: instead of endlessly translating reality between professional dialects, build a shared understanding of the domain and let that shape the software.

That, to me, is the first serious argument against traditional requirements as the central artefact: they are often symptoms of organisational distance. If devs, ops, and business people can only communicate through intermediaries and blessed documents, the team is already paying a tax on misunderstanding (not to say frustrating), and the interest compounds fast. The time “saved” by shielding engineers from domain conversations usually comes back later as rework, clarification, workaround logic, and that wonderfully-infidel scrum rituals.

The second argument matters even more.

Requirements are usually written in a deontic (obligation) mode: the system must do this, shall do that, may do this, must not do that. That style fits procurement, compliance, and command-and-control engineering. But product development in uncertain environments increasingly works in another mode entirely: not command, but hypothesis.

That is a profound shift.

Requirements say: build this ship, but you sit in a bottle.

A hypothesis says: we currently believe this behaviour, capability, or constraint will make the system more successful; now let’s test whether that belief survives reality.

That is not a cosmetic change. In the first case, failure gets framed as poor execution. In the second, failure may simply mean the idea was wrong, the timing was wrong, the tradeoff was bad, the model was incomplete, or we once again discovered that the future refuses to file bug reports.

This is also where first-principles thinking comes in. The useful, not the LinkedIn sigma-grindset version. Strip the problem down to constraints, physics, incentives, interfaces, and failure modes. Ask what actually has to be true, not what some inherited spreadsheet says must be true because it has survived six reorganisations. This is why SpaceX became part of the mythology around modern engineering thinking: first principles is basically a socially acceptable way of saying “have you considered not worshipping legacy assumptions?”

That is also why modern alternatives to classic requirements sound different even when they cover similar ground. Instead of one sacred list of obligations, teams talk about hypotheses, concepts, bounded contexts, strategies, assumptions, executable examples, acceptance tests, and behaviours. In software, that often converges toward DDD and BDD-style work: keep the conversation in the language of the domain, then make expected behaviour testable as early as possible

That changes the question.

The question is no longer “Have we documented the requirement correctly?” The question becomes “Do we actually share the same model of the domain, and can we express that model in a form that can be checked?” A decent test written in domain language often does more useful work than a beautiful requirements document, because it is both a communication device and a lie detector.​

Jump from Gherkin to Personas. From “must” to “explain me.”

This also changes what should count as architecture.

"Architecture" was stuffed full of almost every important early decision. That older understanding still shows up in many textbooks. That older framing still shows up in system-architecture literature, including System Architecture: Strategy and Product Development for Complex Systems, which treats architecture as a discipline for reasoning about major decisions in complex systems. But even there, the point is not that architects should issue decrees from above. It is that teams need explicit ways to reason about choices, tradeoffs, stakeholder needs, and system evolution.

In other words, architecture should not be treated as a sacred cow any more than requirements should. Both are closer to a structured bet.

Strategy, too, is a bet.

That is true for startups, enterprise platforms, and cyber-physical systems alike. A strategy is not a guarantee. It is a working heuristic that remains respectable only until reality humiliates it in public. Once that happens, you update the strategy.

The same applies to many things once called "requirements" especially when they are really assumptions about product success disguised as mandatory system properties, often seemingly stupid without proper explanations.

Of course, none of this means every domain can simply delete requirements tomorrow.

In regulated environments, contractual work, safety-critical systems, and certification-heavy industries (the ridiculous example here is FDA, amazing talk about open-source medical devices btw), requirements still matter because organisations need stable reference points for compliance, procurement, validation, and liability. But even there, the centre of gravity is shifting toward models, simulations, executable specifications, scenario-based validation, and tighter feedback loops rather than blind faith in a giant static document.

So no, RE are not dead-dead. They are undead. They still walk. They still attend meetings. They still consume budget. But they are no longer the unquestioned source of truth in the most interesting parts of engineering.

What is dying is not the need to describe expected system behaviour. What is dying is the belief that a long-lived, centrally authored requirements document should be the master copy of reality. In many modern teams, that role is being taken over by shared domain language, evolving models, executable examples, and hypotheses that are expected to change.

And weirdly enough, this newer approach rhymes with another systems model entirely: Internal Family Systems.

That sounds unhinged until you think about it for five minutes.

IFS says you do not have one clean, rational, unified inner voice running the show. You have parts. Protective parts, reactive parts, wounded parts, managerial parts, firefighter parts, all with their own logic, fears, incentives, and local optimisation strategies. Systems thinking in engineering is often like that too. The user has goals. Ops have goals. Legal, Security, Finance, regulator have goals. Latency has goals. Agents have opinions. Half of engineering is just getting the parts to stop sabotaging each other long enough to produce something useful.

That is why modelling matters. A decent model does not flatten conflict out of existence. It gives the conflict names, boundaries, interfaces, tradeoffs, and testable consequences. Same reason I think this is one of the least stupid ways to write specs and to compose teams of agents: not as one fake omniscient brain, but as a system of parts with roles, interests and relations, memory, constraints, communication patterns, and validation. You do not need to pretend the whole machine is one voice. You need the voices to coordinate without accidentally summoning Satan.

If you are learning systems engineering or software engineering today, this distinction matters.

Learning only the comfortable mainstream is a good way to arrive late. Learning only ye olde ways is worse. Better to understand the underlying mechanics well enough to recognise where your organisation actually is: pre-modelling chaos, classical requirements culture, or post-requirements engineering built around hypotheses, models, and continuous verification.​

That is where the real transition is happening.

Not from discipline to chaos. But from requirements as commands to models as shared tools for understanding reality before reality invoices you for your arrogance.