Wenn Architektur und Anforderungen in separaten Werkzeugen gepflegt werden, wird das Verständnis der Auswirkungen einer Änderung zu einer der anspruchsvollsten Aufgaben im Systems Engineering. Teams verfügen über Verknüpfungen zwischen MBSE-Modellen und ALM-Artefakten. Es existieren definierte Änderungsprozesse und Review-Mechanismen. Und dennoch bleibt der tatsächliche Umfang architekturseitiger Änderungen häufig bis in späte Projektphasen unentdeckt. Das Problem liegt weder in fehlenden Links noch in unzureichenden Prozessen. Es liegt darin, dass eine MBSE-Impactanalyse eine Form von Systemverständnis erfordert, die weder das MBSE-Werkzeug noch das ALM-Werkzeug isoliert leisten können – und dass die Grenze zwischen beiden eine automatisierte Bewertung strukturell erschwert.

Was eine MBSE-Impactanalyse leisten sollte

In einer modellbasierten Systems-Engineering-Umgebung trägt die Architektur Struktur, Kontext und Beziehungslogik. Anforderungen sind nicht lediglich Textobjekte, sondern werden nachvollziehbar Komponenten, Schnittstellen, Verhaltensbeschreibungen und Konfigurationen zugeordnet.

Funktioniert diese Integration konsistent, ermöglicht die MBSE-Impactanalyse unter anderem die Identifikation betroffener Architekturelemente bei Anforderungsänderungen, die Erkennung nachgelagerter Verifikationsauswirkungen, die Bewertung von Konsequenzen pro Variante oder Baseline sowie die Bereitstellung belastbarer Nachweise für Compliance-Reviews.

Werden Architektur und Anforderungen jedoch in getrennten Systemen verwaltet, bricht diese Logik – oft unbemerkt – auseinander.

MBSE-Impactanalyse ist kein Navigationsproblem

In vielen Organisationen wird Impactanalyse im Rahmen der MBSE-ALM-Integration als Navigationsaufgabe verstanden: Wenn sich von einem Architekturelement per Klick zur verknüpften Anforderung wechseln lässt, gilt die Integration als erfolgreich.

Diese Annahme ist grundlegend falsch – und sie erklärt, warum MBSE-Impactanalysen in realen Engineering-Umgebungen regelmäßig versagen.

Impactanalyse bedeutet nicht, einen Link zu finden. Sie bedeutet zu verstehen, was sich systemisch verändert, wenn sich ein Element ändert: Welche Anforderungen sind betroffen? Welche Testfälle müssen neu bewertet werden? Welche Sicherheitsziele könnten ihre Gültigkeit verlieren? Diese Art der Analyse lässt sich nicht auf das bloße Folgen eines Hyperlinks zwischen zwei Werkzeugen reduzieren.

Die Realität getrennter Werkzeuge

In den meisten Engineering-Organisationen wird die Architektur in einem MBSE-Werkzeug modelliert, während Anforderungen in einem ALM-System verwaltet werden. Jedes System erfüllt seine Aufgabe isoliert betrachtet sehr gut. Die Problematik entsteht an der Schnittstelle.

Soll die Auswirkung einer Architekturänderung bewertet werden, sieht der Prozess häufig folgendermaßen aus:

1. Identifikation des geänderten Elements im MBSE-Modell
2. Suche nach vorhandenen Verknüpfungen zu ALM-Artefakten
3. Wechsel ins ALM-System und Lokalisierung der verknüpften Anforderungen
4. Mentale Rekonstruktion weiterer potenziell betroffener Anforderungen, Testfälle oder Change Requests
5. Wiederholung dieses Vorgangs für zahlreiche abhängige Elemente

Dies ist keine Impactanalyse im eigentlichen Sinne. Es ist eine manuelle Rekonstruktion. Sie ist zeitaufwendig, fehleranfällig und skaliert nicht mit der Komplexität realer Systeme.

Warum das Problem strukturell ist

Fehler in der werkzeugübergreifenden Impactanalyse entstehen nicht aus Nachlässigkeit. Sie resultieren aus einem grundlegenden Unterschied in der Art, wie MBSE- und ALM-Werkzeuge technisches Wissen repräsentieren.

Ein MBSE-Modell bildet Architektur als Beziehungsgraph ab. Änderungen an einem Element propagieren entlang dieser Beziehungsstruktur – oft auf nicht unmittelbar sichtbare Weise. Ein ALM-System kennt diese interne Struktur nicht. Es erkennt lediglich, welche Artefakte mit welchen Architekturelementen verknüpft sind, nicht jedoch deren interne Zusammenhänge im Modell.

Diese Kontextinformation verbleibt im MBSE-Werkzeug. Eine Impactanalyse ausgehend vom ALM-System bleibt daher zwangsläufig unvollständig. Eine Analyse ausgehend vom MBSE-System wiederum erfordert, dass Ingenieure Kontext manuell über die Werkzeuggrenze hinweg übertragen.

Das verdeckte Propagationsproblem

