Klassische Werkzeuge zwingen Anforderungen in eine Gliederung und verlangen, dass alles auf jeder Ebene wiederholt wird. Ab einigen hundert Anforderungen kippt das, und der Analyst vereinfacht — unkontrolliert und undokumentiert. Architecture-Driven Requirements Allocation, kurz ADRA, dreht die Reihenfolge um: Die Architektur ist der Anker, die Zuordnung ist eine geprüfte Beziehung, und Vollständigkeit wird nachrechenbar statt behauptet.
Rechnen Sie einmal nach, was gepflegt werden muss
Ein mittelgroßes Projekt mit Bestandssystem, realistische Größenordnung:
Was in der Praxis passiert, kennt jeder, der es einmal gemacht hat: Irgendwo zwischen Anforderung 400 und 600 beginnt das Konstrukt zu kippen. Das Werkzeug wird langsam. Die Übersicht geht verloren. Und dann beginnt der Analyst zu vereinfachen.
Diese Vereinfachung ist der eigentliche Befund. Sie geschieht unkontrolliert, sie wird nicht aufgeschrieben, und sie hängt vollständig am Wissen und der Sorgfalt der jeweiligen Person. Kein Prozess, keine Nachvollziehbarkeit, keine Auditierbarkeit.
Das Ergebnis ist keine schlechte Analyse. Es ist eine Analyse mit unbekannten Lücken.
Die Tyrannei der dominanten Gliederung
Klassische Werkzeuge erzwingen eine Hauptgliederung — meist die physische Bauteilstruktur. Alles andere, also Anforderungen, Zustände, Risiken, Testfälle, wird dieser einen Gliederung als Anhängsel untergeordnet. In der Softwaretechnik heißt dieses Phänomen seit über zwanzig Jahren Tyranny of the dominant decomposition — die Tyrannei der einen Zerlegung.
Das Problem: Ein technisches System hat nicht eine sinnvolle Gliederung. Es hat mindestens zwei die gleichzeitig gültig sind und einander nicht ersetzen.
Wann Lösungsfreiheit Sinn ergibt — und wann sie Theater ist
Der Systems-Engineering-Ansatz nach SOPHIS oder INCOSE und ISO/IEC 15288 ist im Grundsatz richtig: Anforderungen lösungsfrei formulieren, erst danach die Architektur entscheiden. Für Neuentwicklungen ist das der korrekte Weg.
Bei Bestandssystemen ist derselbe Ansatz ein Kategorienfehler. Ein Notstromaggregat, ein Fahrzeuggetriebe, eine Medizinpumpe — die Architektur dieser Systeme ist keine Designentscheidung mehr. Motor, Generator, Rahmen, Steuerung sind physische Realität. Ihnen gegenüber auf Lösungsfreiheit zu bestehen ist methodisch nicht sauber.
Erfahrene Ingenieure umgehen die Doktrin ohnehin. Sie weisen Anforderungen direkt den Komponenten zu (was technisch korrekt ist), sie aggregieren Funktionen, sie vereinfachen das Systemmodell. Das Problem ist nicht, dass sie es tun. Das Problem ist, dass es implizit geschieht, jeder es ein bisschen anders macht und niemand aufschreibt, warum. Das nächste Projekt beginnt wieder bei null.
ADRA ist die Formalisierung dessen, was ohnehin funktioniert — mit vollständiger Nachvollziehbarkeit.
Fünf Grundsätze
| Grundsatz | Wirkung |
|---|---|
| Einmal erfassen, per Zuordnung sichtbar | Keine Doppelpflege auf jeder Hierarchieebene |
| Die Architektur ist der Anker | Nicht eine abstrakte Funktionshierarchie, die niemand pflegt |
| Zuordnung auf beide Strukturen | Steuerungsarchitektur und, wo physisch relevant, mechanische Architektur |
| Funktionen werden aggregiert | Aus 700 Systemfunktionen werden 50 bis 80 analyserelevante |
| Die Granularität tragen die Fehlerbilder | Nicht die Funktionen — sonst wächst die Menge wieder |
Das Ergebnis wird überschaubar und vollständig, prüfbar.
Einmal generisch — gepflegt wird nur, was abweicht
Zurück zu den 800 Anforderungen, die für jede Komponente gelten. Bei zwanzig Komponenten wären das sechzehntausend Einträge, die dasselbe sagen. Sie einzeln zu pflegen ist ausgeschlossen. Sie einzeln zu filtern übrigens auch — eine Triage, die jede Anforderung gegen jede Komponente prüft, ist dasselbe Skalierungsproblem in Grün.
Der einzige Weg, der trägt: einmal am Typ deklarieren, alle Verwendungen erben per Verweis, und gepflegt wird ausschließlich die Abweichung.
Zwei Regeln machen das tragfähig.
Die Abweichung ist eine Abweichung, keine Kopie. Wer eine Anforderung für eine Komponente ändert, erzeugt keinen zweiten Text, der irgendwann auseinanderläuft. Er erzeugt einen sichtbar markierten Unterschied gegenüber dem Typ. Man sieht auf einen Blick, wo abgewichen wurde — und warum.
Die Verwendung verweist auf einen Stand, nicht auf einen Namen. Der Typ ist versioniert. Eine Komponente hängt an einer bestimmten Fassung. Ändert sich der Typ, ist sichtbar, welche Verwendungen auf dem alten Stand stehen — statt dass es niemand merkt.
Dasselbe gilt für fachliche Sichten wie Sicherheit, Umwelt oder elektromagnetische Verträglichkeit. Sie sind zusätzliche Facetten an einem Objekt, keine exklusiven Kategorien. Ein Bauteil wird nicht „zu einem Sicherheitsteil", weil jemand eine Sicherheitsanforderung daran hängt — es trägt danach eine Facette mehr. Die Sicherheitssicht zeigt dann alle Objekte mit dieser Facette, nicht die Objekte, die Sicherheit sind. Wer daraus ein exklusives Attribut macht, erzeugt Kopien, und Kopien laufen auseinander.
Der Filter ist kein Arbeitsschritt am Anfang. Er ist eine Eigenschaft der Struktur.
Vollständigkeit wird prüfbar statt behauptet
Weil die Zuordnung eine eigenständige Beziehung im Modell ist und keine Notiz, kann eine Maschine sie prüfen. Drei Fragen, deterministisch beantwortbar, ohne Workshop und ohne Review-Meeting.
Das ist der Unterschied zwischen einem Werkzeug, das Nachvollziehbarkeit ermöglicht, und einer Struktur, die sie erzwingt.
Bricht das mit ISO 26262?
Das ist die häufigste Reaktion. Die kurze Antwort ist nein — und es lohnt, die beiden Spalten nebeneinanderzulegen.
| Was die Standards fordern | Was kein Standard vorschreibt |
|---|---|
| Bidirektionale Nachvollziehbarkeit von der Anforderung über Funktion und Komponente bis zum Test | Dass jede Anforderung auf jeder Hierarchieebene explizit erscheint |
| Lückenloser Anforderungsnachweis — keine Anforderung ohne Verifikation | Eine bestimmte Werkzeugstruktur oder Hierarchietiefe |
| Vollständigkeit der Verifikation | Redundante Verknüpfungen durch alle Ebenen |
| Nachvollziehbarkeit jeder Zuweisung | — |
Das eigentliche regulatorische Risiko liegt nicht in diesem Ansatz. Es liegt in den unkontrollierten Vereinfachungen, die Analysten in klassischen Werkzeugen vornehmen — undokumentiert, nicht nachvollziehbar, nicht auditierbar.
Was bleibt, und was verschwindet
Der berechtigte Einwand jedes erfahrenen Requirements-Engineers lautet: „Ich will weiter mein gewohntes Anforderungsdokument sehen. Der Sicherheitsanalytiker will sein Formblatt. Der Architekt will sein Strukturbild."
Genau das bleibt. Anforderungsdokument, Fehleranalyse, Architekturbild, Testplan sind Sichten auf dasselbe Modell — keine getrennten Systeme, die synchronisiert werden müssen.
Drei Dinge nimmt auch ADRA niemandem ab
- Der Streit um den richtigen SchnittWie ein Produkt sinnvoll zerlegt wird, bleibt eine Ingenieursentscheidung. Die Methode setzt eine Architektur voraus, sie erzeugt keine.
- Anforderungen, die mehrere Elemente gleichzeitig betreffenEin Gewichtsbudget aufzuteilen ist eine Entscheidung, keine Automatik.
- Schnittstellen mit zwei EigentümernWas 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.
Und der Wirksamkeitsnachweis fehlt. Es gibt für ADRA keine kontrollierte Studie. Was es gibt, sind Prüfungen, die scheitern können: Eine Anforderung ist zugeordnet oder nicht. Ein Verifikationskriterium existiert oder nicht. Eine Verwendung steht auf dem aktuellen Stand oder nicht. Das ist kein Beweis — es ist die Bedingung dafür, dass je einer möglich wird. Der ehrliche Vergleich lautet nicht „ADRA gegen bewiesene Alternative", sondern dokumentierte Zuordnung gegen undokumentierte Vereinfachung.
Weiterlesen
Die erzählte Fassung mit dem Beispiel aus dem Alltag steht im Beitrag Warum euer bester Konstrukteur drei Wochen braucht, um eine E-Mail zu verarbeiten. Der übergeordnete Rahmen steht unter Lebensfähigkeit, die Prüfung von Schnittstellen und Gefahrenmengen unter Der erlaubte Raum.