Product Requirements & Spec-Driven Development (SDD)

Product Requirements & Spec-Driven Development

0:00 Wenn das Schreiben von Code nicht mehr der aufwendigste Teil der Arbeit ist — was wird dann zum Engpass? Diese Frage steht über dem ganzen Kapitel, und die Antwort ist unbequem: Es ist die Klarheit darüber, was eigentlich gebaut werden soll. Ein Agent, der eine vage Anforderung bekommt, liefert zuverlässig ein vages Ergebnis, nur eben schneller als früher.

0:19 Wir schauen uns deshalb an, wie sich die Rolle von Entwicklerinnen und Entwicklern gerade verschiebt, wie man eine Idee in eine formale Spezifikation gießt und wie aus dieser Spezifikation ganz von selbst die Tests entstehen, die das Ergebnis abnehmen.

Product Requirements & Spec-Driven Development

0:33 Drei Stationen, und sie hängen eng zusammen. Zuerst der Blick auf die eigene Rolle: Wo verschiebt sich Ihre Arbeit hin, wenn KI die Routine übernimmt? Dann das Handwerk der Spezifikation — wie aus einer Idee prüfbare Regeln werden. Und zum Schluss die Ernte: Aus denselben Regeln leiten sich Abnahmetests ab. Der rote Faden ist dabei ein einziger Gedanke: Die Spezifikation steuert sowohl die Generierung als auch die Abnahme.

Der T-Shaped Engineer

1:00 Bevor wir über Dokumente reden, ein Blick auf die Menschen. Denn wenn sich die Arbeit verändert, verändert sich auch, was eine gute Entwicklerin oder einen guten Entwickler ausmacht — und das ist eine Beobachtung, die weit über Werkzeugfragen hinausgeht. Das Bild ist buchstäblich zu nehmen: Der senkrechte Strich des „T" ist Ihre fachliche Tiefe — das, worin Sie wirklich gut sind.

1:22 Der waagerechte Balken darüber ist die Breite: ein belastbares Verständnis von Produktmanagement, Design und Betrieb. Neu ist an diesem Konzept nichts, es kursiert seit Jahren. Neu ist, dass es plötzlich praktisch wird. Denn wenn KI die Routinearbeit übernimmt — Boilerplate, Standardstrukturen, das dritte ähnliche Formular —, entsteht Zeit, und die fließt genau in diese Breite: Problemdefinition, Abwägung, Qualitätsurteil.

1:48 Der Balken wächst, weil der Stamm weniger Aufwand kostet. Der erste Punkt ist der ökonomische Kern des ganzen Kapitels: Wenn Code generierbar wird, ist er nicht mehr der Engpass — die klare Problemstellung wird es. Daraus folgt der zweite, und der ist eine Machtfrage: Wer die Spezifikation formuliert, steuert das Ergebnis. Nicht mehr, wer tippt.

2:09 Das verschiebt Einfluss in Richtung derjenigen, die präzise beschreiben können, was sein soll. Der dritte Punkt beschreibt die Bewegung von der anderen Seite: Produkt- und Designentscheidungen rücken näher an die Umsetzung, weil der Weg dorthin kürzer geworden ist. Und was bleibt, ist das Urteilsvermögen — Review wird zur Kernkompetenz, nicht zur lästigen Pflicht am Ende.

2:31 Diese Tabelle wird gern falsch gelesen, deshalb ein Hinweis vorweg: Es steht nicht „früher falsch, heute richtig" da, sondern „früher zentral, zunehmend zentral". Alle drei Zeilen beschreiben dieselbe Bewegung — weg von der Produktion einzelner Artefakte, hin zur Steuerung und Bewertung. Syntax müssen Sie weiterhin lesen können, nur ist das Beherrschen von Syntax kein Unterscheidungsmerkmal mehr.

2:54 Und die dritte Zeile ist die anspruchsvollste: Tiefe in einer Rolle bleibt wertvoll, aber Breite entscheidet zunehmend über die Wirksamkeit. Die Fußzeile bringt es auf den Punkt, und sie ist mir wichtig: Das ist nicht weniger Engineering, es ist anderes Engineering. Diese Übung braucht kein Terminal, nur Ehrlichkeit. Nehmen Sie eine reale Aufgabe von Ihrem Schreibtisch und zerlegen Sie sie in zwei Teile: Was davon ist „Problem definieren", was ist „Lösung tippen"?

3:21 Notieren Sie dann, welcher Anteil tatsächlich an Claude delegierbar wäre und welcher menschliches Urteil braucht. Der Hinweis unten stammt aus der Erfahrung vieler solcher Übungen: Der delegierbare Anteil ist meistens größer, als man beim ersten Nachdenken annimmt. Das ist keine bedrohliche Nachricht, sondern eine nützliche — sie zeigt Ihnen, wo Ihre Zeit künftig besser aufgehoben ist.

Spec-Driven Development

