Was ist eine Impact-Analyse im Requirements Engineering?

Eine Impact-Analyse (Auswirkungsanalyse) im Requirements Engineering ist ein systematisches Verfahren zur Ermittlung und Bewertung der Auswirkungen einer geplanten Änderung an Anforderungen. Sie beantwortet die Frage, welche weiteren Anforderungen, Modelle, Testfälle, Risiken oder Projektartefakte von einer Änderung betroffen sind und welche Konsequenzen sich daraus ergeben.

Eine Impact-Analyse schafft damit die Grundlage für fundierte Änderungsentscheidungen. Sie reduziert das Risiko unerwarteter Seiteneffekte, verbessert die Aufwandsschätzung und unterstützt ein kontrolliertes Change Management.

Änderungen gehören zum Alltag jedes Entwicklungsprojekts. Neue Kundenanforderungen, geänderte Rahmenbedingungen, neue technische Erkenntnisse oder Änderungen an Normen und Vorschriften können dazu führen, dass bestehende Anforderungen angepasst, ergänzt oder entfernt werden müssen.

Selten betrifft eine solche Änderung jedoch nur die einzelne Anforderung. In einem modernen Systems Engineering sind Anforderungen über Hierarchien und Traceability-Beziehungen mit zahlreichen weiteren Anforderungen und Artefakten verbunden. Bereits eine kleine Änderung kann sich deshalb auf Systemarchitektur, Testfälle, Sicherheitsanalysen oder Projektplanung auswirken.

Die Aufgabe der Impact-Analyse besteht darin, diese Auswirkungen möglichst vollständig sichtbar zu machen, bevor eine Änderung umgesetzt wird.

Der Begriff Impact bezeichnet die Auswirkungen und Konsequenzen einer Änderung. Dabei geht es nicht nur darum festzustellen, dass andere Elemente betroffen sind. Entscheidend ist auch zu verstehen, warum und in welcher Weise sie betroffen sind.

Eine Impact-Analyse beantwortet daher vier zentrale Fragen:

1. Welche Elemente sind von der Änderung betroffen?
2. Warum sind sie betroffen?
3. Welche inhaltlichen oder strukturellen Konsequenzen entstehen?
4. Welche Maßnahmen ergeben sich daraus?

Dabei können unterschiedliche Arten von Auswirkungen auftreten:

Hierarchischer Impact

Anforderungen bilden häufig eine Hierarchie aus übergeordneten und untergeordneten Anforderungen. Ändert sich eine Anforderung, müssen deshalb ihre Beziehungen nach oben, nach unten und zu Anforderungen derselben Ebene überprüft werden.

Technischer Impact

Aus Anforderungen entstehen Architekturmodelle, Schnittstellen, Software- oder Hardwarekomponenten. Eine Änderung kann daher Anpassungen an UML- oder SysML-Modellen, Systemarchitektur, Schnittstellen oder Implementierung erforderlich machen.

Qualitäts- und Verifikations-Impact

Testfälle und Akzeptanzkriterien basieren auf Anforderungen. Ändert sich die zugrunde liegende Anforderung, muss geprüft werden, welche Tests angepasst oder erneut durchgeführt werden müssen und ob vorhandene Verifikationsnachweise weiterhin gültig sind.

Risiko- und Compliance-Impact

Insbesondere in regulierten oder sicherheitskritischen Projekten können Änderungen bestehende Risikoanalysen, Sicherheitsbewertungen oder Compliance-Nachweise beeinflussen.

Wirtschaftlicher und organisatorischer Impact

Änderungen können schließlich Auswirkungen auf Entwicklungsaufwand, Ressourcen, Verantwortlichkeiten, Termine und Kosten haben. Die Ergebnisse einer Impact-Analyse sind deshalb eine wichtige Grundlage für die Entscheidung, ob und wie eine geplante Änderung umgesetzt wird.

Besonders wichtig ist die Impact-Analyse innerhalb einer Anforderungshierarchie. Eine Systemanforderung kann beispielsweise durch mehrere Subsystemanforderungen konkretisiert werden, aus denen wiederum Komponentenanforderungen abgeleitet werden.

Eine Änderung muss deshalb nicht nur isoliert betrachtet werden. Es sind drei Richtungen des hierarchischen Impacts zu untersuchen, die ein einfaches Prüfraster für die Analyse hierarchischer Auswirkungen bilden:

Parent Consideration: Berücksichtigung der Vateranforderung

Mit Parent Consideration wird geprüft, ob eine Anforderung weiterhin mit ihrer übergeordneten Vateranforderung vereinbar ist und zu deren Erfüllung beiträgt.

