Impact-Analyse (Auswirkungsanalyse)
Die Impact-Analyse (Auswirkungsanalyse) ermittelt anhand von Trace-Links, welche Artefakte — Anforderungen, Architektur, Code, Tests, Nachweise — von einer Änderung betroffen sind. Sie macht Änderungskosten und -risiken abschätzbar, bevor die Änderung umgesetzt wird. Zusammen mit der Coverage-Analyse ist sie eine der beiden Kern-Auswertungen von Requirements Traceability.
Wie funktioniert eine Impact-Analyse?
Gepflegte Trace-Links machen aus den Projektdaten einen Graphen: Artefakte sind die Knoten, semantische Beziehungen wie „wird verifiziert durch“ oder „wird erfüllt durch“ die Kanten. Die Impact-Analyse folgt diesen Kanten — direkt oder über Ketten von Links, in beide Richtungen — und beantwortet Fragen wie:
- Welche Teile des Systems sind von diesem Change Request betroffen?
- Ein Test schlägt fehl — welche Anforderungen werden nicht korrekt erfüllt?
- Eine Anforderung ändert sich — welche Architekturelemente, Software-Komponenten, Testfälle und Safety-Nachweise müssen neu bewertet werden?
Typische Auslöser
In regulierten Entwicklungsprojekten stößt nicht nur der klassische Change Request eine Impact-Analyse an:
- Geänderte Anforderungen: die häufigste Ursache — jede Anforderungsänderung wirft die Frage auf, was mitgeändert und was neu getestet werden muss.
- Neu bewertete Gefährdungen: Wird ein Gefährdungsereignis in der HARA neu eingestuft, zeigen Trace-Links unmittelbar, welche Sicherheitsanforderungen, Analysen und Testfälle betroffen sind — und welche unberührt bleiben.
- Neue Schwachstellen: Ein neues CVE in einer verbauten Komponente verlangt die Antwort, welche Angriffspfade, Security Controls und Verifikationsnachweise neu zu bewerten sind.
- Architekturänderungen: Ändert sich ein Architekturelement, pflanzt sich die Änderung in abhängige Analysen wie FMEA und FTA fort.
Impact-Analyse vs. Coverage-Analyse
Die Impact-Analyse wertet aus, was verknüpft ist: Sie folgt bestehenden Links und findet Betroffene. Die Coverage-Analyse wertet aus, was nicht verknüpft ist: Fehlende Links sind Indikatoren für offene Arbeit — eine Anforderung ohne Testfall wurde wahrscheinlich nicht getestet. Beide Analysen brauchen dieselbe Datenbasis, beantworten aber unterschiedliche Fragen: die eine steuert Änderungen, die andere misst Fortschritt und Vollständigkeit.
Warum Impact-Analysen ohne Traceability nicht skalieren
Wer die Querbezüge zwischen Artefakten nicht als digitale Trace-Links pflegt, muss sie bei jeder Änderung mühsam von Hand rekonstruieren — quer durch Anforderungswerkzeug, Modellierungsumgebung, Repository und Testmanagement. Bei kurzen Entwicklungszyklen skaliert das nicht: Eine Impact-Analyse, die Wochen an Handarbeit kostet, passt in keinen Sprint. Der Nutzen der Verknüpfung ist dabei messbar: In einer empirischen Studie mit 71 Probanden bearbeiteten Entwickler Wartungsaufgaben mit Traceability im Schnitt 24 % schneller und lieferten 50 % mehr korrekte Lösungen.
Impact-Analyse in der Praxis: Von der Recherche zur Abfrage
Damit die Auswirkungsanalyse zur beantwortbaren Frage statt zur Neubewertung auf Verdacht wird, braucht es drei Voraussetzungen: eindeutig identifizierbare Artefakte, gepflegte Links über Werkzeuggrenzen hinweg und ein Traceability Information Model, das die Beziehungstypen definiert. Sind sie erfüllt, zeigt eine durchgängige Traceability-Schicht bei einer Anforderungsänderung auf Abruf, welche Software-Komponenten, Testfälle, Safety-Nachweise und Security Controls betroffen sind — die erfahrungsgemäß größte Stellschraube zur Senkung von Änderungskosten in regulierten Projekten.