Spec-Driven Development: Was es ist und warum Ihr Team es braucht

Die meisten Softwareprojekte scheitern nicht an schlechtem Code. Sie scheitern an unklaren Anforderungen, falsch ausgerichteten Erwartungen und Features, die das falsche Problem lösen. Spec-Driven Development begegnet diesem Problem, indem die Spezifikation zum ersten — und wichtigsten — Schritt jedes Features wird.

Bei HTX2 haben wir Spec-Driven Development für alle unsere Projekte übernommen. Hier erfahren Sie, was es ist, warum es funktioniert und wie Sie es umsetzen.

Was ist Spec-Driven Development?

Spec-Driven Development (SDD) ist eine Methodik, bei der jedes Feature eine strukturierte Spezifikationsphase durchläuft, bevor Code geschrieben wird. Die Spec definiert:

Was das Feature tut (Anforderungen)
Warum es existiert (Geschäftskontext)
Wie es gebaut wird (technischer Ansatz)
Wie wir wissen, dass es fertig ist (Akzeptanzkriterien)

Das ist nicht dasselbe wie Wasserfall. Specs sind lebende Dokumente, die sich während der Implementierung weiterentwickeln. Der entscheidende Unterschied zur Ad-hoc-Entwicklung ist, dass man denkt, bevor man tippt.

Der Spec-Driven Workflow

Ein typischer SDD-Workflow folgt diesen Phasen:

1. Analysieren

Die aktuelle Codebasis und den Geschäftskontext untersuchen. Was existiert? Was sind die Einschränkungen? Was sind die Risiken?

2. Spezifizieren

Eine Feature-Spezifikation schreiben, die enthält:

Problemstellung: Welches Problem lösen wir?
Lösungsvorschlag: Wie werden wir es lösen?
Scope: Was ist enthalten und was ist explizit ausgeschlossen?
Technischer Ansatz: Architekturentscheidungen, Datenfluss, Abhängigkeiten
Akzeptanzkriterien: Messbare Bedingungen für „fertig”

3. Planen

Die Spec in implementierbare Aufgaben aufteilen. Jede Aufgabe sollte:

Klein genug sein, um in einer Sitzung abgeschlossen zu werden
Unabhängig testbar sein
Nach Abhängigkeit sortiert sein

4. Implementieren

Das Feature gemäß dem Plan bauen. Die Spec dient als Single Source of Truth — wenn die Implementierung von der Spec abweicht, entweder die Spec aktualisieren oder den Code anpassen.

5. Verifizieren

Die Implementierung gegen Akzeptanzkriterien prüfen. Tests ausführen, Code reviewen, mit Stakeholdern validieren.

Warum Specs zuerst?

Probleme früh erkennen

Der günstigste Zeitpunkt, einen Fehler zu finden, ist bevor man den Code schreibt. Specs zwingen dazu, Edge Cases, Fehlerbehandlung und Integrationspunkte durchzudenken, bevor Stunden in die Implementierung investiert werden.

Das Team ausrichten

Wenn alle dieselbe Spec lesen, gibt es keine Mehrdeutigkeit darüber, was „fertig” bedeutet. Designer, Entwickler und Produktmanager teilen dasselbe mentale Modell.

Paralleles Arbeiten ermöglichen

Mit einer klaren Spec können mehrere Entwickler gleichzeitig an verschiedenen Teilen eines Features arbeiten. Die Spec definiert die Schnittstellen — jeder Entwickler implementiert seinen Teil und weiß, wie er sich einfügt.

Dokumentation automatisch erstellen

Die Spec ist die Dokumentation. Wenn jemand sechs Monate später fragt „Warum funktioniert das so?”, hat die Spec die Antwort.

KI-gestützte Entwicklung verbessern

Dies ist vielleicht der am meisten unterschätzte Vorteil. Wenn Sie einem KI-Coding-Assistenten eine klare Spec geben, verbessert sich die Ausgabequalität dramatisch. Statt zu raten, was Sie wollen, hat die KI explizite Anforderungen, gegen die sie implementieren kann.

