Traceability: Die wichtigsten Link-Typen

Nachverfolgbarkeit (Traceability) ist wichtig — das hat sich inzwischen herumgesprochen. Doch was bedeutet eigentlich eine Verlinkung? Ein Link hat nämlich eine Semantik, oft nur implizit. Im Folgenden werden die wichtigsten Link-Typen vorgestellt.

Traceability ist ein wichtiges Konzept im Systems Engineering. Warum Nachverfolgbarkeit unsere Aktivitäten unterstützt hatte ich bereits in der Vergangenheit erklärt. In dem Artikel erklärte ich bereits, dass die Bedeutung von Links wichtig ist, aber oft nicht explizit dokumentiert wird, was zu Problemen führen kann.

Die Richtung der Traceability

In der Praxis finden wir zwei unterschiedliche Philosophien zur Richtung der Traceability. Das folgende Bild verdeutlicht dies:

In welche Richtung sollte der Pfeil zwischen „Functional Requirement“ und „Test Case“ gehen? Die kurze Antwort ist: Beides ist richtig, aber die Bedeutung ist unterschiedlich. Konkret:

• (a) Hier bedeutet der Trace: „testet“ (Test Case testet Functional Requirement)
• (b) Hier bedeutet der Trace: „wird getestet von“ (Functional Requirement wird getestet von Test Case)

Heutzutage gibt das Werkzeug die Linkrichtung vor, da diese für bestimmte Funktionen relevant ist. Zum Beispiel kennen alle professionelle Anforderungsmanagementwerkzeuge das Konzept von „suspekten Links“. In diesem Beispiel wird ein Test Case suspekt, wenn sich mindestens eine der verlinkten Functional Requirements verändert hat. Denn dann ist es möglich, dass der Test Case nicht mehr zur Anforderung passt. Aber umgekehrt würde eine Veränderung des Test Cases keine Auswirkungen bezüglich „suspect“ auf das Functional Requirement haben. Falls am Test Case allerdings ein „Test Result“ hängen würde, würde dies durch die Änderung des Test Cases suspekt werden.

Da moderne Werkzeuge sowieso die Navigation der Traceability in beide Richtungen erlauben, ist ein klares Verständnis im Team wichtiger als die eigentliche Wahl der zwei Optionen.

Implizite Link-Typen oft ausreichend

Im eben gezeigten Beispiel ist für die meisten Menschen wohl klar, dass die Relation eine Test-Beziehung darstellt. Ein Label am Pfeil „testet“ ist daher redundant. Ob und wie im Werkzeug entsprechende Link-Typen der Traceability angelegt werden ist auch zweitrangig. Hier sollte darauf geachtet werden, dass die Arbeit der Nutzer nicht erschwert wird, bspw. dadurch, dass als zusätzlicher Arbeitsschritt ein Link-Typ ausgewählt werden muss. Natürlich sollte dennoch in der Prozessdokumentation die Semantik des Links beschrieben werden. Eine Daumenregel: Wenn ein bestimmter Anwendungsfall explizite Link-Typen benötigt, bspw. um entsprechende Filter nutzen zu können, dann ist dies gerechtfertigt.

Die wichtigsten Link-Typen der Traceability

Die hier beschriebenen Link-Typen finden im Anforderungsmanagement Anwendung. Falls es entsprechende Link-Typen aus dem MBSE geben sollte (bspw. über die SysML definiert), so werden diese mit herangezogen.

„Derive“ beschreibt die Beziehung zwischen zwei Anforderungen, wobei die erste von der zweiten abgeleitet wurde. Eine Derive-Beziehung zeigt oft an, dass wir von einer Ebene zur Nächsten gewechselt haben, also bspw. von Systemsicht zur Designsicht. Ich empfehle, möglichst eine Derive-Beziehung nicht in der selben Ebene zu benutzen (auch wenn es Situationen gibt, wo dies Sinn machen könnte).

