KI im Requirements Engineering: Warum der Mensch trotz GenAI die wichtigste Instanz bleibt

KI schreibt Code heute in Sekunden – doch wer garantiert, dass dieser Code das richtige Problem löst? Der Einsatz von KI im Requirements Engineering (RE) ist ein zweischneidiges Schwert: Während generative Tools Lücken in Anforderungen mit plausibel erscheinenden, aber oft fachlich fatalen Annahmen füllen, steigt das Risiko für teure Fehlentwicklungen massiv. Geschwindigkeit ohne methodische Leitplanken ist in der Softwareentwicklung oft nur der schnellste Weg am Ziel vorbei. Um diesen Prozess beherrschbar zu machen, setzen wir am Fraunhofer IESE seit 25 Jahren auf das »Task-Oriented Requirements Engineering« (TORE). Dieses Rahmenwerk transformiert das Requirements Engineering von einer reinen Dokumentationsaufgabe in einen bewussten Entscheidungsprozess über Projekt-, Geschäfts-, Interaktions- und Systemebenen hinweg. So stellen wir sicher, dass technologische Effizienz und echte Mehrwerte keine Gegensätze bleiben.

Requirements Engineering ganz ohne KI?

Bis vor wenigen Jahren galt die Annahme, dass Entwicklerinnen oder Entwickler etwaige nicht in der Anforderungsdokumentation festgelegte Entscheidungen und fehlende Details während der Implementierung eigenständig schließen. Inzwischen ist jedoch durch den Einsatz generativer KI nicht mehr auszuschließen, dass gar kein Mensch mehr involviert ist, wenn Entscheidungen im Code manifestiert werden. Sämtliche Unklarheiten wird eine Code-generierende KI mit einer klar erscheinenden Antwort überspielen und eine lauffähige Software erzeugen.

Welche Entscheidungen sind zu treffen?

Das Ergebnis eines Software-Projekts ist ausführbarer Programmcode, der auf einem dafür passenden Gerät – einem Smartphone, einem Laptop, einem dedizierten Server oder in der Cloud – ausgeführt wird. Auf dem Weg dahin, werden zahlreiche Entscheidungen getroffen:

• Welche Ziele sollen mit der Software erreicht werden?
• Welche Stakeholder müssen berücksichtigt werden?
• Wie sind die Geschäftsprozesse gestaltet?
• Welche Daten verarbeitet das System?
• Welche technischen und grafischen Schnittstellen sind notwendig?
• Auf welchen Geräten oder Servern wird der Code ausgeführt?

Wo verbergen sich die Mehrwerte?

Bereits in der ersten Frage verbirgt sich die Suche nach Mehrwerten. Diese sind im Idealfall messbar und richten sich an den Bedürfnissen von Stakeholdern aus. Realisiert werden die Mehrwerte durch Entscheidungen, die entlang der obigen Leitfragen getroffen werden, und zwar von oben (dem Abstrakten) nach unten (dem Konkreten). Entlang dieser Kette werden Prozessschritte und Systemverantwortlichkeiten festgelegt, die Datenstrukturen und Schnittstellen definiert, und die technische Infrastruktur geschaffen. All dies geschieht, um am Ende den praktischen Nutzen einer Software zu realisieren, sobald sie auf dem entsprechenden Gerät läuft.

Die Leitfragen und deren Reihenfolge sind kein Zufall: Sie folgen einem Rahmenwerk, das wir am Fraunhofer IESE seit ca. 25 Jahren weiterentwickeln und in Software-Projekten einsetzen: »Task-Oriented Requirements Engineering«, kurz »TORE«.

Requirements Engineering als Entscheidungsprozess

Requirements Engineering bildet die erste Phase im traditionellen Software-Engineering und besitzt dieselbe hohe Wichtigkeit in agilen Projekten: Kontinuierlich arbeitet ein Team darauf hin, erhobene Anforderungen in Form von Inkrementen der Gesamtlösung zu realisieren. Während die Prozessschritte und Vorgehensweisen in wasserfallartigen und agilen Projekten sehr unterschiedlich sein können, sind zu treffenden Entscheidungen stets dieselben: Ein Requirements-Engineering-Prozess ist ein Entscheidungsprozess, in dem für ein System dessen Nutzungskontext, Scope, Funktionalität und Qualität festgelegt werden. Die verantwortlichen Akteure haben dabei meist die Aufgabe, aus verschiedenen Optionen eine Entscheidung zu treffen.

Das TORE-Rahmenwerk ordnet die Entscheidungen in vier Abstraktionsebenen ein, wie sie in Abbildung 1 dargestellt sind, einschließlich aller Entscheidungspunkte.

1. Projektebene

