Wenn ein Kunde eine einzige Änderung wünscht – zum Beispiel eine andere Kabel-Beschichtung ohne Schadstoffe – und diese Änderung erst drei Wochen später zufällig auffällt, weil die Spezifikation noch den alten Stand zeigt, dann liegt das Problem nicht am Konstrukteur. Es liegt daran, dass sechs verschiedene Programme sechs verschiedene, unabhängig gepflegte Wahrheiten über dasselbe Bauteil enthalten.
Das ist kein Einzelfall und kein Zeichen von Schlamperei. Das ist die vorhersehbare Folge einer Architekturentscheidung, die vor Jahrzehnten getroffen wurde und die kaum jemand noch als Entscheidung erkennt.
Der Einwand, den ich ernst nehme#
Man könnte sagen: Dafür gibt es doch Traceability-Matrizen, DOORS, Polarion, ALM-Suiten mit Verlinkungsfunktion. Das Problem ist doch längst gelöst, es ist nur eine Frage der Disziplin, die Links zu pflegen.
Das ist der Kern des Missverständnisses. Diese Werkzeuge lösen das Problem nicht – sie verschieben es auf die Disziplin der Menschen, die die Links pflegen müssen. Und Disziplin skaliert nicht linear mit der Anzahl der Verknüpfungen. Bei einem Bauteil mit hundert Anforderungen, verteilt über Architektur, Risikoanalyse und Spezifikation, entstehen tausende potenzielle Verknüpfungen. Jede Änderung an einer Stelle verlangt manuelles Nachpflegen an allen anderen. Das ist keine Fleißaufgabe, das ist eine kombinatorische Wette gegen die Zeit – und die Zeit gewinnt praktisch immer.
Die eigentliche Ursache: die Tyrannei der einen Gliederung#
Klassische Engineering-Werkzeuge erzwingen fast immer eine Hauptgliederung – meist die physische Bauteilstruktur. Alles andere (Anforderungen, Zustände, Risiken, Testfälle) wird dieser einen Gliederung als Anhängsel untergeordnet. In der Software-Entwicklung heißt dieses Phänomen seit über zwanzig Jahren „Tyranny of the dominant decomposition" – die Tyrannei der einen Zerlegung.
Das Problem: Ein Bauteil hat nicht nur eine sinnvolle Gliederung. Es hat mindestens zwei, die gleichzeitig gültig sind und die sich gegenseitig nicht ersetzen:
- Die mechanische Zerlegung – woraus besteht das Bauteil physisch?
- Die Steuerungs-Struktur – wer steuert wen, welches Signal geht wohin?
Eine Anforderung wie „Bremsweg unter 40 Metern" betrifft nicht nur ein Bauteil. Sie betrifft eine Funktion, die über mehrere Steuerungsknoten und mehrere physische Komponenten verteilt ist. Zwingt man das Werkzeug, sich für eine der beiden Gliederungen zu entscheiden, wird die andere zu Freitext, zu Kommentaren, zu Excel-Spalten, die niemand mehr synchron hält.
Was ADRA anders macht#
ADRA – Architecture-Driven Requirements Allocation – kehrt die Reihenfolge um. Statt Anforderungen in eine Gliederung hineinzuquetschen, werden sie explizit auf beide Strukturen gleichzeitig alloziert: auf die Steuerungs-Architektur und, wo physisch relevant, auf die mechanische Architektur. Diese Zuordnung ist keine Notiz, sondern eine erstklassige, geprüfte Kante im Datenmodell.
Daraus folgt etwas, das mit reiner Verlinkungs-Disziplin nicht erreichbar ist: Vollständigkeit wird prüfbar statt behauptet. Ein automatisierter Check – kein Workshop, kein Review-Meeting – kann exakt feststellen:
- Hat jede Anforderung eine Verifikationsmethode? (Pflicht nach ISO/IEC/IEEE 29148, ohne Ausnahme.)
- Ist jede Anforderung mindestens einer Steuerungs- und, sofern physisch relevant, einer Bauteil-Struktur zugeordnet?
- Hat jede Steuerungsaktion ein Bauteil, das sie tatsächlich ausführt?
Was vorher ein Audit-Marathon war – manuell durch hunderte Zeilen einer Traceability-Matrix klicken – wird zu einer deterministischen Prüfung, die in Sekunden läuft, weil sie gegen eine Struktur läuft, die die Zuordnung ohnehin erzwingt.
Die Pointe: Fachsichten bleiben, die Doppelpflege verschwindet#
Der berechtigte Einwand jedes erfahrenen Requirements-Engineers lautet an dieser Stelle: „Ich will aber weiter mein gewohntes Anforderungsdokument sehen. Der Sicherheitsanalytiker will weiter sein FMEA-Formblatt. Der Architekt will weiter sein Strukturbild."
Genau das bleibt erhalten. Anforderungsdokument, FMEA-Bericht, Architekturbild, Testplan – das sind Sichten, die aus demselben zugrundeliegenden Modell erzeugt werden, nicht getrennte Systeme, die synchronisiert werden müssen. Was verschwindet, ist ausschließlich die Arbeit zwischen den Sichten: das Übertragen, das Abgleichen, das Suchen nach dem aktuellen Stand.
Drei Dinge nimmt auch ADRA niemandem ab, weil sie genuin menschliches Urteil verlangen:
- Der Streit um den richtigen Schnitt – wie ein Produkt sinnvoll zerlegt wird, bleibt Ingenieursentscheidung.
- Anforderungen, die mehrere Elemente gleichzeitig betreffen (z. B. ein Gewichtsbudget) – das Aufteilen ist eine Entscheidung, keine Automatik.
- Schnittstellen mit zwei Eigentümern – was der eine liefert, muss der andere vertragen. Die Methode macht das Paar sichtbar und prüfbar; einigen müssen sich die Menschen.
Wer verspricht, auch das zu automatisieren, verspricht zu viel.
Was das für den Alltag heißt#
Die Kunden-E-Mail mit dem Wunsch nach der schadstofffreien Beschichtung trifft in einer ADRA-Struktur nicht auf sechs Programme, sondern auf eine Anforderung, die – weil sie korrekt alloziert ist – automatisch anzeigt, welche Risikoanalyse, welche Architektur und welche Spezifikation betroffen sind. Nicht durch einen Menschen, der zufällig danach sucht. Durch die Struktur selbst.
Das ist der ganze Unterschied zwischen einem Werkzeug, das Traceability ermöglicht, und einer Architektur, die Traceability erzwingt.
Das vollständige Umsetzungskonzept – inklusive Datenmodell, den drei deterministischen Prüf-Gates und der Abgrenzung zu klassischem Requirements-Tooling – gibt es hier als PDF zum Download.