Das Potenzial von generativer KI in der Anforderungsmodellierung - Teil 5

Das Potenzial von generativer KI in der Anforderungsmodellierung – Teil 5

Die Anforderungsmodellierung ist eine zentrale Disziplin des Anforderungsmanagements. Sie befasst sich mit der systematischen Erfassung, Strukturierung und Visualisierung von Anforderungen an ein Softwaresystem. Während die Anforderungserhebung vor allem auf das Sammeln und Dokumentieren von Informationen abzielt, konzentriert sich die Anforderungsmodellierung darauf, diese Informationen in formale oder semi-formale Modelle zu überführen. Ziel ist es, die Komplexität zu reduzieren, ein gemeinsames Verständnis zwischen Stakeholdern und Entwicklungsteams zu schaffen und eine Grundlage für weitere Entwicklungsphasen zu bieten.

Wichtig für eine erfolgreiche Anforderungsmodellierung sind insbesondere die Einhaltung etablierter Notationen (z. B. UML2), die Präzision der Darstellung sowie die Konsistenz und Vollständigkeit der Modelle. Nur so können die Modelle als belastbare Grundlage für Architektur- und Implementierungsentscheidungen genutzt sowie als Spezifikation für Umsetzung werden. Weniger formale Modelle dienen hingegen eher dem Zusammenfassen von Informationen in einer so geeigneten Weise, dass sich Anforderungsspezialisten, Stakeholder und Entwickler korrekt verständigen können.

Vor dem Hintergrund der wachsenden Bedeutung von Generativer Künstlicher Intelligenz (GenAI) stellt sich die Frage, inwiefern diese Technologien die Anforderungsmodellierung unterstützen können. Ziel dieses Beitrags ist es daher, das Potenzial von GenAI in diesem Kontext anhand eines konkreten Beispiels kritisch zu untersuchen.

Ausgangslage

Als Beispiel dient ein fiktives Warenwirtschaftssystem, das aus drei wesentlichen Bereichen besteht: einem Kassensystem für den Verkauf von Waren, einem Filialensystem zur Verwaltung, Bestellung und Überwachung von Produkten sowie einem Unternehmenssystem, das Berichte aus den Filialdaten erstellt. Grundlage der Untersuchung sind manuell erstellte, fiktive Dokumente wie Projektvorschläge, Beobachtungsprotokolle, Schnittstellenspezifikationen, unvollständige Use-Case-Diagramme und Mockups. Diese Dokumente liegen in unterschiedlichen Formaten vor (z. B. DOCX, PNG, YAML, PDF) und werden einem generativen KI-Modell (ChatGPT-4o) übergeben. Ziel ist es, zu evaluieren, ob und in welcher Qualität die KI aus diesen Eingaben verschiedene Modelltypen erstellen kann.

Vorgehen

Die Bewertung der Ergebnisse erfolgt anhand ausgewählter Kriterien. Zunächst werden unterschiedliche Diagrammtypen durch die KI erzeugt, darunter Komponentendiagramme, Klassendiagramme, Use-Case-Diagramme, Anforderungsdiagramme und Aktivitätsdiagramme. Alle Modelle werden durch die KI als Mermaid-Code generiert und anschließend visualisiert. Es handelt sich hierbei um sehr einfach lesbaren und interpretierbaren Code mit der Möglichkeit, diesen auszutauschen sowie zu visualisieren. Ebenfalls wird die KI auch aufgefordert, ein UML Modell als XMI auszugeben, da dieses einen hohen Spezifikationsgrad hat und sich damit als Grundlage der Softwareentwicklung versteht.

Die Analyse beider erzeugten Modelle erfolgt auf Basis folgender Kriterien:

Klarheit der Darstellung
Korrektheit der Inhalte
Prüfung der XMI auf Konformität zu UML2

Nach einer ersten Begutachtung werden die größten Schwachstellen identifiziert und die KI gebeten, Korrekturen vorzunehmen. Damit soll überprüft werden, inwiefern die KI auf Feedback reagiert und ihre Ergebnisse verbessern kann.

Ergebnisse

Die Modelle bzw. Diagramme, die mit Mermaid-Code erstellt worden sind, sind zur UML2 nicht konform, da zum einen nicht alle Diagrammtypen unterstützt werden und zum anderen Mermaid nicht für den Zweck einer Spezifikation geschaffen ist. Im Folgenden werden die Ergebnisse der einzelnen Diagrammtypen vorgestellt und verdeutlichen die Stärken und Schwächen von GenAI in der Anforderungsmodellierung.

Komponentendiagramm

