KI in der Impact-Analyse

Wie KI künftig helfen kann, die Folgen von Anforderungsänderungen nicht nur zu finden, sondern auch zu verstehen

Eine Anforderung wird geändert. Was nun? In einem gut strukturierten Requirements Engineering liefert die Traceability darauf bereits eine wichtige Antwort. Sie zeigt, welche anderen Anforderungen, Architekturmodelle, Risiken, Testfälle oder weiteren Projektartefakte mit der geänderten Anforderung verbunden sind. Damit wissen wir, wo eine Änderung wirken könnte.

Doch für eine fundierte Impact-Analyse reicht das noch nicht. Die eigentlich schwierige Frage lautet: Was bedeutet die Änderung inhaltlich für die verbundenen Elemente? Muss eine Kindanforderung tatsächlich angepasst werden? Passt die geänderte Anforderung noch zur Vateranforderung? Entsteht gegenüber einer benachbarten Anforderung plötzlich eine Überschneidung? Ist ein Testfall wirklich nicht mehr gültig? Oder besteht die Traceability-Beziehung weiterhin, ohne dass die Änderung für ihn relevant ist?

Die zentrale These lautet:

Klassische Traceability findet die potenziell betroffenen Elemente und KI kann helfen zu beurteilen, ob und wie sie inhaltlich betroffen sind.

Impact-Analyse beginnt mit Beziehungen

In unserem Wissen-Online-Beitrag „Was ist eine Impact-Analyse im Requirements Engineering?“ haben wir Impact-Analyse als systematisches Verfahren beschrieben, das die Folgen geplanter Anforderungsänderungen sichtbar macht.

Dabei geht es nicht nur darum, betroffene Elemente zu finden. Eine Impact-Analyse muss vier Fragen beantworten:

• Welche Elemente sind betroffen?
• Warum sind sie betroffen?
• Welche inhaltlichen oder strukturellen Konsequenzen entstehen?
• Welche Maßnahmen ergeben sich daraus?

Gerade die letzten drei Fragen zeigen die Grenze einer rein strukturellen Betrachtung. Ein Traceability-Link kann beispielsweise eindeutig dokumentieren: Anforderung A ist mit Anforderung B verbunden. Er beantwortet jedoch nicht automatisch: Welche Konsequenz hat die konkrete Änderung von A für B? Dafür muss die Bedeutung der Änderung verstanden und in den Kontext der verbundenen Anforderung eingeordnet werden, darin liegt eine besondere Stärke generativer KI.

Vom Beziehungswissen zum Bedeutungswissen

Large Language Models können sprachliche Inhalte miteinander vergleichen und Hinweise auf Bedeutungsunterschiede und semantische Zusammenhänge ableiten. Für eine Impact-Analyse entsteht daraus eine interessante Arbeitsteilung.

• Das Requirements-Management-System liefert das Beziehungswissen.
  Es kennt Hierarchien, Traceability-Links, Modelle, Testfälle, Risiken, Versionen und weitere Projektinformationen.
• Die KI ergänzt dieses Beziehungswissen um Bedeutungswissen.
  Sie untersucht, was sich in einer Anforderung geändert hat und welche inhaltlichen Konsequenzen sich daraus für die verbundenen Elemente ergeben könnten.

Kurz gesagt:

Traceability liefert den Suchraum. KI hilft, den Impact innerhalb dieses Suchraums zu interpretieren.

Wie das konkret aussehen kann, lässt sich besonders gut an den drei Prüfrichtungen der hierarchischen Impact-Analyse zeigen.

Drei konkrete Prüfaufgaben für KI

Für die Analyse von Anforderungshierarchien lässt sich der hierarchische Impact in drei Prüfperspektiven strukturieren.

• Parent Consideration: der Blick nach oben zur Vateranforderung.
• Child Coverage: der Blick nach unten zu den Kindanforderungen.
• Slot Fit: der Blick zur Seite auf gleichgeordnete Anforderungen.

Aus diesen methodischen Perspektiven lassen sich unmittelbar drei Aufgaben für einen KI-Assistenten ableiten. Wichtig ist dabei: Parent Consideration, Child Coverage und Slot Fit sind zunächst lokale Prüfungen der unmittelbar verbundenen Anforderungen.

