Seit langem gehören Wireframes und Prototypen unumstritten zu den Werkzeugen der Business Analyse (BA). In vielen Organisationen zeigt sich jedoch immer wieder die Herausforderung, dass zwischen fachlicher Idee und belastbarer Entscheidungsgrundlage oft eine große Lücke liegt. Der Weg von einer ersten Idee zu einem aussagekräftigen Prototyp ist einerseits aufwendig und andererseits überzeugen klassische Mockups oder Wireframes zwar visuell, bleiben jedoch funktional eingeschränkt; sie erlauben zwar Diskussionen, liefern aber nur begrenzt Erkenntnisse darüber, wie sich eine Lösung tatsächlich verhält und anfühlt.
Mit dem zunehmenden Einsatz generativer KI verändert sich diese Situation. Neue Ansätze ermöglichen es, funktionierende Software‑Prototypen mit geringem technischem Aufwand zu erstellen. Einer dieser Ansätze ist die Nutzung von Spec-driven Development (SDD) mit einem KI-Agenten. Bei diesem Ansatz entwickelt die KI mit dem Menschen gemeinsam Hand in Hand einen lauffähigen Prototyp.
Dieser Beitrag ordnet SDD bewusst aus Sicht der BA ein. Der Fokus liegt dabei nicht auf technischen Details, sondern auf der Frage nach der Bedeutung von SDD in der BA im Unternehmenskontext und nach sinnvoller Integration des Ansatzes in bestehende Prozesse.
Prototypen in der Business Analyse – Wo klassische Ansätze an Grenzen stoßen
Prototypen sind in der Business Analyse etabliert, wobei ihre Aussagekraft in frühen Entscheidungsphasen stark von der Genauigkeit und dem Abstraktionsniveau abhängt.
Typische Artefakte und Mockups der Business Analyse (User Stories, Prozessmodelle oder fachliche Konzepte) sind für fachliche Stakeholder oder Kund:innen oft nicht ausreichend, um sich vorzustellen, wie sich die Lösung später tatsächlich anfühlen wird. Dies kann zu Missverständnissen führen, die lange unentdeckt bleiben, da Anforderungen zwar diskutiert, aber nicht erlebt werden. Ein funktionierender Prototyp wirkt hier als früher Realitätscheck und als fundierte Entscheidungsgrundlage.
Demgegenüber steht jedoch der klassische Engpass, dass ein „echter“ Prototyp Entwicklungszeit erfordert, welche in diesen frühen Phasen der Softwareentwicklung knapp oder anderweitig priorisiert ist.
Genau hier setzen KI‑gestützte Entwicklungsansätze wie SDD an, mit denen BA und KI gemeinsam ausführbare Prototypen anhand von Spezifikationen erstellen können.
Was ist Spec-driven Development?
Spec-driven Development ist ein strukturiertes Vorgehensmodell für die KI‑gestützte Entwicklung von Software. Der Kern des Ansatzes ist die zentrale Rolle der fachlichen Spezifikation und der Überprüfungs-, Planungs- und Freigabefunktion des Menschen in dem Prozess. Die Tools, die genutzt werden, um Spec-driven Development umzusetzen bringen dabei Templates und Promptsammlungen mit. Diese helfen bei der Arbeit mit dem KI-Agenten, um strukturiert und geleitet hilfreiche Dokumente zu erstellen und letztlich den Code zu schreiben. Dadurch bleibt der Ansatz auch für Business Analyst:innen tragbar, da technisches Know-how aktuell zwar noch benötigt wird, aber in den Hintergrund rückt.
Der Prozess gliedert sich formal in drei Schritte:
Spezifikation
Präzise Beschreibung fachlicher Anforderungen, etwa in Form von User Stories, Szenarien, Regeln oder Akzeptanzkriterien.Planung
Ableitung und Strukturierung der Umsetzungsschritte auf Basis der Spezifikation.Implementierung
Generierung der Umsetzung entlang der definierten fachlichen Leitplanken.
Im Unterschied zu experimentellem „Vibe Coding“, bei welchem häufig unstrukturierte Anweisungen an einen Agenten gegeben werden, steht Spec-driven Development für Nachvollziehbarkeit, Struktur und Wiederverwendbarkeit. Die KI übernimmt operative Aufgaben, während der Mensch eine steuernde, prüfende und fachlich verantwortliche Rolle einnimmt.
Prototypen mit Spec-driven Development
In der Praxis lässt sich Spec-driven Development gut nutzen, um fachliche Ideen schnell in funktionierende Prototypen zu überführen.
Ein typischer Ablauf sieht folgendermaßen aus:
Eine neue Funktion wird textuell oder durch User Stories in einem Prompt beschrieben (BA)
Daraus entstehen eine strukturierte, überprüfbare Spezifikation und weitere Artefakte (KI)
Diese Spezifikation wird überprüft, eventuell verändert und bestätigt (BA)
Aus der Spezifikation wird der Code generiert (KI)
Der Prototyp wird getestet – intern oder mit ausgewählten Nutzer:innen. (BA)
Erkenntnisse fließen in eine überarbeitete Spezifikation und in den weiteren Prozess
Die Artefakte (Spezifikation, Task-Liste) können im weiteren Prozess weiter genutzt werden, wodurch diese nicht noch mal extra erstellt werden müssen, was Zeit spart.
Im Prozess könnte die konkrete Einbettung des SDD folgendermaßen aussehen und dabei beliebige iterative Schleifen enthalten:
Im Gegensatz zu klassischen Mock Ups bringt dieser Ansatz einen tatsächlich ausführbaren Prototypen hervor, der die perfekte Grundlage bildet um:
Funktionen konkret auszuprobieren
Nutzerverhalten zu beobachten
UX‑Probleme früh zu erkennen
fachliche Annahmen gezielt zu überprüfen
Der Prototyp wird damit zu einem Experimentierraum für fachliche Fragestellungen und keineswegs zu einer Vorwegnahme der späteren Produktentwicklung.
Zwei konkrete Beispiele
Ein Kunde hatte Schwierigkeiten, sich eine von uns ausgedachte Idee zur Verbesserung des Arbeitsprozesses konkret vorzustellen. Unser Mock-Up bzw. unsere Anwendungsbeschreibung war wenig aussagekräftig, da die Zeitersparnis nicht direkt ersichtlich war. Diesen konkreten Use Case haben wir also mithilfe von Spec-driven Development in ca. 1,5 h in einen ausführbaren Prototyp überführt. Nun kann er vom Kunden selbst ausprobiert werden und dadurch die Zeitersparnis deutlich erlebbar machen. Außerdem kann die User Experience direkt besprochen und im Implementierungsschritt später durch Entwickler:innen angepasst werden.
Bei einer internen Anwendung zum Lernen von Namen sollte ein neuer Spielmodus implementiert werden. Aber wir haben uns gefragt, ob sich die Arbeit wirklich lohnt und ob der Modus wirklich so spaßig wäre. Deshalb habe ich auch hier einen neuen Spielmodus mithilfe von SDD in 45 min als ausführbaren Prototypen entwickelt. Das Ergebnis? Der Spielmodus kommt sehr gut an und wird nun von den Entwickler:innen implementiert.
Praxisbeobachtungen
In ersten praktischen Anwendungen zeigt sich, dass Spec-driven Development besonders gut für explorative Fragestellungen geeignet ist. Also zum Beispiel bei neuen Features oder noch unscharfen Produktideen.
Der erste Prototyp ist selten „richtig“ und der Prozess ist iterativ. Entsprechend muss der Prototyp durch Prompts nach der ersten Erstellung verfeinert werden. Im Vergleich zu klassischen Entwicklungsprozessen entsteht jedoch sehr schnell ein lauffähiges Ergebnis, das diskutiert und bewertet werden kann.
Auffällig ist dabei die veränderte Rolle der Business Analyse. Statt Anforderungen primär zu dokumentieren, wird aktiv mit dem Prototyp gearbeitet. Es werden neue Werkzeuge verwendet; es wird gepromptet statt in Powerpoint, Word oder Balsamiq zu arbeiten. Außerdem ändern sich die Schritte im Prozess; statt der Erstellung eines groben Wireframes mit kurzer UX Diskussion kann nun anhand des Prototypen konkretes Nutzerverhalten analysiert und der Prototyp dementsprechend angepasst werden. Das bedeutet, dass BA künftig neue Skills brauchen und andere Diskussionen mit den Stakeholdern führen können.
Mehrwert für Business Analyse und Organisationen
Aus organisatorischer Sicht ergeben sich mehrere relevante Vorteile:
Fachliche Hypothesen lassen sich früh überprüfen. Diskussionen verlagern sich von Meinungen hin zu beobachtbarem Verhalten.
Ein funktionierender Prototyp dient als gemeinsamer Referenzpunkt für Business Analyse, Fachbereich und Entwicklung.
Business Analyst:innen können Ideen explorieren, ohne sofort Entwicklungsressourcen zu binden. Das führt zu klareren Anforderungen.
Die entstehenden Spezifikationen bleiben erhalten und können später als Grundlage für Anforderungen, Konzepte oder Abstimmungen genutzt werden.
Risiken und Grenzen
Trotz aller Potenziale ist ein realistischer Blick wichtig:
Schnell entstehende Prototypen können falsche Erwartungen wecken. Ein Prototyp ist ein Experiment und keine produktionsreife Lösung.
Ohne technische Expertise lässt sich die Qualität des erzeugten Codes nur eingeschränkt bewerten. Für produktive Systeme bleiben Entwickler:innen in späteren Schritten unverzichtbar.
Auch bei guter Spezifikation bleibt KI fehleranfällig. Iterationen sind daher Teil des Prozesses.
Der Einstieg erfordert Vorbereitung, geeignete Tools und ein Grundverständnis technischer Zusammenhänge, welches in diesem Beitrag absichtlich ausgelassen wurde, da es den Rahmen sprengen würde.
Leitplanken für den Einsatz im Unternehmen
Aus der bisherigen Praxis lassen sich einige Empfehlungen ableiten:
Klein anfangen, denn klar abgegrenzte Funktionen eignen sich besonders gut.
Prototypen bewusst als Experimente verstehen, bei denen der Erkenntnisgewinn im Vordergrund steht.
Nutzerfeedback priorisieren, denn der größte Mehrwert entsteht durch echtes Nutzungserleben.
Fazit
Spec-driven Development eröffnet neue Möglichkeiten für die Business Analyse, insbesondere in frühen Phasen der Produkt‑ und Anforderungsarbeit. Der Ansatz verbindet fachliche Spezifikation mit funktionierenden Software‑Prototypen und ermöglicht es, Ideen schneller zu validieren und fundierter zu diskutieren.
Gleichzeitig ist SDD kein Ersatz für klassische Softwareentwicklung. Der Ansatz erfordert Einarbeitung, klares Erwartungsmanagement und setzt in späteren Phasen trotzdem noch eine Neuimplementierung voraus.
Richtig eingesetzt, kann der Ansatz jedoch einen messbaren Beitrag zur Qualität von Entscheidungen und Ergebnissen leisten und zusätzlich Dokumentationen zur Verfügung stellen, die konkret Zeit sparen.
Ausblick
Generative KI verändert etablierte Arbeitsweisen. Für die Business Analyse bedeutet das eine Erweiterung der Rolle, weg von reiner Dokumentation, hin zu aktiver Exploration und Validierung von Ideen.
Spec-driven Development ist ein möglicher Baustein auf diesem Weg. Die zentrale Frage für Unternehmen ist daher nicht, ob solche Ansätze relevant werden, sondern wie sie sinnvoll, verantwortungsvoll und integriert in bestehende Prozesse eingesetzt werden können.
Weitere Fragen, die die weitere Nutzung und Elaboration von SDD klären muss:
Wie reagieren Unternehmen auf diesen Ansatz der Prototypenentwicklung?
Wie gehen Entwickler:innen damit um, dass es schon einen lauffähigen Prototyp gibt?
Wir unterstützen gerne bei der Evaluierung und Einführung von Spec-driven Development. Sprechen Sie uns gerne an.
