Wie entstehen Anforderungen, wenn KI mitarbeitet? 

Im ersten Teil dieser Serie ging es um ein Gedankenexperiment: 
Ein Projektraum, der immer dunkler wird, weil KI mehr und mehr operative Tätigkeiten übernimmt. Die Arbeit verschwindet dabei nicht. Sie verlagert sich. 

Im zweiten Teil haben wir uns angeschaut, dass KI nie im luftleeren Raum arbeitet. Sie sieht nur das, was wir ihr zur Verfügung stellen. Kontext ist also nichts Technisches, sondern eine bewusste Entscheidung.  Und genau an dieser Stelle bleibt eine Frage offen: 

Wie entstehen daraus eigentlich Anforderungen? 

KI sieht viel – aber nicht alles 

Bleiben wir im Bild des dunklen Projektraums. 

Die KI arbeitet nicht „einfach so“. Sie bekommt Informationen: Dokumente, Beschreibungen von Altsystemen, Protokolle aus Workshops, Feedback von Stakeholdern, vielleicht auch Nutzungsdaten aus bestehenden Systemen. All das wird bewusst bereitgestellt. 

Darauf aufbauend kann sie inzwischen ziemlich viel leisten. Sie analysiert Inhalte, findet Muster, stößt auf Widersprüche und formuliert daraus Vorschläge. Offene Punkte kann sie häufig identifizieren und als Rückfragen in bestehende Kommunikationsprozesse zurückspielen. 

Wenn man sich das anschaut, wirkt das erst einmal sehr aufgeräumt. Dinge, die früher mühsam zusammengesucht wurden, liegen strukturiert vor. Vieles geht schneller, manches auch F 

Und genau hier liegt der Haken. 

Denn das, was die KI liefert, ist vor allem eines: ein Bild dessen, was in den vorhandenen Informationen steckt. Ein Bild, das oft stimmig wirkt, aber eben nur innerhalb dieses Ausschnitts. 

Was darin fehlt, ist das, was nie explizit gesagt wurde. 

Oder anders gesagt: Zwischen dem, was sich aus Daten ableiten lässt, und dem, was eigentlich gemeint ist, liegt immer ein Interpretationsschritt. 

Ein Beispiel aus der Praxis 

In einem Entwicklungsvorhaben fällt der Satz: 

„Das System soll international einsetzbar sein.“ 

Das klingt zunächst klar. Und natürlich kann eine KI damit arbeiten. Sie wird Mehrsprachigkeit berücksichtigen, regulatorische Anforderungen einbeziehen, vielleicht auch Unterschiede zwischen Märkten identifizieren.  

Alles sinnvoll.  

Alles nachvollziehbar.  

Und genau hier zeigt sich die Grenze: 
Was heißt „international“ in diesem konkreten Fall? Geht es wirklich um einen globalen Rollout? Oder nur um zwei, drei ausgewählte Märkte? Steht die rechtliche Absicherung im Vordergrund oder die Benutzerfreundlichkeit? 

Die Formulierung ist eindeutig genug, um damit zu arbeiten. Aber sie ist nicht eindeutig genug, um daraus automatisch die „richtige“ Anforderung abzuleiten. 

Was entsteht, ist kein fertiger Anforderungssatz, sondern ein Möglichkeitsraum. 
Dieser entsteht oft, weil sowohl die Formulierung offen ist als auch der zugrunde liegende Kontext nicht eindeutig festgelegt wurde. Erst wenn klar ist, welche Rahmenbedingungen gelten und wie die Aussage zu interpretieren ist, lässt sich dieser Raum sinnvoll eingrenzen. 

Wo Anforderungen wirklich entstehen 

Es reicht nicht, mögliche Interpretationen zu haben. Man muss sich festlegen. Gemeinsam mit den Stakeholdern wird entschieden, was gelten soll, welche Annahmen explizit gemacht werden und was bewusst ausgeschlossen wird. 

In der Praxis passiert das selten konfliktfrei. Unterschiedliche Bereiche verfolgen unterschiedliche Ziele. Der Fachbereich denkt anders als der Betrieb, die IT anders als das Management, und der Markt bringt noch einmal eigene Anforderungen mit. 

Deshalb entstehen Anforderungen nicht einfach durch Analyse. Sie entstehen in Gesprächen, in Abstimmungen und manchmal auch in durchaus zähen Diskussionen. 

Diese Entscheidungen sind dabei nicht automatisch „richtig“. Auch Menschen interpretieren falsch oder übersehen Dinge. 
Und nicht jede Entscheidung wird bewusst getroffen. Vieles entsteht aus Gewohnheit, Zeitdruck oder impliziten Annahmen. 
Der Unterschied ist: Diese Entscheidungen könnten bewusst gemacht werden und damit auch hinterfragt und korrigiert werden. 

Wenn Widersprüche zu Konflikten werden 

Eine Stärke von KI ist es, Widersprüche sichtbar zu machen. Das funktioniert oft erstaunlich gut, gerade wenn viele Quellen zusammenkommen. 

