Requirements Traceability Matrix erstellen: Schritt für Schritt

In diesem Artikel erkläre ich, was eine Requirements Traceability Matrix (RTM) ist und wie man sie erstellt. Falls du noch keine Erfahrung mit Requirements Traceability hast, hier zunächst ein kurzer Überblick.

Traceability ist ein Begriff aus vielen Kontexten. In der Softwareentwicklung ist Requirements Traceability definiert als die Fähigkeit, jede Anforderung von ihrem Ursprung durch die gesamte Entwicklung bis zur Validierung auf jeder Ebene zu verfolgen.

Die Grafik zeigt eine vereinfachte Darstellung eines Traceability-Graphen. Die blauen Knoten repräsentieren verschiedene Entwicklungsartefakt-Typen. Die grünen Knoten sind die Validierungen, die die Qualität und korrekte Umsetzung der Artefakte sicherstellen. Direkte Verbindungen heißen Links, Ketten von Links heißen Traces.

Welche Struktur und Detailtiefe für deinen Traceability-Graphen sinnvoll ist, hängt von deinem Produkt und deinem Prozess ab. Bei der Entwicklung einer Website für einen lokalen Schneider sieht er anders aus als beim Bau sicherheitskritischer Fahrzeugkomponenten oder Medizintechnik. Traceability einzuführen und für die Projektanalyse zu nutzen ist in jedem Fall sinnvoll.

Traceability lässt sich in verschiedene Richtungen auswerten. Es gibt Forward Traceability (z. B. von der Anforderung zur Validierung) und Backward Traceability (von der Validierung zur Anforderung). Jede Richtung erlaubt es, verschiedene Aspekte des Projektstands zu beurteilen. Das Ziel ist es, beide Richtungen abzudecken — bidirektionale Traceability — und genau das ermöglicht die Traceability Matrix.

Was ist eine Requirements Traceability Matrix?

Eine Requirements Traceability Matrix (RTM) ist ein einfaches und effektives Werkzeug, um bidirektionale Traceability im Projekt herzustellen und zu pflegen.

Wie der Name schon sagt, ist eine RTM nichts anderes als eine Tabelle, die die Beziehungen zwischen verschiedenen Entwicklungsartefakten darstellt. Durch ihre Einfachheit kann sie mit dem grundlegendsten Werkzeug erstellt werden — zum Beispiel in Excel. Manchmal macht es sogar Sinn, sie auf einem Whiteboard zu zeichnen, damit sie für das gesamte Team sichtbar ist.

Behalte im Hinterkopf: Eine RTM kann beim Aufbau der Projekt-Traceability hilfreich sein, aber du solltest ihre Grenzen kennen. Es gibt gute Gründe, warum eine Traceability Matrix für komplexe Projekte oft nicht ausreicht.

Hier ein einfaches Beispiel einer RTM als kumulierte Ansicht über einen gesamten Trace von „Anforderung" bis „Validierung":

Zu beachten ist, dass die Tabelle nicht die konkreten Entwicklungsartefakte enthält, sondern diese über eine eindeutige ID referenziert. Obwohl es gute Argumente dafür gibt, detailliertere Informationen zu den Artefakten einzutragen, würde dies die Einfachheit reduzieren und die Information schwerer zugänglich und verständlich machen. Traceability ist nur nützlich, wenn sie konsequent gepflegt wird — und das gelingt nur, wenn sie so einfach wie möglich ist.

Das Beispiel zeigt die Beziehungen zwischen Anforderungen (Req. 1–15) und Validierungen (Val. 1–13) in einer Viele-zu-Viele-Kardinalität. Immer wenn eine Anforderung auf eine Validierung zurückzuführen ist, wird sie mit einem „x" markiert.

Im Sinne der Forward Traceability sieht man auf einen Blick, dass Req. 10, Req. 11, Req. 13 nicht ordnungsgemäß validiert sind. Dreht man die Leserichtung um (Backward Traceability), wird offensichtlich, dass Val. 9 keine Anforderung validiert. Die RTM allein kann nicht erklären, warum ein Problem besteht — aber sie ist äußerst effizient darin, Probleme zu identifizieren und aufzuzeigen, wo man suchen muss.

Wie erstellt man eine Traceability Matrix?

