Zum Inhalt springen
Requirements Dialogue

Methodik

Requirements Dialogue

Wie Software-Anforderungen entstehen, wenn eine KI sie nicht nur aufschreibt, sondern wirklich versteht.

Softwareprojekte scheitern selten an schlechtem Code. Sie scheitern daran, dass niemand genau genug wusste, was eigentlich gebraucht wird — und dass diese Lücke erst spät auffällt, wenn eine Korrektur schon teuer ist. Scrum hat versucht, dieses Problem durch kurze Zyklen zu entschärfen. Wasserfall hat versucht, es durch gründliche Planung vorab zu lösen. Beide haben denselben blinden Fleck: Sie verlassen sich darauf, dass Menschen eine wachsende Menge an Anforderungen im Kopf widerspruchsfrei halten können — und das gelingt ab einer gewissen Größe nie zuverlässig. Requirements Dialogue ist ein anderer Ansatz: ein fortlaufendes, protokolliertes Gespräch zwischen Mensch und KI, das jede Anforderung so lange schärft, bis sie wirklich trägt, und dabei automatisch prüft, ob sie zu allem anderen passt, was bereits feststeht.

Die Kernthese

Die meisten Entwicklungsmethoden lösen zwei Probleme gleichzeitig, ohne sie zu trennen: wie Menschen sich untereinander abstimmen, und wie man wirklich weiß, was gebraucht wird. Wenn ein Großteil der Abstimmung an KI-Agenten übergeht, verschwindet das erste Problem – aber das zweite bleibt genauso wichtig wie vorher. Requirements Dialogue setzt genau dort an: eine KI führt den eigentlichen Anforderungsdialog, eine zweite, unvoreingenommene KI-Instanz prüft jede Aussage kompromisslos auf Widersprüche, und jede Entscheidung bleibt nachvollziehbar dokumentiert – nicht als starre Vorab-Planung und nicht als hektischer Sprint-Rhythmus, sondern als etwas, das so lange weiterwächst und sich verfeinert, wie das Produkt selbst lebt.

Drei-Achsen-Framework

Jede Entwicklungsmethode lässt sich an drei Fragen messen, die in der üblichen Debatte fast immer vermischt werden. Getrennt betrachtet erklären sie, warum bisherige Methoden an unterschiedlichen Stellen an ihre Grenzen gestoßen sind — und warum sich gerade jetzt etwas verschiebt.

  1. 01

    Abstimmungskosten

    Der Aufwand, mehrere Beteiligte so aufeinander abzustimmen, dass ihre einzelnen Arbeiten zusammenpassen. Bei menschlichen Teams wächst dieser Aufwand deutlich schneller als die Teamgröße selbst — mehr Beteiligte heißt überproportional mehr Abstimmungswege.

  2. 02

    Vorabwissen

    Der Grad, in dem die tatsächlichen Anforderungen an ein System schon zu Beginn bekannt oder erkennbar sind. Diese Unsicherheit liegt am Thema selbst, nicht am Prozess — sie lässt sich nicht wegplanen, nur durch echten Kontakt mit der Realität nach und nach auflösen.

  3. 03

    Konsistenzkosten

    Der Aufwand, eine wachsende Menge an Entscheidungen und Anforderungen widerspruchsfrei zu halten, während sie sich über Zeit verändert. Historisch hing diese Achse eng an der ersten, weil derselbe Mensch, der Abstimmung leistet, auch Konsistenz prüfen musste — mit denselben Kapazitätsgrenzen. Diese Kopplung war kein Naturgesetz, nur eine Folge der bisher verfügbaren Werkzeuge.

Einordnung

[TEXT FOLGT — optionaler Einleitungssatz zur Tabelle. Kann auch entfallen; die Tabelle steht auch ohne ihn.]

VorgehensmodellAbstimmungskostenVorabwissenKonsistenzkosten
WasserfallNicht adressiertVorab gesammelt, aber später kaum korrigierbarMenschlicher Disziplin überlassen
ScrumDurch kurze Zyklen und feste Rollen handhabbar gemachtAktiv verbessert durch schnelles FeedbackDurch Zerlegung in Slices eher verschärft
SAFeDurch zusätzliche Prozessebenen skaliert, nicht reduziertWie Scrum, aber durch Overhead verlangsamtNicht gelöst, zusätzliche Ebene nötig
Requirements DialogueNahe null, wenn KI die Umsetzung koordiniertBewusst offengehalten — bleibt Aufgabe des MenschenTechnisch geprüft durch eine zweite, unvoreingenommene KI-Instanz

Werkzeug

CCIDE

In aktiver Entwicklung

Requirements Dialogue ist keine Theorie, die auf ein Anwendungsbeispiel wartet. Die Methodik entsteht direkt an einem echten Softwareprojekt: CCIDE, ein Werkzeug, das mehrere KI-Instanzen orchestriert, um Softwareentwicklung sichtbar und steuerbar zu machen — und das nach seinen eigenen Regeln gebaut wird, während diese Regeln selbst entstehen. Jeder Fehler, den die Methodik nicht gefangen hätte, zählt gegen sie; jede Lücke, die sichtbar wird, fließt zurück in die Methodik selbst. CCIDE ist aktuell in aktiver Entwicklung.

Früher Zugang und Gespräch

[TEXT FOLGT — Wen die Ansprache adressiert und was Interessierte erwarten können.]

Zum Kontaktformular