Ergibt eine solche Prüfung einen begründeten Hinweis auf weiteren Änderungsbedarf, muss zunächst fachlich bewertet werden, ob die betroffene Anforderung tatsächlich angepasst werden soll. Wird sie geändert, wird sie selbst zum Ausgangspunkt einer neuen Impact-Analyse. Auf diese Weise kann sich eine Änderung schrittweise durch die Anforderungshierarchie fortpflanzen.

1. Parent Consideration: Passt die Änderung noch zum übergeordneten Ziel?

Eine Kindanforderung wird geändert. Dank Traceability ist bekannt, welche Vateranforderung ihr zugeordnet ist. Damit ist die Beziehung eindeutig. Aber unterstützt die veränderte Kindanforderung weiterhin das Ziel der Vateranforderung?

Hier kann ein KI-Assistent die alte und die neue Formulierung sowie die Vateranforderung gemeinsam analysieren. Er kann beispielsweise darauf hinweisen:

• Die neue Formulierung entfernt sich möglicherweise vom übergeordneten Ziel.
• Ein Teil der Vateranforderung wird nicht mehr berücksichtigt.
• Die geänderte Anforderung erweitert den bisherigen Scope.
• Zwischen Parent und Child ist möglicherweise ein Widerspruch entstanden.

Aus einem einfachen Link wird damit eine konkrete Prüfaufgabe.

• Traceability sagt: Diese beiden Anforderungen gehören zusammen.
• Die KI fragt zusätzlich: Passen sie nach der Änderung inhaltlich noch zusammen?

Der Requirements Engineer erhält nicht nur ein betroffenes Element, sondern einen begründeten Hinweis darauf, warum dieses Element überprüft werden sollte.

Die Prüfung muss dabei nicht an der unmittelbar übergeordneten Vateranforderung enden. Ergibt die Analyse einen begründeten Hinweis darauf, dass auch diese Vateranforderung betroffen sein könnte, wird zunächst geprüft, ob tatsächlich eine Anpassung erforderlich ist. Wird die Vateranforderung daraufhin geändert, ist erneut zu untersuchen, ob sie weiterhin zu ihrer eigenen Vateranforderung passt. Parent Consideration kann sich dadurch schrittweise über mehrere Ebenen der Anforderungshierarchie nach oben fortsetzen.

2. Child Coverage: Reichen die vorhandenen Kindanforderungen noch aus?

Betrachten wir die Gegenrichtung. Eine Vateranforderung lautet zunächst: „Das System muss Messdaten speichern.“ Daraus wurden Kindanforderungen zu Speicherdauer, Datenformat und Speicherkapazität abgeleitet. Nun wird die Vateranforderung geändert: „Das System muss Messdaten verschlüsselt speichern.“

Die bestehende Traceability sieht möglicherweise weiterhin tadellos aus. Alle Kindanforderungen sind vorhanden. Alle Beziehungen bestehen. Keine Anforderung ist verwaist. Und trotzdem ist ein Problem entstanden: Die neue Bedeutungskomponente „verschlüsselt“ wird durch keine der vorhandenen Kindanforderungen konkretisiert.

Strukturell ist das Modell vollständig. Semantisch besitzt es aber eine Lücke. Ein KI-Assistent kann deshalb prüfen:

• Welche Bedeutung ist durch die Änderung hinzugekommen?
• Welche vorhandenen Kindanforderungen decken diese Bedeutung bereits ab?
• Welche Aspekte sind bislang nicht berücksichtigt?
• Muss eine bestehende Kindanforderung ergänzt werden?
• Wird möglicherweise eine neue Kindanforderung benötigt?

Die Fragestellung verändert sich dadurch grundlegend. Nicht mehr nur: Welche Kindanforderungen existieren? Sondern: Decken sie das geänderte Requirement noch vollständig ab?

Auch Child Coverage kann sich über mehrere Hierarchieebenen fortsetzen. Ergibt die Prüfung einen begründeten Hinweis darauf, dass eine Kindanforderung die geänderte Vateranforderung nicht mehr vollständig abdeckt, muss zunächst entschieden werden, ob und wie sie angepasst werden soll.

Wird die Kindanforderung geändert, ist anschließend zu prüfen, ob deren eigene Kindanforderungen die neue Bedeutung weiterhin vollständig abdecken. So kann jede tatsächlich vorgenommene Folgeänderung eine weitere Child-Coverage-Prüfung auf der nächsten Ebene auslösen.

