Wikiwand AI

Spec-driven Development

From Wikipedia, the free encyclopedia

Spec-driven Development (auch Specification-driven Development, kurz SDD) ist eine Arbeitsweise der KI-gestützten Softwareentwicklung, bei der eine strukturierte Spezifikation als zentrale Grundlage des Entwicklungsprozesses dient. Sie wird vor der Implementierung erstellt und bildet für Softwareentwickler und generative KI-Modelle die maßgebliche Referenz (Single Source of Truth). Quellcode, Tests und weitere Entwicklungsartefakte können aus der Spezifikation abgeleitet oder auf ihre Übereinstimmung mit ihr geprüft werden. Der Ansatz wird dabei häufig als stärker strukturierte Alternative zum Vibe-Coding eingeordnet.[1][2]

Begriff

Der Begriff Spec-driven Development wird in der Fachliteratur und von Anbietern von Entwicklungswerkzeugen uneinheitlich verwendet und ist nicht eindeutig definiert.[3] Vereinzelt wurde die Bezeichnung bereits vor der Verbreitung generativer Sprachmodelle verwendet, etwa 2004 für einen agilen Ansatz, der testgetriebene Entwicklung mit dem Prinzip des Design by Contract verbindet.[4] In seiner heutigen Bedeutung bezeichnet der Begriff jedoch überwiegend eine Arbeitsweise der KI-gestützten Softwareentwicklung. Die Grundidee, das gewünschte Verhalten zunächst zu spezifizieren und die Implementierung daran auszurichten, teilt Spec-driven Development mit älteren Verfahren wie der testgetriebenen Entwicklung, dem Behavior Driven Development und der modellgetriebenen Softwareentwicklung.[3][1][5]

Ansatz

Beim Spec-driven Development wird der Implementierung einer Software oder einzelner Features eine strukturierte Spezifikation vorangestellt, die das gewünschte Verhalten in natürlicher Sprache beschreibt. Sie enthält insbesondere Anforderungen, Randbedingungen sowie Sonderfälle und dient als Referenz für die weitere Planung und Umsetzung. Eine solche Spezifikation liefert einem KI-Agenten den entsprechenden Kontext, aus dem er Quellcode, Tests und weitere Artefakte erzeugt.[2][6]

Die zugehörigen Vorgehensmodelle gliedern die Entwicklung in aufeinanderfolgende Schritte, bei denen jeweils ein eigenes Dokument entsteht. Üblicherweise werden zunächst übergeordnete Grundsätze und Anforderungen festgehalten. Anschließend werden Mehrdeutigkeiten aufgelöst, die Architektur geplant und die Arbeit in einzelne Aufgaben zerlegt, bevor die Implementierung mit KI-Unterstützung erfolgt und das Ergebnis abschließend gegen die Spezifikation geprüft wird. Auf diese Weise sollen die ursprünglichen Anforderungen über alle Stationen der Entwicklung erhalten bleiben, statt auf dem Weg von den Bedürfnissen der Beteiligten über Anforderungen und Architektur bis zur Umsetzung mehrfach neu interpretiert zu werden.[3][6]

Üblicherweise werden drei aufeinander aufbauende Reifegrade unterschieden.[3][2][1] Beim Spec-first-Vorgehen entsteht die Spezifikation einmalig zu Beginn der Arbeit an einem Feature und wird danach nicht zwingend weitergepflegt. Bei Spec-anchored bleibt sie nach der Implementierung als Referenz für die Weiterentwicklung erhalten und wird fortgeschrieben, wobei sie sich auch auf einzelne Funktionen oder Entwicklungsschritte beschränken kann. Dadurch lässt sich der Ansatz iterativ einsetzen. Bei Spec-as-source dient die Spezifikation als primäres Artefakt, aus dessen Änderungen der Quellcode automatisch erzeugt oder aktualisiert wird.[1][3][6][7]

Empirische Befunde

Die empirische Evidenz zu Vor- und Nachteilen von Spec-driven Development ist bislang begrenzt. Eine 2026 veröffentlichte Studie untersuchte rund 88 Tausend Pull-Requests aus 119 Open-Source-Repositories und fand keinen statistisch signifikanten Zusammenhang zwischen den untersuchten Spezifikationsartefakten und einer Verringerung von Programmfehlern oder nachträglichen Korrekturen. Die Studie untersuchte jedoch keine von aktuellen SDD-Werkzeugen erzeugten Spezifikationen.[8]

Eine weitere empirische Untersuchung zeigte, dass die Qualität der Anforderungen die Ergebnisse der Codegenerierung beeinflusst. Eine Studie zu sogenannten Requirement Smells fand bei zunehmender Dichte problematischer Anforderungen eine geringere funktionale Korrektheit des erzeugten Codes. Zugleich führte auch eine hohe Qualität der Anforderungen nicht in allen Fällen zu korrektem Code.[9]

Weblinks

Einzelnachweise

Related Articles

Timelines

Top Qs

Fact Checks