Ein Tool entsteht, das die eigene Methodik gegen sich selbst prüft
Requirements Dialogue ist keine Theorie, die auf ein Anwendungsbeispiel wartet. Sie entsteht direkt an einem Werkzeug, das nach ihren eigenen Regeln gebaut wird — während diese Regeln selbst noch geschärft werden.
Die letzten vier Artikel dieser Serie haben ein Bild zusammengesetzt: Scrum löst ein Koordinationsproblem, das gerade verschwindet. SAFe beantwortet dasselbe Problem mit noch mehr Prozess, statt es strukturell zu reduzieren. Drei Achsen — Abstimmung, Vorabwissen, Konsistenz — erklären, warum keine bisherige Methode an allen drei Stellen gleichzeitig trägt. Und acht Monate Alleinbau haben gezeigt, dass eine Methodik sich erst dann beweist, wenn sie an echten Fehlern gemessen wird, nicht an einem sauberen Gedankenexperiment.
Dieser Artikel beschreibt, was aus alledem tatsächlich entsteht.
Weder Rückkehr noch Weiterentwicklung
Requirements Dialogue ist keine Rückkehr zu Wasserfall und keine Weiterentwicklung von Scrum. Es ist der Versuch, das einzulösen, was das Spiralmodell schon 1986 wollte, aber mangels Werkzeug nicht konnte: eine unbegrenzt oft wiederholbare, risikogetriebene Verfeinerung von Anforderungen, mit einem harten, unhintergehbaren Abschlusskriterium pro einzelner Anforderung, und einer strukturell unvoreingenommenen Prüfinstanz, gehalten in einem maschinell konsistent gehaltenen, nie überschriebenen Korpus.
Vier Bausteine tragen das:
Ein vierstufiges Modell, das für jede Aussage im Anforderungskorpus festhält, wie verbindlich sie ist — unmittelbar vom Entscheider bestätigt, logisch abgeleitet, vorläufig angenommen, oder lediglich vorgeschlagen. Dieser Zustand ist keine Formalität. Er bestimmt, mit welcher Sicherheit eine Aussage weiterverwendet werden darf.
Ein Dialog zwischen zwei Rollen mit strukturell getrenntem Kontext: Eine Rolle führt den eigentlichen Dialog mit dem Entscheider. Eine zweite, unabhängige Instanz prüft die entstandenen Aussagen ohne Kenntnis der vorherigen Verhandlung auf Widersprüche und Lücken. Findet sie etwas, geht die erste Rolle in eine zweite Runde, bei Bedarf mit hartnäckiger Nachfrage, bis der eigentliche Kern einer Anforderung wirklich freigelegt ist.
Ein hartes Abschlusskriterium pro Einzelaussage, kombiniert mit unbegrenzter Offenheit auf Ebene des Gesamtkorpus. Eine einzelne Anforderung gilt erst als verbindlich, wenn der Entscheider entweder eine ausformulierte Fassung ausdrücklich bestätigt oder selbst eine eigene Formulierung liefert — und eine Bestätigung ist nur gültig, wenn ihr unmittelbar die exakte Formulierung vorausging, auf die sie sich bezieht. Gleichzeitig bleibt der gesamte Korpus jederzeit erweiterbar, weil ein reales Produkt nie vollständig fertig ist.
Additive statt überschreibende Korrektur. Ändert sich eine Anforderung, wird die vorherige Fassung sichtbar durchgestrichen, die neue danebengestellt. Die Historie bleibt vollständig nachvollziehbar, ohne den aktuellen Stand zu verdecken.
Ein Werkzeug, das seine eigene Methode beweisen muss
Das Werkzeug, an dem das entsteht, heißt CCIDE. Es orchestriert mehrere KI-Instanzen, um Softwareentwicklung sichtbar und steuerbar zu machen — und es wird nach genau den Regeln gebaut, die es selbst umsetzen soll, während diese Regeln noch geschärft werden. Das ist kein Umweg, sondern der eigentliche Punkt: 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, bevor sie an anderer Stelle zum Problem wird.
CCIDE ist aktuell in aktiver Entwicklung. Es gibt noch keine öffentliche Version — aber es gibt einen Ansatz, der offen dokumentiert ist, an einem echten Projekt erprobt wird, und dessen Grenzen genauso offen benannt sind wie seine Stärken.
Im letzten Artikel dieser Serie geht es darum, wer als Erstes selbst damit arbeiten kann.