3. Slot Fit: Passt die Anforderung noch an ihre Stelle?

Eine Anforderung steht nicht nur in vertikalen Beziehungen zu Parent und Children. Sie besitzt auch einen Kontext innerhalb ihrer Hierarchieebene. Wird sie verändert oder eine neue Anforderung eingefügt, muss deshalb geprüft werden, wie sie sich gegenüber ihren Sibling Requirements verhält. Die strukturelle Seite ist einfach: Das Requirements-Management-System kann feststellen, welche Anforderungen denselben Parent besitzen. Die semantische Bewertung ist schwieriger.

Eine KI kann die relevanten Sibling Requirements gemeinsam analysieren und Hinweise darauf liefern, dass

• zwei Anforderungen nun denselben Sachverhalt beschreiben,
• sich ihre Geltungsbereiche überschneiden,
• Anforderungen einander widersprechen,
• zwischen mehreren Anforderungen eine funktionale oder semantische Lücke besteht.

Gerade hier zeigt sich der Unterschied zwischen Struktur und Bedeutung besonders deutlich. Slot Fit fragt nicht nur, welche Anforderungen befinden sich auf derselben Ebene befinden, sondern: Sind ihre Verantwortungsbereiche noch sinnvoll voneinander abgegrenzt?

KI-gestützte Impact-Analyse betrachtet unterschiedliche Change Events

Hinzufügen und Löschen sind KI-relevante Ereignisse

Impact-Analyse beginnt nicht ausschließlich dann, wenn ein Requirement umformuliert wird. Auch das Hinzufügen oder Entfernen einer Anforderung verändert das Anforderungsmodell. Wird eine neue Anforderung eingefügt, kann ein KI-Assistent beispielsweise Parent Consideration und Slot Fit auf Folgendes prüfen:

• Passt sie tatsächlich zum vorgesehenen Parent?
• Gibt es bereits eine Anforderung mit sehr ähnlicher Bedeutung?
• Entsteht ein Konflikt?

Wird eine Anforderung entfernt, ergeben sich andere Fragen:

• Ist die Vateranforderung weiterhin vollständig abgedeckt?
• Werden Kindanforderungen zu Orphaned Requirements?
• Entsteht zwischen den verbleibenden Siblings eine Lücke?

Damit könnte die KI-Unterstützung nicht nur auf einen einzelnen Bearbeitungsvorgang reagieren, sondern auf unterschiedliche Change Events im Anforderungsmodell.

Vom direkten zum indirekten Impact

Indirekter Impact kann bereits innerhalb der Anforderungshierarchie entstehen. Führt beispielsweise die Änderung einer Anforderung zu einer Anpassung ihrer Vater- oder Kindanforderung, kann diese Folgeänderung wiederum weitere Anforderungen auf der nächsten Hierarchieebene betreffen.

Aus einer einzelnen Änderung kann dadurch eine rekursive Wirkungskette entstehen:

Grandparent ← Parent ← geänderte Anforderung → Child → Grandchild

Die Analyse endet dabei nicht an einer festgelegten Hierarchiestufe. Sie wird so lange fortgesetzt, wie auf der nächsten Ebene ein fachlich relevanter weiterer Impact erkennbar ist.

Damit ergibt sich ein Gesamtmodell der Impact-Analyse, das drei Ebenen verbindet: die lokale semantische Prüfung, die rekursive Ausbreitung von Auswirkungen und den indirekten Impact über Artefaktgrenzen hinweg.

Noch anspruchsvoller wird die Analyse, wenn sich die Wirkung einer Änderung über die reine Anforderungshierarchie hinaus auf Architektur, Risiken, Tests oder weitere Projektartefakte fortsetzt.

Traceability kann solche Wirkungspfade grundsätzlich sichtbar machen. Mit zunehmender Länge und Vernetzung wächst jedoch die Zahl potenziell betroffener Elemente erheblich. Nicht jeder strukturell erreichbare Knoten im Traceability-Netz besitzt zwangsläufig einen fachlich relevanten Impact.

Dadurch entsteht eine weitere interessante Aufgabe für einen KI-Assistenten, die darin besteht, relevante Wirkungspfade semantisch zu bewerten und zu priorisieren. Er könnte dabei helfen, die entscheidende Frage zu beantworten: Welche der strukturell erreichbaren Elemente sind aufgrund der konkreten Bedeutungsänderung tatsächlich relevant?