Wird beispielsweise eine Kindanforderung verändert, kann sich ihre Bedeutung so weit verschieben, dass sie das ursprüngliche Ziel der Vateranforderung nur noch teilweise oder möglicherweise gar nicht mehr unterstützt.

Typische Prüffragen sind:

• Passt die geänderte Anforderung weiterhin zum Ziel der Vateranforderung?
• Konkretisiert sie weiterhin den vorgesehenen Teil des übergeordneten Requirements?
• Entsteht ein Widerspruch zur Vateranforderung?
• Wird durch die Änderung möglicherweise der ursprünglich definierte Scope verlassen?

Parent Consideration betrachtet den Impact damit von unten nach oben.

Child Coverage: Abdeckung durch Kindanforderungen

Child Coverage betrachtet die entgegengesetzte Richtung. Hier wird geprüft, ob eine übergeordnete Anforderung durch ihre Kindanforderungen weiterhin vollständig konkretisiert beziehungsweise abgedeckt wird.

Wird beispielsweise eine Vateranforderung erweitert, können die bisher vorhandenen Kindanforderungen zwar weiterhin korrekt sein, aber nicht mehr ausreichen, um die neue Bedeutung vollständig abzudecken.

Typische Prüffragen sind:

• Decken die vorhandenen Kindanforderungen die geänderte Vateranforderung noch vollständig ab?
• Müssen bestehende Kindanforderungen angepasst werden?
• Werden zusätzliche Kindanforderungen benötigt?
• Entsteht durch das Entfernen einer Kindanforderung eine Abdeckungslücke?

Child Coverage betrachtet den Impact somit von oben nach unten.

Slot Fit: Abgrenzung gegenüber Anforderungen derselben Ebene

Eine Anforderung muss nicht nur zu ihren Vater- und Kindanforderungen passen. Sie muss auch innerhalb der Gruppe gleichgeordneter Anforderungen eine sinnvolle und eindeutig abgegrenzte Position einnehmen.

Diese Perspektive lässt sich als Slot Fit beschreiben.

Wird eine Anforderung neu hinzugefügt oder inhaltlich verändert, ist deshalb zu prüfen, wie sie sich gegenüber ihren Geschwisteranforderungen (Sibling Requirements) verhält.

Typische Prüffragen sind:

• Überschneidet sich die Anforderung inhaltlich mit einer bestehenden Anforderung?
• Entsteht eine Redundanz?
• Widersprechen sich zwei Anforderungen?
• Bleibt zwischen Anforderungen eine funktionale oder semantische Lücke?
• Gehört die Anforderung überhaupt an diese Stelle der Hierarchie?

Slot Fit ergänzt damit die vertikale Betrachtung von Parent Consideration und Child Coverage um eine horizontale Perspektive.

Jeder strukturelle Eingriff in das Anforderungsmodell kann eine Kettenreaktion auslösen. Die drei Prüfrichtungen helfen dabei, die Konsequenzen systematisch zu bewerten:

Wenn eine bestehende Anforderung geändert wird

Die Änderung einer vorhandenen Anforderung ist der häufigste Fall im Projektalltag.

Wird eine bestehende Systemanforderung um einen zusätzlichen Aspekt erweitert, dann sind alle drei Perspektiven relevant:

Anschließend muss untersucht werden, welche nachgelagerten Artefakte – beispielsweise Architekturmodelle, Risiken und Testfälle – ebenfalls betroffen sind.

Wenn eine Anforderung wegfällt

Bei einer Kindanforderung stellt sich bezogen auf  Child Coverage die Frage, ob ihre Vateranforderung anschließend noch vollständig abgedeckt wird. Entsteht eine Lücke, muss diese entweder durch eine andere bestehende Anforderung geschlossen oder durch eine neue Anforderung abgedeckt werden.

Wird dagegen eine Vater- oder Zwischenanforderung entfernt, können darunterliegende Kindanforderungen ihren logischen Bezug verlieren. Es entstehen sogenannte verwaiste Anforderungen (Orphaned Requirements).

Dann muss entschieden werden, ob diese Anforderungen ebenfalls entfallen oder einer anderen Vateranforderung zugeordnet werden können.

Auch der  Slot Fit kann sich verändern: Durch den Wegfall einer Anforderung können sich die Verantwortungsbereiche der verbleibenden Geschwisteranforderungen verschieben oder neue Lücken entstehen.

Wenn eine neue Anforderung hinzukommt

Jede neue Anforderung muss in das bestehende Anforderungsmodell passen.

