What is Requirements-Driven Engineering?
Requirements-Driven Engineering, or RDE, is a method for maintaining explicit, versioned requirements and connecting them to architecture, decisions, implementation work and validation evidence.
A work item describes what changes now. A requirement describes the behavior or constraint that must remain true across changes. Keeping those responsibilities distinct helps people and AI agents understand the current system without reconstructing its intent from years of completed tickets.
Business and product owners steer the work through outcomes, priorities and acceptance criteria. Engineering provides technical judgment and implementation. The method connects those responsibilities through a shared, reviewable model.
How RDE, SDD and agentic execution fit together
| Layer | The question it answers | Typical output |
|---|---|---|
| Requirements-Driven Engineering | What must this system continue to do? | Persistent requirements connected to decisions, risks and tests |
| Spec-Driven Development | What exactly should change now? | A bounded change specification and validation plan |
| Agentic execution | How do we produce and validate the change? | Implementation, tests, documentation and review evidence |
RDE gives Spec-Driven Development a durable source of intent. SDD packages the relevant intent for a particular change. Agents then help carry out the approved work. Each layer has a role; none eliminates the need for the others.
From a business decision to evidence
1. Define the outcome. The business identifies the problem, expected value and constraints.
2. Make intent explicit. Product and domain experts establish the required behavior, exceptions and acceptance criteria.
3. Scope the change. The team identifies affected requirements, dependencies, architecture decisions and risks. It prepares a specification that can be executed and reviewed.
4. Agree the boundaries. Decide what agents may do, which tools and data they may access, and where human review is required.
5. Implement and validate. Engineers and agents produce the change, tests and supporting evidence. Findings can reveal a need to revisit the specification.
6. Accept and preserve. Authorized people evaluate the outcome. Durable requirements and evidence are updated so the next change starts from an accurate foundation.
Follow a concrete, illustrative walkthrough.
Modernization starts with understanding
When documentation is incomplete, code may contain the only surviving expression of a business rule. We start with a bounded part of the system and reconstruct its behavior from code, tests, documents and knowledgeable people.
Observed behavior is not automatically approved behavior. Business owners distinguish rules that must be preserved from defects, obsolete practices and intended changes. The resulting requirements guide modernization and integration testing.
Each completed increment improves the implementation and preserves knowledge for future work.
Autonomy with accountable decisions
Agents can assist with analysis, specifications, code, tests and documentation. The operating model defines eligible work, access, review responsibilities and acceptance authority. Increasing autonomy is an explicit decision supported by evidence.
Business and product owners remain responsible for value and priorities. Engineers remain responsible for architecture, security, reliability and operational readiness. The workflow should make those responsibilities clear rather than hide them inside a prompt.
Work with the tools you already use
RDE is a methodology. RDE Hub is one way to operationalize it, while repositories, CI pipelines, work-management tools and existing documentation can remain part of the environment.
The starting question is what information and controls the team needs, then which existing tools can provide them. A pilot should demonstrate useful behavior before a wider tooling decision.
Measure the whole outcome
Track accepted output, total engineering effort, lead time, defects, rework and review load. Faster code generation is useful when it contributes to a better delivery outcome.
Our pilot ambition is 5× greater engineering efficiency in selected workflows. We define the baseline, include review and integration effort, and report the actual result. The target does not establish a universal multiplier for enterprise projects.