Das von der KI erzeugte Komponentendiagramm als XMI entspricht dem UML2-Standard, ist aber sehr reduziert in der Darstellung der Abhängigkeiten. Das nicht UML2-konforme in Mermaid generierte Diagramm erlaubt jedoch einen Einblick in Abhängigkeiten der Module. Mehrere neue Module werden hinzugefügt, deren Existenz nicht in den Quelldokumenten belegt ist. Nachstehende Tabelle vergleicht Module in den Anforderungen und Module, welche sich im Diagramm wiederfinden:

In den Anforderungen identifizierte Module	Im Diagramm vorhandene Module
Kassensystem	Kassensystem
Lager & Warenwirtschaft	LagerWirtschaft
Reporting & Controlling	Reporting & Controlling
Systemintegration	Systemintegration & Kommunikation
Sicherheit & Benutzerverwaltung	Sicherheit & Benutzerverwaltung
Business Analytics	Analytics & Marketing
Qualitätsmanagement	Qualitätsmanagement
Benutzeroberfläche	Benutzeroberfläche
Systemarchitektur	Infrastruktur
Stammdatenverwaltung	Infrastruktur
–	Einkauf & Lagerorganisation
–	Zentrale Systeme

Im Vergleich der identifizierten Module und der modellierten beziehen sich Lagerwirtschaft und Einkauf & Lagerorganisation vermutlich auf das identifizierte Modul Lager & Warenwirtschaft, ist aber nicht klar ersichtlich. Im Diagramm vereint die neue Modulbezeichnung Infrastruktur die zuvor in den Anforderungen identifizierten Module Systemarchitektur und Stammdatenverwaltung. Alle drei Bezeichnungen sind nicht aussagekräftig und verschleiern, welche Geschäftsbereiche sie abdecken. Bei Stammdaten ist auch nicht klar, ob die Daten der Mitarbeiter oder der Kunden gemeint sind. Da hierzu nichts in den Eingabedokumenten erwähnt ist, ist die Modellierung des Moduls Stammdatenverwaltung fraglich und muss geklärt werden. Auch nicht eindeutig übereinstimmend sind Business Analytics und Analytics & Marketing. Es ist anzunehmen, dass hier das gleiche Modul gemeint ist. Positiv ist hervorzuheben, dass viele Kernmodule korrekt identifiziert und miteinander in Beziehung gesetzt werden.

Use-Case-Diagramm

Sowohl für das UML2-konforme als auch das Mermaid-Modell gilt: Die Akteure werden zuverlässig erkannt, während die Use Cases dagegen unvollständig sind, denn 14 Anforderungen können keinem Anwendungsfall zugeordnet werden. Zu diesen nicht verknüpften Anforderungen zählen:

Anforderungsduplikate haben keine erneute Verknüpfung erhalten
Anforderungen, die ohne Erklärung keinem Anwendungsfall zugeordnet worden sind

Vererbungsbeziehungen oder Extensions werden nicht modelliert – vermutlich, weil sich dies aus den gefundenen Anforderungen und den Quelldokumenten nicht ergibt.

Die KI wird zu einer erneuten Ausführung gebeten, um fehlende Zuordnungen von Anforderungen zu Anwendungsfällen zu ergänzen, was sie auch umsetzt. Insgesamt entsteht ein brauchbarer, aber nicht vollständiger Überblick über das Systemverhalten.

Das UML-Modell erfüllt zwar den Standard, enthält aber gegenüber dem Mermaid-Modell keine Beziehungen zwischen Akteuren und Anwendungsfällen. Der generierte Mermaid-Code hingegen kann nicht visualisiert werden, da Use Cases nicht als Diagrammtyp unterstützt sind. Hier kann nur die Bedeutung des Mermaid-Codes bewertet werden.

Klassendiagramm

Die Klassendiagramme, sowohl im Mermaid-Code als auch in XMI, sind syntaktisch korrekt und geben einen detaillierten Einblick in das System, besonders im Bereich Lager und Bestand.

Ein großer Unterschied beider Modelle ist allerdings, dass das Modell der XMI nur 8 Klassen mit 3 Assoziationen erzeugt, während der Mermaid-Code aus den gleichen Eingabedaten ein Modell mit 23 Klassen und zahlreichen sinnvollen Attributen, Methoden und Assoziationen mit Rollenbeschreibungen erzeugt. Letzteres sind Details an Assoziationen, auf die im UML-Modell verzichtet wird.

Bei weiterer Betrachtung des Mermaid-Modells ist zu erkennen: Vererbungen, Sichtbarkeiten und Multiplizitäten werden eingesetzt. Allerdings sind semantische Details problematisch: Manche Beziehungen sollten besser als Aggregation oder Komposition modelliert werden, was die KI nicht leistet. Attribute und Methoden sind plausibel, teils jedoch spekulativ, sodass eine manuelle Prüfung und ein Hinterfragen dieser Angaben durch den Anforderungsspezialisten notwendig ist.