Das bedeutet in der Regel auch, dass abgeleitete Anforderung mit in der übergeordneten Anforderung nicht vorhanden Informationen angereichert wurde, die sich zum Beispiel aus Design-Entscheidungen ergeben..

Statt „testen“ weiter open hätten wir auch allgemeiner „verifizieren“ schreiben können. Denn Testen ist nur eine Möglichkeit des Verifizierens. Diese Beziehung wird in der Praxis extrem häufig benutzt. Probleme kann es bei einem Toolbruch geben, wenn es also keine automatische Traceability zwischen Anforderungen und Tests gibt.

Link-Typen für MBSE Traceability

Mit den zwei eben beschriebenen Link-Typen können wir bereits alle Beziehungen in einem primitiven V-Modell darstellen. In der Praxis kommen allerdings fast immer weitere dazu, selbst bei traditionellem Systems Engineering. Dazu weiter unten mehr.

Auch beim modellbasierten Systems Engineering (MBSE) arbeiten wir mit textuellen Anforderungen. Daher benötigen wir hier auch die eben vorgestellten Link-Typen Derive und Verify. Es kommen aber weitere hinzu:

„Refine“ wird benutzt, um Informationen zu präzisieren. Die Refine-Beziehung stammt aus der Modellierung und wird oft für Beziehungen zwischen Modellelementen und Anforderungen benutzt. Im traditionellen Anforderungsmanagement (ohne Systemmodellierung) empfehle ich auf den Verzicht von Refine, um das Team nicht durch die Ähnlichkeit mit Derive zu verwirren.

Ebenfalls in der Modellierung zeit der Satisfy-Link, wie Modellelemente entsprechende Anforderungen erfüllen. Wie Refine ist die Satisfy-Beziehung die Brücke zwischen (textuellen) Anforderungen und Modell.

Eine wichtige Aktivität im Systems Engineering ist das „schneiden“ in Subsysteme und Komponenten. Dadurch realisieren wir die Entkopplung des Systems, was die Komplexität beherrschbar macht. Um die Brücke zwischen der logischen und konkreten Struktur des Systems zu schlagen, müssen wir logische Elemente den konkreten zuordnen. Das geschieht durch Zuordnung von Funktionen auf Subsysteme mit dem Link-Typen Allocate.

Weitere Link-Typen

Was ich hier vorgestellt habe ist das absolute Minimum. Gerade bei der Entwicklung von Systemen, bei denen Sicherheit eine Rolle spielt, benötigen wir spezielle Link-Typen für die entsprechende Traceability. Dazu gehört zum Beispiel „Mitigation“ (Entschärfung), die Risiken mit den Anforderungen verknüpft, die diese entschärfen.

Im Anforderungsmanagement können wir uns die Traceability und Link-Typen nach den eigenen Bedürfnissen konfigurieren. Insofern gibt es da auch keine wirklichen Standards, sondern lediglich Best Practices. Das trifft ebenfalls auf die Semantik der Links zu. Dies zu dokumentieren ist empfehlenswert.

Beim MBSE hingegen gibt die Modellierungssprache in der Regel die sowohl die Link-Typen vor als auch deren Semantik. Die hier gezeigten Link-Typen sind der SysML entlehnt, sind aber in den meisten Modellierungssprachen ähnlich. Hier empfehle ich sicherzustellen, dass alle Teammitglieder das richtige und dasselbe Verständnis der verwendeten Link-Typen haben.

Nicht vergessen: Implizite Traceability

Zuletzt: Nicht alle Traces sind explizit. Auch für die impliziten Link-Typen muss das Team ein gemeinsames Verständnis haben. Um nur ein Beispiel zu nennen: Selbst beim dokumentenbasierten Arbeiten haben Überschriften eine Bedeutung und haben eine implizite Traceability zu den Absätzen in dem Kapitel. Das mag zwar trivial klingen, aber gerade solche Dinge können zu großen (und teuren) Missverständnissen führen.

Photo by Susan Q Yin on Unsplash