Auf der ersten Ebene wird das übergeordnete Thema des Projekts formuliert. Es stellt sicher, dass ein gemeinsames Verständnis zum Inhalt des Projekts unter allen Beteiligten besteht. Anschließend werden die Stakeholder identifiziert, also Personen oder Organisationseinheiten, die ein Interesse am Projekt haben oder von den Arbeiten bzw. dem Ergebnis des Projekts betroffen sind. Die Projektziele legen fest, welcher Nutzen durch das Projekt für welche Stakeholder erreicht werden muss. Als letzten Punkt auf der Projektebene werden die Geschäftsprozesse identifiziert, die im Rahmen des Projekts behandelt werden.

2. Geschäftsebene

Die folgende Ebene befasst sich mit den geschäftlichen Prozessen. Begonnen wird mit der Erhebung des gegenwärtigen Ist-Stands. Dies zielt darauf ab, zu verstehen, wie Prozesse aktuell durchgeführt werden sowie welche Stärken und Schwächen sie aufweisen. Darauf aufbauend wird die Soll-Situation erarbeitet. Diese beschreibt, wie die Prozesse künftig ablaufen sollen, um zuvor im Ist-Stand identifizierte Schwächen zu adressieren. Dabei wird festgelegt, welche Rolle welche Prozessschritte übernimmt, und hierbei werden bestimmte Daten produziert oder konsumiert. Auf Basis dieser Soll-Prozesse wird abgeleitet, welche Teile oder Schritte durch Systeme unterstützt oder gar vollständig automatisiert werden. Des Weiteren sind für ein Verständnis der Geschäftsebene die Geschäftsdaten und zugehörige Regeln für die Handhabung von Daten oder die Durchführung von Prozessen von Interesse.

3. Interaktionsebene

Die Interaktionsebene verfeinert hauptsächlich die zuvor identifizierten Teile des Soll-Prozesses, deren Durchführung durch IT-Systeme unterstützt wird. Zunächst werden für diese Teile die Interaktionen zwischen Nutzern oder externen Systemen mit dem zu entwickelnden System erarbeitet. Innerhalb einer solchen Interaktion werden üblicherweise Teilaufgaben vom System übernommen, z.B. Berechnungen oder Datenausgaben. Diese konkreten Funktionalitäten werden als Systemfunktionen identifiziert und detailliert dokumentiert. Sie bilden einen Kern der Anforderungen an das zu entwickelnde System ab. Zusätzlich ergeben sich durch die Interaktionen mit dem System weitere Daten und Regeln, die die bereits auf der vorherigen Ebene erfassten Geschäftsdaten detaillieren. Die Interaktionen laufen im Regelfall mithilfe einer Nutzerschnittstelle ab, die auf der Interaktionsebene konzeptionell erfasst wird.

4. Systemebene

Die abschließende Systemebene erläutern wir an dieser Stelle nicht näher. Sie dient als Übergabepunkt für weitergehende, sich an die Anforderungsanalyse anschließende Entwicklungsphasen, in denen Anforderungsingenieure involviert sein können. Dies schließt die Gestaltung grafischer Nutzerschnittstellen und die Definition einer Systemarchitektur ein.

Wer trifft die Entscheidungen – und wann?

Das TORE-Rahmenwerk macht Entscheidungen explizit und unterstützt dabei, eine bewusste Entscheidungsfindung herbeizuführen. Das Ziel ist es, frühzeitig in der Konzeption einer Software einen Konsens im Projektteam zu erreichen, anstatt Entscheidungen implizit und (zu) spät im Projekt durch Programmiertätigkeiten treffen zu lassen. In der Praxis geschieht zu oft genau das: Spätestens eine Entwicklerin oder ein Entwickler legt fest, welche Datenfelder in einer Maske abgefragt werden. Doch womöglich geschieht dies ohne Kenntnis über Nutzergruppen und Nutzungsszenarien, und folglich mit falschen Annahmen. Diese führen zu teuren, aber vermeidbaren Korrekturen.

Die Ebenen in TORE geben eine Orientierung, welche Entscheidungen früher getroffen werden müssen, weil sie spätere Entscheidungen beeinflussen. Hierbei gibt TORE keinen starren Prozess vor. Vielmehr unterstützt es Anforderungsingenieurinnen und -ingenieure dabei, eine Vollständigkeit aller relevanten Themen im Requirements Engineering zu erzielen: von abstrakten Zielen bis hin zu Systemfunktionen, die konkrete Anforderungen widerspiegeln.

Wie unterstützende KI im Requirements Engineering einsetzen?

Wir sind überzeugt, dass weitreichende Entscheidungen über die durch die Software erzielten Mehrwerte und damit deren Erfolgsaussichten nicht leichtfertig abgegeben werden dürfen. Diese Aussage bedeutet jedoch nicht, dass nicht auch sinnvolle Einsatzmöglichkeiten für KI im Requirements Engineering bestehen. Die gibt es und wir geben zwei Beispiele:

Generierung von Inhaltsvorschlägen