Spec-Driven Development mit KI-Agenten

Moderne KI-Coding-Assistenten wie Claude und GPT-5 können an jeder Phase des SDD-Workflows teilnehmen:

Analysieren: KI untersucht die Codebasis und identifiziert Einschränkungen
Spezifizieren: KI hilft beim Erstellen von Specs, schlägt Edge Cases vor
Planen: KI zerlegt Specs in geordnete, implementierbare Aufgaben
Implementieren: KI schreibt Code, der der Spec präzise folgt
Verifizieren: KI führt Tests aus und validiert gegen Akzeptanzkriterien

Der Schlüssel ist, dass KI besser mit Specs arbeitet. Eine Anweisung wie „füge einen Blog-Bereich hinzu” liefert mittelmäßige Ergebnisse. Eine Spec, die Inhaltsmodell, URL-Struktur, i18n-Anforderungen und SEO-Schema definiert, liefert exzellente Ergebnisse.

Ein reales Beispiel

So haben wir bei HTX2 SDD für die SEO-Optimierung unserer Website eingesetzt:

Spec-Auszug:

FAQPage JSON-LD Schema mit i18n-Schlüsseln faq.q1–faq.q5 hinzufügen. Sowohl EN- als auch DE-Seiten müssen lokalisierte FAQ Rich Snippets rendern. Einen separaten <script type="application/ld+json">-Block verwenden.

Mit dieser Spec war die Implementierung unkompliziert — Übersetzungsschlüssel hinzufügen, JSON-LD-Block einfügen, beide Sprachen verifizieren. Keine Mehrdeutigkeit, keine Nacharbeit.

Ohne die Spec hätte ein Entwickler möglicherweise FAQ-Schema nur auf Englisch hinzugefügt, die falsche JSON-LD-Struktur verwendet oder die i18n-Anforderung ganz übersehen.

Erste Schritte mit SDD

Sie brauchen keine speziellen Tools. Eine Markdown-Datei pro Feature reicht:

# Feature: [Name]

## Problem
Welches Problem löst das?

## Lösung
Wie werden wir es lösen?

## Scope
- Im Scope: ...
- Außerhalb des Scope: ...

## Technischer Ansatz
Architektur, Datenfluss, wichtige Entscheidungen.

## Aufgaben
- [ ] Aufgabe 1
- [ ] Aufgabe 2
- [ ] Aufgabe 3

## Akzeptanzkriterien
- [ ] Kriterium 1
- [ ] Kriterium 2

Speichern Sie Specs neben Ihrem Code. Bei HTX2 verwenden wir ein docs/-Verzeichnis mit einer konsistenten Namenskonvention: feature-001-name.md, feature-002-name.md, etc.

Häufige Einwände

„Das verlangsamt uns.” Eine Spec zu schreiben dauert 30 Minuten. Eine fehlerhafte Implementierung zu reparieren dauert Tage. Specs sind schneller, nicht langsamer.

„Anforderungen ändern sich sowieso.” Ja — und das ist in Ordnung. Aktualisieren Sie die Spec. Es geht nicht darum, die Zukunft vorherzusagen, sondern Entscheidungen explizit statt implizit zu treffen.

„Wir sind zu klein für Prozesse.” Man ist nie zu klein, um vor dem Coden nachzudenken. Solo-Entwickler profitieren von Specs genauso wie große Teams — wohl sogar mehr, weil niemand da ist, um Fehler abzufangen.

Das Fazit

Spec-Driven Development dreht sich nicht um Bürokratie. Es geht darum, implizite Annahmen durch explizite Entscheidungen zu ersetzen. Wenn Sie wissen, was Sie bauen, bevor Sie es bauen, wird alles besser: Code-Qualität, Team-Ausrichtung, Liefergeschwindigkeit und — zunehmend — KI-gestützte Entwicklung.

HTX2 nutzt Spec-Driven Development für alle Kundenprojekte. Erfahren Sie mehr über uns oder kontaktieren Sie uns.