Besonders kritisch sind jene Fehler, die unbemerkt bleiben. Eine Verknüpfung existiert, eine Anforderung wurde aktualisiert – die Änderung scheint abgeschlossen. Tatsächlich ist sie es nicht.

Ein vereinfachtes Beispiel: Eine Schnittstellenspezifikation wird im Architekturmodell geändert. Diese Schnittstelle ist mit einer Systemanforderung im ALM-System verknüpft. Die Anforderung wird überprüft und angepasst. Formal ist der Vorgang abgeschlossen.

Im Modell existieren jedoch weitere Blöcke, die dieselbe Schnittstelle verwenden. Diese Blöcke sind wiederum mit anderen Anforderungen verknüpft. Die Änderung propagiert durch den Architekturgraphen – bleibt für das ALM-System jedoch unsichtbar. Die zugehörigen Anforderungen werden nie zur Überprüfung angestoßen.

Das Ergebnis ist eine scheinbar vollständige Traceability, die faktisch nicht mehr der Systemrealität entspricht. Es entsteht eine stille Erosion der Konsistenz.

Wenn getrennte Werkzeuge getrennte Realitäten erzeugen

Werden MBSE- und ALM-Systeme unabhängig voneinander betrieben, entwickeln sie sich mit der Zeit auseinander.

Architekturen werden refaktoriert: Blöcke werden umbenannt, restrukturiert, aufgeteilt oder zusammengeführt. Diese Änderungen werden im MBSE-Modell konsistent gepflegt. Im ALM-System hingegen bleiben Verknüpfungen bestehen – möglicherweise zu Elementen, die nicht mehr existieren oder deren strukturelle Rolle sich verändert hat.

Aus Sicht des ALM-Systems wirkt die Traceability-Matrix konsistent. Die Links sind vorhanden. Aus Sicht des MBSE-Modells verweisen sie auf einen überholten Zustand. Keine der beiden Umgebungen erkennt diese Inkonsistenz automatisch.

Dies erklärt, warum Impactanalysen in solchen Umgebungen häufig auf Skepsis stoßen. Die Daten existieren. Die Zusammenhänge nicht.

Compliance-Risiken bei fehlerhafter Impactanalyse

In regulierten Branchen wie Automotive, Aerospace oder Medizintechnik ist Impactanalyse keine Option, sondern Verpflichtung. Auditoren erwarten belastbare Nachweise, dass Anforderungsänderungen vollständig bewertet, architektonische Auswirkungen analysiert, Verifikationsaktivitäten angepasst und Konfigurationskontexte berücksichtigt wurden.

Sind Architektur und Anforderungen entkoppelt, wird die Nachweisführung zur manuellen Rekonstruktion – gestützt auf E-Mails, Meeting-Protokolle und individuelles Erinnerungsvermögen statt auf gesteuerte Traceability-Daten. Der Aufwand für Audits steigt, das Risiko von Abweichungen nimmt zu, und Zertifizierungszeitpläne geraten unter Druck.

Auch außerhalb regulierter Umfelder entstehen erhebliche Effizienzverluste. Die manuelle werkzeugübergreifende Rekonstruktion bindet Engineering-Kapazitäten, die eigentlich für Entwurf und Verifikation benötigt werden – und liefert dennoch Ergebnisse mit begrenzter Vertrauenswürdigkeit.

Was eine wirksame MBSE-Impactanalyse tatsächlich erfordert

Die Lösung liegt nicht im bloßen Hinzufügen weiterer Links zwischen Werkzeugen.

Eine tragfähige Integrationsebene muss die interne Struktur des MBSE-Modells verstehen – nicht nur die übergreifenden Verknüpfungen. Sie muss Änderungen erkennen und deren Konsequenzen automatisch über beide Systeme hinweg propagieren, ohne dass Ingenieure den Kontext manuell rekonstruieren müssen. Zudem muss sie die Gültigkeit von Links über Zeit hinweg sichern, sodass Architektur-Refaktorierungen nicht unbemerkt zu veralteter oder irreführender Traceability führen.

Diese Fähigkeiten sind weder reinem MBSE- noch reinem ALM-Werkzeug inhärent. Sie müssen auf Integrationsebene implementiert werden. Genau deshalb bleibt das Problem selbst in Organisationen bestehen, die umfangreich in beide Werkzeuge investiert haben.

Von isolierter Analyse zu durchgängiger Wirkungslogik

Organisationen, die dieses Problem erfolgreich adressieren, verstehen Impactanalyse nicht als Funktion eines einzelnen Werkzeugs. Sie verorten die Fähigkeit auf Integrationsebene – in einer Komponente, die sowohl die Graphstruktur der Architektur als auch die Artefaktstruktur des ALM-Systems interpretiert und bei Änderungen konsistent traversiert.

Dies ist mehr als eine einfache Tool-Verknüpfung. Es ist eine eigenständige Engineering-Fähigkeit auf Basis der Werkzeugverbindung – eine Fähigkeit, die Impactanalyse von einer manuellen, werkzeugwechselnden Tätigkeit zu einem verlässlichen, automatisierten Prozess transformiert.

---