# RDE and SDD: preserve the intent, specify the change.

Requirements-Driven Engineering maintains what a system must do over time. Spec-Driven Development defines a particular change clearly enough to execute and validate it.

Canonical: https://peakroai.com/insights/rde-vs-sdd/
Updated: 2026-10-26


## Two useful questions, two different lifecycles

When a team changes software, it needs to answer both “What should this system do?” and “What should we change now?” Those questions are related, but their answers have different lifecycles.

An implementation task might last a few days. A business rule can remain important for years. If the rule lives only inside the completed task, a later team must reconstruct it from the work history, the code or someone's memory.

Requirements-Driven Engineering gives that rule its own durable identity. Spec-Driven Development uses the relevant requirements to define a bounded change. The combination helps engineers and agents work from current intent while keeping each execution task focused.

## What RDE preserves

A persistent requirement records intended behavior or a constraint. It can be reviewed, changed and connected to architecture decisions, risks, tests and implementation evidence.

Consider an order service. “A customer may cancel their own order before fulfillment starts” is a lasting rule. It still matters after the first cancellation screen ships. A new mobile client, an integration or a different fulfillment process may all affect it.

The requirement needs to remain discoverable and current across those changes. Its relationships help the team identify which decisions and checks may need attention when the business rule changes.

## What SDD packages for execution

A change specification describes the work to carry out now. It identifies relevant requirements, current behavior, intended modifications, boundaries, dependencies and a validation plan.

For the order service, the change might add customer self-service cancellation to an existing operator workflow. The specification describes the screen, API behavior, access checks and tests needed for that increment. It does not need to contain the entire history of order management.

A useful specification gives an implementer enough context to act and enough criteria to know when the proposed solution is acceptable.

## Where agents fit

Agents can help refine specifications, investigate affected code, implement changes and produce tests. Their effectiveness depends on the quality and relevance of the context they receive.

RDE provides an addressable source of intent. SDD selects and structures the context for one execution task. The operating process then defines permissions, review boundaries and acceptance responsibilities.

The product owner decides whether the behavior serves the business. Engineering evaluates feasibility and design. A successful test run is evidence for that decision; it does not replace the decision.

## Start with a small, useful requirement set

Adoption does not require documenting every line of an existing application. Select a meaningful change and identify the rules it could affect. Record those rules, resolve ambiguities with the business and connect the checks that demonstrate them.

After delivery, update the durable requirements to reflect the accepted behavior. Keep temporary implementation detail with the work item unless it belongs in the continuing technical contract.

This creates a repeatable habit: each change improves the software and the quality of the context available for the next one.

## A practical test

Ask whether a new team member can find the current intended behavior without reading all the old tickets. Then ask whether an implementer can understand the next change without receiving the entire system's documentation.

If both answers are yes, the team is separating durable intent from executable work in a useful way.

[Explore the RDE methodology](/methodology/requirements-driven-engineering/) and [follow the order-cancellation example](/methodology/worked-example/).