Parent Consideration prüft zunächst, ob sie tatsächlich zur vorgesehenen Vateranforderung gehört und deren Ziel unterstützt.

Über Child Coverage wird anschließend untersucht, ob die neue Anforderung weiter konkretisiert werden muss und dafür zusätzliche Kindanforderungen erforderlich sind.

Slot Fit prüft schließlich ihre Position gegenüber bereits vorhandenen Geschwisteranforderungen. Dabei können Redundanzen, Überschneidungen oder Widersprüche sichtbar werden.

Das bloße Einfügen einer neuen Anforderung in eine Hierarchie reicht daher nicht aus. Entscheidend ist, dass sie semantisch und strukturell in das bestehende Anforderungsmodell passt.

Eine weitere wichtige Unterscheidung besteht zwischen direktem und indirektem Impact.

• Ein direkter Impact betrifft Elemente, die unmittelbar mit der geänderten Anforderung verbunden sind. Das können beispielsweise die direkte Vateranforderung, Kindanforderungen oder ein zugeordneter Testfall sein.
• Ein indirekter Impact entsteht dagegen über mehrere Beziehungsschritte hinweg.

Ändert sich beispielsweise eine Systemanforderung, kann dies zunächst eine Subsystemanforderung betreffen. Deren Änderung beeinflusst wiederum eine Schnittstelle, die Auswirkungen auf eine andere Komponente und deren Testfälle hat.

Je länger solche Wirkungsketten werden, desto schwieriger ist es, alle Auswirkungen einer Änderung vollständig zu erkennen.

Traceability verbindet Anforderungen beispielsweise mit:

• Vater- und Kindanforderungen,
• anderen abhängigen Anforderungen,
• Architekturmodellen,
• Risiken,
• Testfällen,
• Implementierungsartefakten.

Traceability beantwortet damit zunächst die Frage:

Welche Elemente stehen mit der geänderten Anforderung in Beziehung und könnten deshalb betroffen sein?

Sie liefert damit das strukturelle Fundament der Impact-Analyse.

Die bloße Existenz einer Beziehung beantwortet allerdings noch nicht automatisch die Frage, welche inhaltlichen Konsequenzen eine Änderung für das verbundene Element hat. Dafür muss die Bedeutung der Änderung im jeweiligen Kontext bewertet werden.

In kleinen Anforderungsmodellen kann ein Requirements Engineer viele Auswirkungen noch manuell überblicken. Mit zunehmender Projektgröße wächst jedoch nicht nur die Anzahl der Anforderungen, sondern vor allem die Zahl ihrer Beziehungen.

Bei mehreren tausend Anforderungen entsteht ein komplexes Netz aus Hierarchien und Abhängigkeiten.

Eine Änderung kann dann:

• zahlreiche direkte Beziehungen betreffen,
• sich über mehrere Hierarchieebenen fortpflanzen,
• indirekte Auswirkungen auf weit entfernte Artefakte besitzen,
• semantische Widersprüche oder Abdeckungslücken verursachen, die aus der Beziehung allein nicht erkennbar sind.

Die Herausforderung besteht daher nicht nur darin, betroffene Elemente zu finden, sondern auch darin, die Bedeutung einer Änderung für diese Elemente zu beurteilen.

objectiF RPM verwaltet Anforderungen gemeinsam mit ihren Beziehungen in einem zentralen Repository. Anforderungen können hierarchisch strukturiert und mit weiteren Projektartefakten verknüpft werden. So wird sichtbar, welche Elemente von einer geplanten Änderung betroffen sein können.

In objectiF RPM bilden Traceability, Anforderungshierarchien und verknüpfte Projektartefakte eine strukturierte Datenbasis für Impact-Analysen. Dadurch lassen sich Beziehungen systematisch untersuchen – und perspektivisch auch durch automatisierte oder KI-gestützte Analyseverfahren auswerten.

Mit objectiF RPM lassen sich diese Perspektiven nachvollziehbar abbilden: Parent Consideration unterstützt den Blick nach oben, Child Coverage die Prüfung der Abdeckung nach unten und Slot Fit die Abgrenzung gegenüber Anforderungen derselben Ebene.

objectiF RPM schafft eine gemeinsame Arbeitsgrundlage für Requirements- und Change-Management. Änderungen können auf Basis verknüpfter Anforderungen, Artefakte und Abhängigkeiten systematisch bewertet werden. So entsteht eine belastbare Grundlage für kontrollierte Entscheidungen im Projekt.

Impact-Analysen methodisch sicher durchführen

Erfahren Sie, wie objectiF RPM Requirements Engineering, Traceability und Change Management in einer gemeinsamen Umgebung verbindet.