Aktivitätsdiagramm

Die erzeugten Aktivitätsdiagramme in UML und Mermaid zeigen die grundlegenden Abläufe. Besonders problematisch ist die fehlerhafte Modellierung von Entscheidungsknoten und Parallelisierungen. So haben Entscheidungen teilweise nur einen Alternativablauf und Parallelisierungen werden nicht korrekt synchronisiert. Manche Abläufe terminieren nicht im Ende der Aktivität. Insgesamt hat die KI zu viele Abläufe als relevant erachtet und versucht, in einem Ablauf zu modellieren. Grund hierfür ist der Prompt, welcher nach einem Diagramm mit relevanten Abläufen gefragt hat. Nach Feedback zu den Schwachpunkten und der Bitte um mehr Fokus auf einen bestimmten Ablauf kann die KI mit dem verbesserten Prompt das Diagramm verbessern, etwa durch die Einführung von Swimlanes und konsistentere Entscheidungsstrukturen. Dennoch bleibt die Darstellung in Teilen unsauber, z.B. wegen anhaltender fehlerhaft zusammengeführter Parallelisierungen oder unklare Aktivitätsbezeichnungen, wie „Alle Prozesse abgeschlossen“. Während nach dem Feedback an die KI das UML-Modell zwar konform zur Notation bleibt, zeigt es jedoch gegenüber des in Mermaid erstellten Modells keine Swimlanes und auch keine Guards an Kanten einer Entscheidung.

Anforderungsdiagramm

Die Anforderungsmodellierung der generativen KI in Mermaid hat jede Anforderung isoliert mit ID, Titel und Priorität modelliert und visualisiert, ohne Berücksichtigung von Beziehungen, Abhängigkeiten oder Testfällen. Diese Elemente fehlen oder können nicht aus den Eingabedokumenten abgeleitet werden. Obwohl das Diagramm korrekt ist, mangelt es ihm an Aussagekraft. Da kein Anforderungsdiagramm in UML2 existiert, wird keines generiert.

Fazit

Die Untersuchung zeigt, dass der Einsatz generativer KI in der Anforderungsmodellierung Chancen, aber auch klare Grenzen hat.

UML2-Konformität: Die erzeugten Modelle erfüllen die formalen Standards zwar, aber sind wesentlich reduziert, wenn nicht unvollständig. Für den Einsatz eines Modells als Spezifikation für die Implementierung ist daher noch viel Aufwand nötig.
Nützlichkeit: Trotz Schwächen sind die Modelle geeignet, Ideen zu generieren und Diskussionen anzustoßen. Sie liefern eine erste Orientierung, ersetzen jedoch keine manuelle Modellierung durch Fachleute. Gerade hier spielt die Modellierung mit Mermaid ihre Stärke aus, weil sie einfacher anpassbar und austauschbar ist.
Stärken: Insbesondere Detailaspekte wie Attribute, Methoden oder logische Zusammenhänge zwischen Entitäten werden von der KI plausibel modelliert.
Schwächen: Die ganzheitliche und konsistente Modellierung bleibt sowohl in UML2 als auch mit Mermaid problematisch. Fehlende Standards, unvollständige Abbildungen und fehlerhafte Strukturen schränken die Verwendbarkeit ein, sodass abgewogen werden muss, welches Ziel mit der Modellierung verfolgt wird: UML2 eignet sich besser für Spezifikationen, bleibt aber durch die generative KI schwach unterstützt, während eine vereinfachte Modellierung ohne einen Standard besser durch die KI gestützt scheint, sich aber eher für den Austausch unter Stakeholdern eignet.

Darüber hinaus lassen sich weitere Schlussfolgerungen ziehen:

GenAI als Ideengeber: Die größte Stärke liegt in der schnellen Generierung von Modellvarianten, die als Ausgangspunkt für Diskussionen und manuelle Nachbearbeitung dienen können.
Notwendigkeit menschlicher Validierung: Ohne die fachliche Bewertung durch Modellierer:innen sind die Ergebnisse nicht zuverlässig genug für die Spezifikation.
Potenzial für hybride Ansätze: In Kombination mit klassischen Methoden kann GenAI die Produktivität steigern, indem Routinearbeiten wie das Aufstellen erster Diagrammgerüste automatisiert werden.
Grenzen in der Semantik: KI erfasst zwar Strukturen, hat aber Schwierigkeiten Kontexte und implizite Zusammenhänge in der Modellierung auszudrücken.

Insgesamt zeigt sich, dass generative KI in der Anforderungsmodellierung aktuell eher als unterstützendes Werkzeug und Ideengeber einsetzbar ist, nicht jedoch als Ersatz für menschliche Expertise.