Das Problem mit klassischen Trace-Taxonomien
Traditionelle Requirements-Engineering-Tools zwingen Anwender dazu, jede Verbindung zwischen Anforderungen mit semantischen Labels zu versehen: derives from, satisfies, refines, implements, allocated to, verified by – die Liste wird je nach Tool und Standard immer länger.
In der Theorie soll diese Klassifizierung Klarheit schaffen. In der Praxis fĂĽhrt sie zu:
- Endlosen Diskussionen ohne Mehrwert: Teams verbringen Stunden damit zu debattieren, ob eine Anforderung nun "derived" oder "refined" ist
- Inkonsistenter Anwendung: Selbst erfahrene Engineers klassifizieren dieselbe Beziehung unterschiedlich
- Scheingenauigkeit: 15 Trace-Typen suggerieren Präzision, wo keine existiert
Der OTSM-Ansatz: Traces die Fragen beantworten
Eine Anforderung wird zerlegt, bis sie prĂĽfbar ist. Die relevanten Fragen im Engineering-Alltag sind:
- Impact-Analyse: Was ist betroffen, wenn sich diese Anforderung ändert?
- Coverage-Analyse: Ist jede Kundenanforderung bis zum Test abgedeckt?
- Root-Cause-Analyse: Woher stammt diese technische Vorgabe ursprĂĽnglich?
Alle drei Fragen werden durch eine einfache Parent-Child-Beziehung beantwortet. Ob diese Beziehung akademisch als "derives", "satisfies" oder "refines" bezeichnet wird, ändert an der Antwort nichts.
Traces in OTSM
OTSM unterscheidet nur dort, wo die Unterscheidung praktische Konsequenzen hat:
- Hierarchie: Element ist Teil eines übergeordneten Elements → Struktur, Zerlegung
- Fehler-Kette: Fehler A verursacht Fehler B → FMEA, Risikoanalyse
- Funktions-Kette: Funktion A beeinflusst Funktion B → Systemverständnis
Die Fehler-Ketten entstehen aus der FMEA-Analyse, die Funktions-Ketten werden automatisch daraus abgeleitet. Keine manuellen Labels, keine Interpretationsspielräume, keine Diskussionen über Semantik.
Das Ergebnis
Anstatt Zeit mit Taxonomie-Debatten zu verbringen, konzentrieren sich Anwender auf das, was zählt: Anforderungen so zu zerlegen, dass sie testbar sind, und Fehlerauswirkungen zu verstehen, bevor sie im Feld auftreten.
Die Rückverfolgbarkeit ist vollständig gegeben – von der Kundenanforderung bis zum Testfall, vom Hazard bis zur technischen Sicherheitsanforderung. Nur ohne den akademischen Ballast, der in der Praxis niemanden interessiert.