Es gibt drei verbindliche Schritte, um Traceability im Projekt herzustellen, plus einen optionalen vierten Schritt, der den Nutzen nochmals deutlich erhöht.

Schritt 1: Artefakt-Typen identifizieren

Finde zunächst heraus, welche Artefakt-Typen in deinem Projekt vorkommen. Was soll nachverfolgbar sein? Was ist relevant und nützlich für dein Team? Was wird vom Kunden oder anderen Stellen gefordert? Stelle sicher, dass jedes Artefakt später über eine eindeutige ID identifizierbar ist.

Für dieses Beispiel haben wir vier Artefakt-Typen gewählt: Kundenanforderungen, interne Anforderungen, Implementierung und Testfälle.

Weitere Beispiele für Artefakt-Typen:

• Anforderungen (System-, Hardware-, rechtliche Anforderungen)
• UI-Design-Dokumente (Papierprototypen, Mockups, Styleguides, Moodboards)
• Softwarearchitektur (Komponentendiagramme, Statecharts, Klassendiagramme)
• Implementierung (Schnittstellen, Protokolle)
• Tests (Unit-Tests, manuelle Tests)

Schritt 2: Beziehungen zwischen den Artefakten definieren

Definiere, wie die Artefakte miteinander verknüpft werden sollen — berücksichtige dabei nur direkte Links. Das Beispiel enthält drei Link-Typen: Kundenanforderungen → interne Anforderungen, interne Anforderungen → Implementierung und Implementierung → Testfall.

Weitere häufige Link-Typen:

• Kundenanforderung ↔ Systemanforderung
• Software-Anforderung ↔ Softwarearchitektur
• Software-Detaildesign ↔ Implementierung (Code)
• Implementierung (Code) ↔ Unit-Test

Achte beim Erstellen der Links darauf, dass sich jeder Artefakt-Typ auf eine Anforderung zurückführen lässt. Es hilft oft, zunächst eine Skizze des Traceability-Graphen zu zeichnen. Wenn du auf Artefakt-Typen stößt, die (auch transitiv) nicht mit einer Anforderung verbunden sind, hast du entweder einen Link-Typ übersehen — oder dieser Artefakt-Typ ist für dein Projekt schlicht nicht relevant.

Schritt 3: Traceability Matrix für jeden Link erstellen

Erstelle eine Traceability Matrix für jeden Link-Typ. Trage einen Link-Teilnehmer auf eine Achse, den anderen auf die andere Achse. Nutze die Skizze aus Schritt 2, um sicherzustellen, dass kein Link fehlt.

Es empfiehlt sich, für jedes Artefakt ein Statusfeld einzutragen, um die Genauigkeit des abgebildeten Projektstands zu erhöhen. Ein Artefakt kann zum Beispiel angelegt sein, aber noch in Entwicklung — im Beispiel haben wir solche Artefakte als nicht realisiert markiert.

Nach dem Erstellen aller Traceability Matrices hast du bidirektionale Traceability für dein Projekt hergestellt. Um einem Trace in beliebiger Richtung zu folgen, kombinierst du die zugehörigen Matrices — ähnlich wie man Dominosteine aneinanderlegt.

Schritt 4 (optional): Kumulierte Metriken erstellen

Zusätzlich zur Pflege und Auswertung von direkten Links lässt sich die RTM nutzen, um kumulierte Ansichten über ganze Traces zu erstellen. Dazu fasst man die Informationen aus mehreren Matrices in einer einzigen zusammen, um wichtige Informationen leichter zugänglich zu machen.

Die kumulierte Ansicht im Beispiel zeigt die Beziehung von Kundenanforderungen bis hin zu Testfällen — und macht sofort sichtbar, dass nur 47 % der Kundenanforderungen durch einen Test abgedeckt sind.

Wenn du mehr über den Nutzen einer Requirements Traceability Matrix erfahren möchtest, lies unseren Folgeartikel: 5 + 1 Fragen, die eine RTM beantwortet.

Requirements Traceability in der Praxis — Wie durchgängige Traceability in regulierten Projekten wirklich funktioniert, welche Werkzeuge sich bewährt haben und wann der RTM-Ansatz an seine Grenzen stößt: Requirements Traceability bei itemis →