Mit ausreichend Kontextinformationen versehen, kann eine KI bei der Erstellung von Inhalten durch die Generierung von Vorschlägen die Effizienz der Erstellung von Anforderungsdokumenten verbessern. So können (Proto-)Personas aus Stakeholder-Beschreibungen erstellt werden, Prozessdiagramme anhand von Interview-Transkripten oder Datenmodelle aus Prozessbeschreibungen. Hierbei gilt besonders, dass ein Mensch die Inhalte prüft und letztlich die Entscheidungen fällt, welche Stakeholder, Prozessschritte oder Daten in der Software unterstützt werden.

Qualitätssicherung von Anforderungen

Das Sprachverständnis großer Sprachmodelle ausnutzend, kann eine KI prüfen, ob zu allen Entscheidungspunkten bereits relevante Informationen dokumentiert sind. Eine automatisierte Prüfung der Vollständigkeit erlaubt eine Verfolgung des Fortschritts im Requirements Engineering eines Projekts.

Genau hier setzt unsere Lösung »Quasar« an: Das Sprachverständnis großer Sprachmodelle (LLMs) ermöglicht heute neue Wege für KI im Requirements Engineering. Durch den Einsatz von LLMs und etablierten Heuristiken ermöglicht Quasar Feedback aus virtuellen User-Tests bereits während der Anforderungsphase. Anstatt auf manuelle Tests zu warten, erhalten Designer und Engineers direkt in Tools wie Figma Rückmeldung zu ihren Entscheidungen. Auch innerhalb der Entscheidungspunkte können automatisiert Prüfungen vorgenommen werden. Diese reichen von der Prüfung der Korrektheit von Prozessmodellen hinsichtlich Notationen und Konventionen im Unternehmen bis hin zur Prüfung inhaltlicher Konsistenz von Persona-Beschreibungen und Zielmodellen.

Effizienzsteigerung durch Requirements Engineering

Gute Anforderungen sind nicht nur eine Zugabe, sondern entscheidend für den Erfolg von Software. Exzellentes Requirements Engineering schafft die Grundlagen für die Realisierung von softwarebasierten Produkten, die tatsächliche Mehrwerte stiften und somit eine Chance auf nachhaltige Akzeptanz im Markt erhalten. Dafür gibt es methodische Hilfsmittel, wie das vorgestellte TORE. Um bestmögliches RE effizient zu gestalten, darf und soll selbstverständlich auch KI eingesetzt werden. Bestmöglich bedeutet hierbei nicht, grenzenlos Ressourcen in die Dokumentation von Anforderungen zu investieren, sondern stets genau so viel, wie notwendig ist. In Zukunft bedeutet bestmöglich auch, dass die Voraussetzungen dafür geschaffen sind, mit ausreichend Kontextinformationen Ansätze wie Generative AI (»GenAI«) gewinnbringend einsetzen zu können.

Schnelligkeit zu jedem Preis?

GenAI, insbesondere KI-basierte Programmierung, hat bereits Einzug in Unternehmen gehalten. Wir erwarten, dass die Nutzung von KI für diese Tätigkeit weiter zunehmen wird. Die Nutzung erlaubt immer kürzere Iterationszyklen in Softwareentwicklungsprozessen. Sie bewirkt zudem, dass Anforderungen immer schneller, womöglich sogar ungefiltert, in eine lauffähige Software überführt werden. Hierin liegen immense Chancen, und ebenso große Risiken. Schnell zu sein, ist erfolgsentscheidend, doch das Richtige auf den Markt zu bringen, ist mindestens genauso bedeutsam.

Wann und wie hilft KI im Requirements Engineering?

Um als Unternehmen also die Chancen der Effizienzsteigerung durch KI in der Entwicklung nutzen zu können, müssen die Voraussetzungen dafür in den Anforderungen geschaffen werden. Das bedeutet keinen Rückschritt in Zeiten, in denen die umfassende Spezifikation das Ziel war. Stattdessen kann und soll unter Verwendung agiler Entwicklungsansätze, gepaart mit LLM-basierten KI-Ansätzen und »Agentic AI« in kurzen Iterationen das Feedback von Stakeholdern eingeholt werden – idealerweise zu bewusst getroffenen Entscheidungen, die effizient in einen Prototyp und lauffähige Software überführt wurden.

Wie verhindern wir KI-Halluzinationen?

Am Fraunhofer IESE forschen wir an Werkzeugen und Methoden, sodass der Einsatz von KI als Hilfsmittel im Software Engineering zu qualitativ hochwertigen Ergebnissen führt. Ohne den richtigen Kontext, wie er beispielsweise durch ein Rahmenwerk wie TORE geschaffen wird, neigen KI-Modelle zu Halluzinationen. Wir sehen daher ein gutes Kontextmanagement als erfolgskritischen Faktor. Gleichzeitig sehen wir den Menschen als Entscheidungsinstanz an neuralgischen Punkten als weiterhin unverzichtbar und sehen in unserer Gestaltung von KI-unterstützten Prozessen den »Human-in-the-Loop« explizit vor.