Brauchen wir überhaupt noch Dokumentation? Und wer validiert eigentlich? 

Im ersten Teil dieser Serie haben wir ein Gedankenexperiment gewagt: 
Ein Projektraum, der zunehmend dunkel wird, weil KI operative Tätigkeiten übernimmt. Die Arbeit verschwindet nicht, sie verlagert sich. 

Im zweiten Teil wurde deutlich, dass KI nie im luftleeren Raum arbeitet. Sie sieht nur den Ausschnitt der Realität, den wir ihr bewusst zur Verfügung stellen. Kontext ist damit keine technische Randbedingung, sondern eine Entscheidung. 

Im dritten Teil haben wir darauf aufgebaut und gezeigt, dass Anforderungen nicht einfach aus Daten entstehen. Sie entstehen durch Interpretation und Aushandlung zwischen unterschiedlichen Perspektiven. 

Doch wenn Anforderungen auf diese Weise entstehen, stellt sich eine naheliegende Folgefrage: 
 

Welche Rolle spielen dann noch Dokumentation und Validierung? 

Wozu dokumentieren wir überhaupt? 

Dokumentation ist im Requirements Engineering kein Selbstzweck. Sie dient dazu, Wissen festzuhalten, Zusammenhänge verständlich zu machen und eine gemeinsame Grundlage für Abstimmungen zu schaffen. Gleichzeitig ist sie häufig Voraussetzung für Nachweise, etwa gegenüber Kunden oder regulatorischen Instanzen. 

All diese Zwecke richten sich heute in erster Linie an Menschen. Genau hier beginnt die Verschiebung. 

Wenn KI mit KI spricht 

Im dunklen Projektraum arbeiten zunehmend KI-Systeme miteinander. Ergebnisse werden nicht mehr nur erzeugt, sondern direkt weiterverarbeitet. Gemeint sind dabei nicht nur einzelne Schritte im Requirements Engineering, sondern ganze Ketten über Disziplinen hinweg, von Anforderungen über Architekturentscheidungen bis hin zur Implementierung. 

Erste Ansätze sehen wir bereits heute in automatisierten Workflows, etwa mit Tools wie Microsoft Power Automate oder n8n, in denen spezialisierte KI-Systeme Teilergebnisse erzeugen und ohne manuelle Übergaben weiterreichen. Auch in der Forschung, etwa im Umfeld der Engineering Automation bei Fraunhofer, wird an genau solchen durchgängigen Prozessketten gearbeitet.¹ 

In solchen Übergängen verliert klassische, natürlichsprachliche Dokumentation an Bedeutung. Für Maschinen ist sie nicht die effizienteste Form der Informationsweitergabe. Stattdessen werden Inhalte in strukturierter Form übergeben, etwa als klar definierte Datenstrukturen oder standardisierte Austauschformate, die direkt weiterverarbeitet werden können. 

Dabei wird ein Punkt oft unterschätzt: 
Jede Transformation von Informationen ist potenziell fehleranfällig. Sobald Inhalte von einem Format in ein anderes überführt werden, besteht die Gefahr, dass Bedeutungen verloren gehen oder ungewollt verändert werden. 

Im Requirements Engineering ist das nicht neu. Dokumentation war schon immer eine Form der strukturierten Übersetzung von Wissen zwischen Menschen. Mit dem Einsatz von KI kommt jedoch ein weiterer Akteur hinzu. Informationen werden nicht mehr nur zwischen Menschen ausgetauscht, sondern auch von und zwischen KI-Systemen verarbeitet. Damit steigen die Anforderungen an diese Übersetzung deutlich, insbesondere dann, wenn Informationen ohne menschliche Interpretation weiterverarbeitet werden. 

Diese Herausforderung zeigt sich auch in der Praxis. In der SOPHIST Prompting Guideline wird deshalb unter anderem die Regel formuliert, das Ausgabeformat bewusst zu definieren. Nur wenn klar ist, in welcher Struktur ein Ergebnis vorliegt, kann es zuverlässig weiterverarbeitet werden, sowohl durch Menschen als auch durch nachgelagerte KI-Systeme. 

Es entstehen also drei Formen der Kommunikation: 

• Zwischen Menschen geht es darum, Bedeutung zu klären. 
• Zwischen Mensch und KI darum, Bedeutung explizit zu machen. 
• Zwischen KI-Systemen darum, Bedeutung eindeutig und verlustfrei zu übergeben. 

Dokumentation wird damit zur Schnittstelle zwischen Menschen und Maschinen. Entscheidend ist nicht mehr nur, ob dokumentiert wird, sondern in welcher Form Informationen so bereitgestellt werden, dass sie zuverlässig weiterverarbeitet werden können. 

Dokumentation wird selektiv – und kritischer 

Die Frage, was dokumentiert werden muss, ist im Requirements Engineering nicht neu. Neu ist jedoch der Kontext, in dem diese Frage beantwortet wird. Dokumentation richtet sich nicht mehr ausschließlich an Menschen, sondern mit zunehmender Automatisierung auch an Systeme, die Informationen direkt weiterverarbeiten. 

Dadurch verändert sich weniger die Fragestellung selbst als vielmehr die Konsequenz ihrer Beantwortung. Unklare, implizite oder inkonsistente Informationen werden nicht mehr im Dialog aufgelöst, sondern fließen unmittelbar in nachgelagerte Verarbeitungsschritte ein. 

Gleichzeitig zeigt die Praxis, dass Nachvollziehbarkeit nicht automatisch gegeben ist. Viele Systeme sind unvollständig dokumentiert und dennoch produktiv im Einsatz. Entscheidend ist daher nicht die Existenz von Dokumentation, sondern die Möglichkeit, getroffene Entscheidungen bei Bedarf rekonstruieren zu können. 