Aus einer möglicherweise langen Liste potenziell betroffener Elemente könnte so eine priorisierte und begründete Prüfliste möglicher Impacts entstehen.

Von der Trefferliste zum begründeten Impact-Hinweis

Der Mehrwert einer KI-gestützten Impact-Analyse sollte deshalb aus meiner Sicht nicht darin bestehen, einfach noch mehr Treffer anzuzeigen. Interessanter wäre eine begründete Einschätzung. Ein KI-Assistent könnte zum Beispiel Hinweise dieser Art erzeugen:

• Parent Consideration – möglicher Konflikt

Hinweis:
Die geänderte Kindanforderung fordert nun eine Aufbewahrungsdauer von zehn Jahren. Die übergeordnete Anforderung begrenzt die Speicherung auf fünf Jahre.

Empfohlene Prüfung:
Konsistenz zwischen Parent und Child prüfen.

• Child Coverage – mögliche Abdeckungslücke

Hinweis:
Die Vateranforderung verlangt nach der Änderung zusätzlich die Verschlüsselung gespeicherter Daten. Unter den derzeit zugeordneten Kindanforderungen wurde keine Anforderung identifiziert, die diesen Aspekt konkretisiert.

Empfohlene Prüfung:
Bestehende Kindanforderungen ergänzen oder neue Anforderung ableiten.

• Slot Fit – mögliche Überschneidung

Hinweis:
Die geänderte Anforderung überschneidet sich inhaltlich mit einem vorhandenen Sibling Requirement hinsichtlich der Verschlüsselung persistierter Messdaten.

Empfohlene Prüfung:
Abgrenzung oder Zusammenführung der Anforderungen prüfen.

Damit würde aus „Dieses Element könnte betroffen sein.“ eine wesentlich nützlichere Aussage: „Dieses Element könnte aus diesem Grund und mit dieser möglichen Konsequenz betroffen sein.“

Wie eine KI-gestützte Impact-Analyse in objectiF RPM aussehen könnte

objectiF RPM verfügt bereits über KI-gestützte Funktionen. Eine KI-Unterstützung speziell für die Impact-Analyse gibt es derzeit noch nicht. Die Vision knüpft damit an zwei bereits vorhandene Stärken an. Zum einen an die strukturierte Traceability von objectiF RPM und zum anderen an die integrierten generativen KI-Assistenten.

Gerade deshalb lohnt es sich, darüber nachzudenken, wie ein solcher Assistent aussehen könnte. Die Ausgangslage ist günstig, denn Anforderungen werden in objectiF RPM nicht isoliert verwaltet. Hierarchien, Beziehungen und weitere Projektartefakte liefern bereits den strukturellen Kontext.

Darauf könnte ein zukünftiger Impact-Assistent aufsetzen. Ein möglicher Ablauf könnte dabei vom Change Event über bestehende hierarchische Auswertungen (in der folgenden Grafik vereinfacht als ‚Impact Map‘ bezeichnet) und eine semantische KI-Vorprüfung bis zu einem begründeten Hinweis für die menschliche Entscheidung führen.

Was ein guter Impact-Assistent leisten könnte

Nach einer Änderung könnte er beispielsweise:

• die über Traceability potenziell betroffenen Elemente ermitteln,
• Parent Consideration, Child Coverage und Slot Fit KI-gestützt vorprüfen,
• direkte und indirekte Wirkungspfade einschließlich rekursiver Folgeänderungen über mehrere Hierarchieebenen untersuchen,
• mögliche Konflikte, Abdeckungslücken oder Redundanzen kennzeichnen,
• die Relevanz gefundener Auswirkungen priorisieren,
• zu jedem Hinweis eine verständliche Begründung liefern,
• betroffene Architektur-, Risiko- und Testartefakte zur Prüfung vorschlagen,

• mögliche nächste Schritte empfehlen.

Das wäre mehr als eine grafische Darstellung von Abhängigkeiten. Aus einer Impact Map könnte eine interpretierte Impact Map werden. Für Requirements Engineers läge der Nutzen vor allem darin, weniger Zeit mit der manuellen Suche nach möglichen Seiteneffekten zu verbringen, kritische Auswirkungen früher zu erkennen und Änderungsentscheidungen auf nachvollziehbar begründete Prüfhypothesen zu stützen.