3:44 Wenn also die klare Problemstellung der Engpass ist, dann lohnt es sich, daraus ein Handwerk zu machen. Genau das ist Spec-Driven Development — und es ist weniger neu und weniger bürokratisch, als der Name vermuten lässt. Nehmen wir den Bauplan eines Hauses. Niemand käme auf die Idee, dem Bautrupp zu sagen „mach mal was Schönes mit vier Zimmern" — es gibt eine Zeichnung, und die ist verbindlich.

4:08 Spec-Driven Development überträgt das auf Software: Die abstrakte Idee wird zuerst in eine formale Spezifikation gegossen, und erst daraus entsteht Code. Drei Arten von Regeln gehören hinein — funktionale, also was das System tun soll; nicht-funktionale, also unter welchen Bedingungen; und architektonische Leitplanken. Der Unterschied zum klassischen Lastenheft ist der Adressat: Diese Spezifikation wird nicht abgeheftet, sie wird von Claude Code direkt gelesen und umgesetzt.

4:36 Der erste Satz ist die schmerzhafte Erfahrung, die viele schon gemacht haben: Mehrdeutige Prompts erzeugen mehrdeutigen Code. Der Agent füllt Lücken — er muss das tun, sonst könnte er nicht arbeiten —, und er füllt sie mit Annahmen, die Sie nicht getroffen haben. Eine Spezifikation macht genau diese Annahmen explizit und damit überprüfbar.

4:55 Der zweite Gewinn ist Wartbarkeit: Änderungen passieren an einem Dokument statt verstreut im Code, und Sie sehen im Diff, was sich am Willen geändert hat, nicht nur an der Implementierung. Und weil eine gute Spezifikation teilbar ist, wird sie zur gemeinsamen Grundlage im Team — nicht zum Wissen einer einzelnen Person. Diese fünf Schritte gehen bewusst vom Groben ins Feine.

5:17 Am Anfang stehen Ziel und Nutzer in einem PRD, einem Product Requirements Document — die Frage „für wen und wozu" vor jeder technischen Überlegung. Dann werden die funktionalen Anforderungen zu prüfbaren Regeln, und auf das Wort „prüfbar" kommt es an. Schritt drei ist der, der am häufigsten ausgelassen wird: die nicht-funktionalen Grenzen, also Performance und Sicherheit.

5:40 Danach die Architektur-Leitplanken, und erst im fünften Schritt implementiert Claude Code. Die Fußzeile ist mehr als eine Randnotiz — die Spezifikation lebt im Repository und wird versioniert wie Code. Nur so bleibt sie am Leben. Schauen Sie weniger auf das Format als auf den Charakter dieser Sätze. „Nach fünf Fehlversuchen fünfzehn Minuten Sperre" — da steht eine Zahl, keine Absicht.

6:03 „Unter dreihundert Millisekunden im fünfundneunzigsten Perzentil" — auch das ist messbar, inklusive der Angabe, wie gemessen wird. Genau darin unterscheidet sich eine brauchbare Spezifikation von einem Wunschzettel. Beachten Sie auch die Trennung in funktional und nicht-funktional: Das ist keine Formalie, sondern eine Gedächtnisstütze, damit die zweite Kategorie nicht untergeht.

6:25 Und die Fußzeile weist schon auf das dritte Kapitel voraus: Jede dieser Regeln ist später ein Abnahmekriterium. Was Sie hier schreiben, schreiben Sie doppelt nutzbar. Vier Fallen, und die erste ist die häufigste: „schnell" und „sicher" sind keine Anforderungen, sondern Stimmungen. Ohne Zahl ist eine Regel nicht prüfbar, und was nicht prüfbar ist, wird der Agent nach eigenem Gutdünken auslegen.

6:49 Der zweite Punkt ist ein Klassiker der Softwareentwicklung, lange vor jeder KI: Last und Sicherheit werden vergessen, weil sie beim Happy Path nicht auffallen. Der dritte kennt jeder aus der Dokumentation — Spezifikation und Code driften auseinander, sobald nur noch der Code gepflegt wird. Und der vierte ist die gut gemeinte Falle: alles auf einmal spezifizieren zu wollen. Eine Spezifikation wird iterativ geschärft, nicht in einem Wurf perfekt.

7:16 Jetzt sind Sie dran, und der Maßstab ist bewusst klein: mindestens drei funktionale und zwei nicht-funktionale Regeln. Nehmen Sie dafür eine Idee, die Sie ohnehin im Kopf haben. Der eigentliche Prüfstein steht im Hinweis, und ich empfehle, ihn wörtlich zu nehmen: Formulieren Sie jede Regel so, dass ein Test sie eindeutig prüfen könnte.

7:34 Wenn Ihnen bei einer Regel kein Test einfällt, ist die Regel noch nicht fertig — dann fehlt eine Zahl, eine Bedingung oder ein klares Verhalten. Diese kleine Selbstkontrolle ist erstaunlich wirksam und wird uns im nächsten Kapitel direkt in die Hände arbeiten.

