Katalog
concept#Softwareentwicklung#Lieferung#Qualitätssicherung

Spec Driven Development (SDD)

Ein konzeptioneller Ansatz, bei dem ausführbare Spezifikationen zentrale Steuerungs- und Verifikationsquelle für Anforderungen, Design und Tests sind.

Spec Driven Development (SDD) ist ein konzeptioneller Ansatz, bei dem ausführbare Spezifikationen als zentrale Quelle für Anforderungen, Design und Tests dienen.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Organisatorisch
  • Organisation
  • Fortgeschritten

Technischer Kontext

Cucumber / Gherkin für ausführbare SzenarienCI/CD-Systeme (z. B. Jenkins, GitHub Actions)Test- und Mock-Frameworks zur Isolation

Prinzipien & Ziele

Spezifikationen sind lebende Artefakte und single source of truthDomänennähe: Sprache und Beispiele müssen für Fachseite verständlich seinAutomatisierung: Spezifikationen sind ausführbar und in der Pipeline verifizierbar
Umsetzung
Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Falsche Spezifikationen führen zu falscher Implementierung
  • Übermäßige Testfragilität durch schlecht designte Szenarien
  • Widerstand in Organisationen ohne geteilte Verantwortung
  • Kleine, fokussierte Szenarien statt großer, monolithischer Tests
  • Spezifikationen als lebendes Artefakt in der Versionsverwaltung
  • Klare Trennung zwischen Geschäftslogik und technischen Implementierungsdetails

I/O & Ressourcen

  • Fachliche Anforderungen und Beispiele
  • Toolchain für ausführbare Spezifikationen (z. B. Cucumber)
  • CI/CD-Infrastruktur zur Ausführung
  • Versionierte, ausführbare Spezifikationen
  • Automatisierte Testreports und Metriken
  • Geringere Anzahl unklarer Anforderungen bei Übergaben

Beschreibung

Spec Driven Development (SDD) ist ein konzeptioneller Ansatz, bei dem ausführbare Spezifikationen als zentrale Quelle für Anforderungen, Design und Tests dienen. Teams formulieren präzise Spezifikationen in domänennaher Sprache und nutzen sie zur automatischen Verifikation. SDD fördert gemeinsame Verantwortung und reduziert Missverständnisse zwischen Fachseite und Entwicklung.

✔

  • Verbesserte Kommunikation zwischen Fach- und Entwicklungsteams
  • Frühe Fehlerentdeckung durch automatisierte Verifikation
  • Klar definierte Akzeptanzkriterien reduzieren Nacharbeit

✖

  • Erfordert disziplinierte Pflege der Spezifikationen
  • Aufwand für Aufbau und Automatisierung kann initial hoch sein
  • Nicht jede technische Detailentscheidung gehört in die Spezifikation

  • Spezifikationsabdeckung

    Anteil der funktionalen Anforderungen, die durch ausführbare Spezifikationen abgedeckt sind.

  • Automatisierte-Test-Status

    Prozentsatz erfolgreicher Ausführungen der Spezifikations-basierten Tests in der Pipeline.

  • Lead Time für Änderungen

    Zeit von der Spezifikationsänderung bis zur erfolgreichen Verifikation in CI.

E-Commerce Checkout

Checkout-Akzeptanzkriterien als ausführbare Szenarien, die Zahlungen, Coupons und Versandregeln abdecken.

Banküberweisung API

API-Verhalten und Fehlerfälle werden als Spezifikationen formuliert und gegen Implementierung automatisiert getestet.

B2B Vertragslogik

Geschäftsregeln in verständlicher Sprache mit Beispielen, die für Automatisierung und Juristentests genutzt werden.

1

Einführung eines einheitlichen Spezifikationsformats (z. B. Gherkin).

2

Schulung von Fach- und Entwicklungsteams zur gemeinsamen Formulierung von Beispielen.

3

Aufbau einer minimalen Toolchain zur Ausführung von Spezifikationen in CI.

4

Schrittweise Migration bestehender Akzeptanzkriterien in ausführbare Spezifikationen.

5

Regelmäßige Review-Zyklen zur Pflege und Verfeinerung der Spezifikationen.

⚠️ Technische Schulden & Engpässe

  • Unstrukturierte Spezifikationssammlung ohne Versionskontrolle
  • Veraltete Mock-Implementierungen, die falsche Sicherheit vermitteln
  • Fehlende Testdatenpflege, die zu instabilen CI-Läufen führt
Unzureichende TestinfrastrukturMangel an Domänenwissen im TeamLangsame CI-Laufzeiten
  • Spezifikationen, die ausschließlich von Entwicklern und nicht von Fachseite geschrieben werden.
  • Spezifikationen, die jede Implementierungsentscheidung vorschreiben und so Agilität einschränken.
  • Hoher Automatisierungsanteil bei flüchtigen Anforderungen, der Wartungskosten treibt.
  • Verwechslung von Testdaten mit Spezifikationsinhalt
  • Unzureichende Pflege führt zu veralteten, irreführenden Spezifikationen
  • Mangelnde Sichtbarkeit der Spezifikationsfehler für Fachseite
Domänenmodellierung und SpezifikationsformulierungAutomatisierung und TestentwicklungCI/CD-Konfiguration und Pipeline-Engineering
Nachvollziehbarkeit von AnforderungenAutomatisierbarkeit in CI/CD PipelinesDomänenverständnis und gemeinsame Sprache
  • • Verfügbarkeit stabiler Testdaten
  • • Einsatz akzeptierter Spezifikationsformate (z. B. Gherkin)
  • • Organisatorische Zustimmung zur gemeinsamen Pflege