Was ein guter Impact-Assistent nicht tun sollte

Gerade weil Large Language Models Wahrscheinlichkeitsmodelle sind, sollte ein solcher Assistent seine Einschätzungen nicht als unumstößliche Wahrheit darstellen.

Ein Hinweis wie „Child Coverage verletzt“ wäre problematischer als: „Mögliche Abdeckungslücke: Der neu hinzugefügte Verschlüsselungsaspekt ist in den derzeit zugeordneten Kindanforderungen nicht erkennbar.“

Das zweite Ergebnis ist nachvollziehbarer, überprüfbar, fachlich diskutierbar und für den verantwortlichen Engineer wesentlich hilfreicher. Ein KI-Assistent sollte deshalb nicht zum automatischen Change Control Board werden. Die sinnvollere Rollenverteilung lautet:

KI analysiert, priorisiert und begründet. Der Mensch bewertet und entscheidet.

Gerade in regulierten und sicherheitskritischen Entwicklungsumgebungen bleibt die nachvollziehbare fachliche Entscheidung unverzichtbar.

Erklärbarkeit (Explainability) wird zum Feature

Daraus ergibt sich eine weitere Anforderung an zukünftige KI-Funktionen. Ein Impact-Assistent sollte nicht nur ein Ergebnis liefern, er sollte Folgendes zeigen:

• Was wurde geprüft?
  Welche Anforderungen und Artefakte wurden betrachtet?
• Welche Beziehung war relevant?
  Parent, Child, Sibling oder ein anderer Traceability-Pfad?
• Welche Textänderung löste den Hinweis aus?
• Warum wird ein Impact vermutet?
• Wie sicher beziehungsweise eindeutig ist die Einschätzung?
• Was sollte der Anwender als Nächstes prüfen?

Somit wird Nachvollziehbarkeit zu einem zentralen Bestandteil des Features.

KI macht gute Traceability wertvoller

Man könnte aus der Leistungsfähigkeit moderner Sprachmodelle den Schluss ziehen, dass sorgfältig gepflegte Traceability künftig weniger wichtig wird. Ein Modell könne schließlich selbst herausfinden, welche Inhalte miteinander zusammenhängen. Für eine belastbare Impact-Analyse wäre das jedoch der falsche Ansatz.

Je besser die Struktur der vorhandenen Informationen ist, desto gezielter kann eine KI arbeiten. Eine gemeinsame Datenbasis mit

• eindeutig identifizierbaren Anforderungen,
• gepflegten Hierarchien,
• definierten Beziehungen,
• Versionen und Baselines,
• Architekturinformationen,
• Risiken,
• Testinformationen

reduziert den Suchraum und liefert fachlichen Kontext. Die KI muss dann nicht versuchen, aus einem unstrukturierten Informationsbestand zunächst das gesamte Beziehungsmodell zu rekonstruieren. Sie kann sich auf die anspruchsvollere Aufgabe konzentrieren, die Bedeutung einer Änderung zu beurteilen. Kurz gesagt, die KI ersetzt die Single Source of Truth nicht, vielmehr erhöht sie ihren Wert.

Der nächste Schritt der Impact-Analyse

Klassische Impact-Analyse und KI-gestützte Impact-Analyse sind deshalb keine Gegensätze. Sie bauen aufeinander auf:

• Traceability findet Beziehungen.
• Impact-Analyse macht daraus Prüfaufgaben.
• KI kann helfen, diese Prüfaufgaben semantisch zu bewerten und zu priorisieren.

Parent Consideration, Child Coverage und Slot Fit liefern dafür ein einfaches, aber leistungsfähiges methodisches Raster. Und die Idee lässt sich weiterführen: von Anforderungen zu Architektur, von Architektur zu Risiken, von Risiken zu Tests und über mehrere Beziehungsschritte hinweg. Damit entsteht eine Perspektive, die weit über einen einzelnen KI-Button hinausgeht.

Aus einem Requirements-Management-System, das Beziehungswissen verwaltet, kann schrittweise ein Assistenzsystem werden, das dieses Beziehungswissen nutzt, um Änderungsfolgen verständlicher, früher und systematischer sichtbar zu machen.

Genau bei dieser Frage könnte KI Requirements Engineers künftig besonders wirkungsvoll unterstützen.