Ein zentraler Unterschied zeigt sich im Umgang mit fehlerhaften oder unvollständigen Informationen. 
Ein erfahrener Entwickler bewertet Informationen im Kontext, erkennt Unsicherheiten und hinterfragt Annahmen. 

Ein KI-System hingegen erzeugt auf Basis seiner Trainingsdaten ein statistisch wahrscheinliches Ergebnis. Dieses kann überzeugend wirken, ist jedoch nicht zwangsläufig auf die konkrete Entwicklungssituation abgestimmt. 

Gerade bei unvollständigen oder fehlerhaften Informationen zeigt sich dieser Unterschied deutlich. Während Menschen solche Schwächen häufig erkennen und relativieren, werden sie in automatisierten Verarbeitungsschritten konsistent weiterverarbeitet. 

Damit gewinnt ein bekanntes Prinzip an neuer Bedeutung: 
Garbage in, garbage out. 

Fehler werden nicht mehr lokal erkannt und korrigiert, sondern können sich entlang automatisierter Verarbeitungsschritte fortpflanzen und verstärken. Dokumentation muss daher nicht umfangreicher werden, sondern an den entscheidenden Stellen präzise und eindeutig interpretierbar sein. 

Validierung verschiebt sich und wird greifbarer 

Validierung beantwortet eine einfache, aber entscheidende Frage: 
Erfüllt das, was wir bauen wollen, tatsächlich den Bedarf? 

Mit dem Einsatz von KI verändert sich genau dieser Punkt. 
Was früher abstrakt beschrieben wurde, kann heute früh sichtbar gemacht werden. Erste Ergebnisse entstehen direkt und können gemeinsam bewertet werden. Ein Requirements Engineer kann während eines Gesprächs aus einer Beschreibung unmittelbar einen Prototypen erzeugen lassen. Benutzeroberflächen, Abläufe oder sogar physische Konzepte werden direkt erlebbar. Validierung findet damit nicht mehr zeitversetzt statt, sondern im Moment der Entstehung. Missverständnisse werden nicht erst in Dokumenten erkannt, sondern im Verhalten des Systems selbst. 

Der Fokus verschiebt sich. 
Weniger hin zur Frage, ob eine Anforderung korrekt formuliert ist. 
Mehr hin zur Frage, ob das sichtbare Ergebnis tatsächlich den Erwartungen entspricht. 

Ein Beispiel aus der Praxis 

In einer Entwicklung soll ein digitales Bestellsystem für einen Online-Shop entwickelt werden. Ein Requirements Engineer spricht mit einem Stakeholder über die zukünftige Benutzeroberfläche. 

Der Stakeholder formuliert: 
„Der Nutzer soll seine Bestellungen schnell einsehen und filtern können.“ 

Statt diese Aussage zunächst detailliert zu spezifizieren, wird sie direkt in ein KI-gestütztes Design-Werkzeug überführt, etwa in Tools wie Google Stitch, Figma, v0 von Vercel oder vergleichbare Lösungen. Innerhalb weniger Sekunden entsteht ein erster, teilweise bereits klickbarer Entwurf. 

Im Gespräch zeigt sich, dass nicht die Filter im Vordergrund stehen, sondern eine schnelle Wiederbestellung. Die vermeintlich klare Anforderung verändert sich im direkten Austausch. 

Die Validierung erfolgt nicht mehr primär über Beschreibung, sondern über Verhalten. Missverständnisse werden unmittelbar sichtbar. 

Ein ähnliches Prinzip lässt sich auch auf physische Systeme übertragen. 
Ein Stakeholder beschreibt eine Geräteidee, etwa ein neues Bedienkonzept für ein technisches Produkt. Die KI erzeugt daraus ein 3D-Modell, das entweder direkt visualisiert oder sogar über einen 3D-Drucker als Prototyp bereitgestellt wird. Alternativ kann das Modell in einer virtuellen Umgebung mit einem Virtual-Reality-System betrachtet und interaktiv getestet werden. 

Auch hier verschiebt sich die Validierung. 
Nicht mehr die Beschreibung wird bewertet, sondern das erlebbare System. 

Zurück in den Projektraum 

Im dunklen Projektraum verschiebt sich der Fokus deutlich. Dokumentation wird gezielter eingesetzt und muss dort verlässlich sein, wo sie Grundlage für Entscheidungen oder automatisierte Verarbeitung ist. Validierung findet zunehmend direkt am System statt. 

Damit verändert sich die Arbeit im Requirements Engineering grundlegend.  

Weniger Formulierung, mehr Bewertung von Ergebnissen. 

Doch eine Frage bleibt: 

Was soll überhaupt gelten? 

Diese Entscheidung entsteht nach wie vor nicht aus Daten. Sie entsteht im Kontext, im Abwägen und im Dialog. Der dunkle Projektraum nimmt uns Arbeit ab, aber nicht die Verantwortung. 

Ausblick 

Im nächsten Beitrag richten wir den Blick auf das Anforderungsmanagement selbst. Wenn Anforderungen kontinuierlich erzeugt, verändert und weiterverarbeitet werden, stellt sich eine neue Frage: 
Wie behalten wir den Überblick? 

Wer entscheidet, welche Anforderung gilt? 
Wie werden Änderungen nachvollziehbar? 
Und wie steuern wir Systeme, in denen Anforderungen nicht mehr statisch sind? Diesen Fragen widmen wir uns im nächsten Teil.