Was sie jedoch nicht leistet, ist die verbindliche Auflösung dieser Widersprüche im Projektkontext. 
Sie kann Vorschläge generieren oder Kompromisse aufzeigen, aber welche Lösung tatsächlich verfolgt wird, ergibt sich nicht aus den Daten allein.  

Ein typischer Zielkonflikt aus der Praxis: 
Ein Stakeholder fordert maximale Sicherheit. Ein anderer möchte eine möglichst einfache und schnelle Bedienung. 

Die KI erkennt diesen Zielkonflikt ohne Probleme. Sie kann sogar Vorschläge machen, wie man damit umgehen könnte. Zum Beispiel durch unterschiedliche Sicherheitsstufen oder alternative Bedienkonzepte. 

Sie kann auf Basis vorhandener Daten durchaus plausible Optionen priorisieren oder Empfehlungen aussprechen. 
Aber sie entscheidet nicht im Sinne einer verantworteten Projektentscheidung, also unter Berücksichtigung von Zielen, Risiken und Konsequenzen über den Daten hinaus. Solche Widersprüche sind oft der Ausgangspunkt für echte Zielkonflikte im Projekt. 
Und genau hier zeigt sich die Grenze: Aus einem erkannten Widerspruch wird nicht automatisch eine tragfähige Entscheidung. 

Was KI tatsächlich liefert 

Wenn man es nüchtern betrachtet, liefert KI vor allem eines: gut aufbereitete Vorschläge. Informationen werden schneller zugänglich, Zusammenhänge sichtbarer, Widersprüche offensichtlicher. Gerade bei großen Datenmengen ist das ein echter Gewinn. 

Trotzdem bleibt eine klare Grenze. 

Die KI trifft keine Entscheidungen im Sinne von: 
„Wir legen uns auf diese Variante fest und tragen die Konsequenzen.“ 
Sie kann Optionen bewerten, aber nicht die Verantwortung für eine Auswahl übernehmen, insbesondere dort, wo Unsicherheit besteht und keine eindeutigen Daten vorliegen. Das passiert weiterhin im Austausch zwischen Menschen. Dort, wo Ziele gegeneinander abgewogen werden und Unsicherheiten dazugehören. 

Verschiebung der Arbeit 

Mit dem Einsatz von KI verschiebt sich die Arbeit im Requirements Engineering spürbar. Der eigentliche Ort der Anforderungsermittlung liegt nicht mehr primär im Sammeln und Strukturieren von Informationen, sondern im Austausch mit Stakeholdern: im Klären von Bedeutungen, im Auflösen von Zielkonflikten und im bewussten Treffen von Entscheidungen. 

Genau hier liegt die Stärke des Menschen. Er stellt die unbequemen Rückfragen, erkennt Unsicherheiten und sorgt dafür, dass aus vagen Aussagen belastbare Anforderungen werden. Eine KI kann Vorschläge liefern und sogar kritische Punkte aufzeigen. Ob diese im konkreten Entwicklungskontext sinnvoll, gewollt oder tragfähig sind, kann sie jedoch nicht eigenständig entscheiden. 

Diese Tätigkeiten lassen sich nicht automatisieren, weil sie Verantwortung beinhalten. Und Verantwortung lässt sich nicht delegieren. Der Requirements Engineer übernimmt dabei weiterhin eine zentrale Rolle: Er macht Annahmen sichtbar, moderiert Zielkonflikte und sorgt dafür, dass Entscheidungen bewusst und nachvollziehbar getroffen werden. 

Ein guter Requirements Engineer nutzt die Vorschläge der KI, übernimmt sie aber nicht ungeprüft. Denn am Ende geht es nicht darum, was plausibel klingt, sondern darum, was für die Produktentwicklung gelten soll. 

Drei Fragen zum Schluss 

Wo verlassen Sie sich heute auf Vorschläge und wo treffen Sie aktiv Entscheidungen? 
Wo klären Sie Bedeutungen und wo bleiben sie implizit? 
Und wo entstehen Entscheidungen, ohne dass sie als solche sichtbar werden? 

Vielleicht liegt genau hier die eigentliche Veränderung: 

Nicht das Ermitteln von Anforderungen wird grundlegend anders. 
Sondern der Umgang mit den Entscheidungen, die daraus entstehen. 

→ Gespräch vereinbaren 

Wenn Sie tiefer einsteigen möchten, finden Sie im Buch „KI im Requirements Engineering – Werkzeuge und Techniken für den Einsatz in der Praxis“ eine systematische Einordnung entlang der klassischen RE-Tätigkeiten. 

→ Zum Buch 

Und wenn Sie KI im Requirements Engineering nicht nur diskutieren, sondern konkret erproben möchten: In unseren Trainings arbeiten wir praxisnah an genau diesen Fragestellungen. 
→ Zu den Trainings 

Im nächsten Beitrag dieser Serie betrachten wir, wie Anforderungen dokumentiert und geprüft werden können, wenn sie zunehmend automatisch erzeugt werden und was das für die Nachvollziehbarkeit und Qualität von Spezifikationen bedeutet.