Automatisierte User Acceptance Tests

7:50 Damit sind wir bei der Belohnung für die Mühe. Wenn jede Regel Ihrer Spezifikation prüfbar formuliert ist, dann liegt die Testsuite eigentlich schon vor Ihnen — sie muss nur noch übersetzt werden. Und genau das kann der Agent übernehmen. User Acceptance Tests, auf Deutsch Abnahmetests, beantworten eine andere Frage als Unit-Tests: nicht „funktioniert dieses Stück Code", sondern „bekommt der Nutzer, was zugesagt wurde".

8:14 Genau deshalb passen sie so gut zur Spezifikation. Claude Code leitet aus deren Regeln die Abnahmekriterien ab, gießt sie in Tests und passt anschließend den Code an, bis die Kriterien erfüllt sind. Das Bemerkenswerte an dieser Konstruktion ist die Geschlossenheit: Dasselbe Dokument, das die Umsetzung steuert, liefert auch den Maßstab für die Abnahme.

8:35 Anforderung und Prüfung können gar nicht mehr auseinanderlaufen — jedenfalls nicht unbemerkt. Vier Schritte, und der erste ist entscheidend: Die Spezifikation muss als Kontext übergeben werden, sonst rät der Agent. Dann lassen Sie je Regel ein Abnahmekriterium ableiten — dieser Zwischenschritt sieht nach Umweg aus, lohnt sich aber, weil Sie hier prüfen können, ob die Regel richtig verstanden wurde, bevor Code entsteht.

8:59 Erst danach werden aus den Kriterien ausführbare Tests, und zum Schluss wird implementiert, bis alles grün ist. Behalten Sie die Fußzeile im Blick: Die Spezifikation bleibt die Referenz, die Tests sind nur ihre Übersetzung. Wenn beides nicht mehr zusammenpasst, ändern Sie die Spezifikation — nicht heimlich den Test. Legen Sie diesen Test gedanklich neben die Spezifikation von vorhin, dann sehen Sie die Übersetzung Zeile für Zeile — nur eben nicht in der Syntax, sondern im Sinn.

9:28 Die Regel lautete: nach fünf Fehlversuchen fünfzehn Minuten Sperre. Der Test tut genau das: fünfmal falsch anmelden, dann einmal richtig — und die Erwartung ist, dass selbst das richtige Passwort jetzt abgewiesen wird. Das ist der schöne Moment an dieser Methode: Der Test prüft nicht eine technische Innerei, sondern eine Zusage an den Nutzer.

9:47 Und er ist ohne Interpretationsspielraum aus der Regel ableitbar, weil die Regel eine Zahl enthielt. Vage Regeln produzieren an dieser Stelle gar nichts. Nehmen Sie eine Regel aus Ihrer eigenen Mini-Spezifikation und gehen Sie den Weg bis zum grünen Test. Der Hinweis ist dabei kein Detail, sondern methodisch entscheidend: Sehen Sie den Test zuerst rot.

10:08 Ein Test, der von Anfang an grün ist, beweist nichts — er könnte auch einfach nichts prüfen. Erst wenn er den Fehlerzustand sichtbar macht und danach durch die Implementierung grün wird, wissen Sie, dass er Prüfkraft hat. Diese Reihenfolge werden Sie im nächsten Kapitel wiedersehen, dort steht sie im Zentrum. Als Erfolg gilt ein laufender Test ohne manuelles Nacharbeiten.

10:30 Fassen wir zusammen. Spec-Driven Development kehrt die gewohnte Reihenfolge um: erst die formale Spezifikation, dann der Code — und weil die Spezifikation das Ergebnis steuert, entscheidet ihre Qualität über die Qualität des Codes. Halten Sie die drei Kategorien getrennt: funktional, nicht-funktional, Architektur; die mittlere ist die, die am ehesten vergessen wird.

10:51 Und wenn die Regeln messbar sind, fallen die Abnahmetests fast nebenbei ab. Im nächsten Kapitel drehen wir diese Idee noch eine Stufe weiter und schauen uns Test-Driven Development an — dort wird der Test selbst zur Spezifikation.

Die Spec führt — der Code folgt

11:05 Idee, Spezifikation, Tests, Code — diese Kette ist die Zusammenfassung des ganzen Kapitels, und sie hat eine bemerkenswerte Eigenschaft: Jedes Glied entsteht aus dem vorherigen, keines steht für sich. Was Sie dabei gewinnen, ist weniger Geschwindigkeit als Verlässlichkeit — Sie wissen vorher, woran Sie das Ergebnis messen werden.

11:26 Ein Gedanke für die Pause: Der Aufwand für eine gute Spezifikation verschwindet nicht, er wandert nur nach vorn. Dort ist er billiger. Fragen und das Material zum Nachlesen finden Sie unter www.HCO.de.