Catalog
concept#Software Engineering#Delivery#Quality Assurance

Spec Driven Development (SDD)

A conceptual approach where executable specifications act as the central control and verification source for requirements, design, and tests.

Spec Driven Development (SDD) is a conceptual approach where executable specifications serve as the central source for requirements, design, and tests.
Established
Medium

Classification

  • Medium
  • Organizational
  • Organizational
  • Intermediate

Technical context

Cucumber / Gherkin for executable scenariosCI/CD systems (e.g., Jenkins, GitHub Actions)Test and mock frameworks for isolation

Principles & goals

Specifications are living artifacts and the single source of truthDomain closeness: language and examples must be understandable to domain expertsAutomation: specifications are executable and verifiable in the pipeline
Build
Domain, Team

Use cases & scenarios

Compromises

  • Incorrect specifications lead to wrong implementation
  • Excessive test fragility from poorly designed scenarios
  • Resistance in organizations without shared ownership
  • Small, focused scenarios instead of large monolithic tests
  • Specifications as living artifacts in version control
  • Clear separation between business logic and technical implementation details

I/O & resources

  • Business requirements and examples
  • Toolchain for executable specifications (e.g., Cucumber)
  • CI/CD infrastructure for execution
  • Versioned, executable specifications
  • Automated test reports and metrics
  • Fewer ambiguous requirements during handovers

Description

Spec Driven Development (SDD) is a conceptual approach where executable specifications serve as the central source for requirements, design, and tests. Teams write precise, domain-oriented specifications and use them for automated verification. SDD fosters shared responsibility and reduces misunderstandings between domain experts and developers.

✔

  • Improved communication between domain and development teams
  • Early bug detection via automated verification
  • Clearly defined acceptance criteria reduce rework

✖

  • Requires disciplined maintenance of specifications
  • Effort to set up and automate can be high initially
  • Not every technical detail belongs in the specification

  • Specification coverage

    Portion of functional requirements covered by executable specifications.

  • Automated test pass rate

    Percentage of successful executions of specification-based tests in the pipeline.

  • Lead time for changes

    Time from specification change to successful verification in CI.

E-commerce checkout

Checkout acceptance criteria as executable scenarios covering payments, coupons and shipping rules.

Bank transfer API

API behavior and error cases are specified and automatically tested against the implementation.

B2B contract logic

Business rules in readable language with examples used for automation and legal review tests.

1

Introduce a unified specification format (e.g., Gherkin).

2

Train domain and development teams to write examples collaboratively.

3

Set up a minimal toolchain to execute specifications in CI.

4

Gradually migrate existing acceptance criteria into executable specifications.

5

Regular review cycles for maintenance and refinement of specifications.

⚠️ Technical debt & bottlenecks

  • Unstructured specification collection without version control
  • Outdated mock implementations that give false confidence
  • Missing test data maintenance causing unstable CI runs
Insufficient test infrastructureLack of domain knowledge in the teamSlow CI runtimes
  • Specifications written only by developers and not by domain experts.
  • Specifications that prescribe every implementation decision and thus restrict agility.
  • High automation coverage for volatile requirements, driving maintenance costs.
  • Confusing test data with specification content
  • Insufficient maintenance leading to outdated, misleading specifications
  • Lack of visibility of specification failures to domain experts
Domain modeling and specification writingAutomation and test developmentCI/CD configuration and pipeline engineering
Traceability of requirementsAutomatability in CI/CD pipelinesDomain understanding and ubiquitous language
  • • Availability of stable test data
  • • Use of agreed specification formats (e.g., Gherkin)
  • • Organizational agreement on shared maintenance