5 + 1 Fragen, die eine Requirements Traceability Matrix beantwortet

Im vorherigen Teil haben wir eine kurze Einführung in Requirements Traceability gegeben und gezeigt, wie man eine Requirements Traceability Matrix erstellt. Jetzt schauen wir uns an, wie wir die darin enthaltenen Informationen nutzen können, um fünf wichtige Fragen im Projektalltag zu beantworten.

Als Beispiel nehmen wir den im Titelbild dieses Artikels gezeigten Traceability-Graphen, in dem wir von „Kundenanforderungen" bis zu „Tests" verfolgen.

Aus diesem Graphen leiten wir einen Satz Traceability Matrices ab, die für diesen Artikel bewusst einfach gehalten sind:

Für jeden Link in unserem Trace-Graphen haben wir eine Matrix erstellt, die die vorhandenen Artefakte und ihre Verknüpfungen enthält. Zusätzlich gibt es eine vierte Matrix, die die anderen drei zu einer einzigen Ansicht zusammenfasst.

Frage 1: Wird das Produkt korrekt gebaut?

Dies ist das klassische Beispiel für Forward Traceability. Kunden oder Stakeholder akzeptieren ein Produkt in der Regel nur, wenn es alle spezifizierten Anforderungen erfüllt. Mit einer lückenlosen Traceability kannst du nachweisen, dass du genau das gebaut hast, was vereinbart wurde. Nutze den Satz von Traceability Matrices, um zu prüfen, ob jede Anforderung durch einen Testfall abgedeckt ist und ob diese Tests erfolgreich ausgeführt wurden.

Der einfachste Ansatz ist, die Traces von jeder Anforderung über ihre Implementierung bis zum bestätigenden Testfall zu verfolgen. Im Beispiel oben könntest du zum Beispiel den Trace „CustReq. 1" → „IntReq. 1" → „Impl. 1" → „Testfall 1" verfolgen.

Wenn alle Anforderungen mit Testspezifikationen verknüpft sind, die wiederum mit erfolgreichen Tests verknüpft sind, ist die Arbeit getan. Du hast das gebaut, was spezifiziert wurde — und kannst es nachweisen.

Im Beispiel oben gibt es jedoch noch einiges zu tun: Für Kundenanforderungen 2 und 3 existiert kein Trace zu einem Testfall, der ihre Erfüllung bestätigt.

Frage 2: Wird das richtige Produkt gebaut?

Backward Traceability ermöglicht es, Validierungen oder Entwicklungsartefakte zu finden, die von keiner Anforderung abgeleitet wurden. Von jedem Test und jedem Entwicklungsartefakt sollte ein Trace zurück zu einer übergeordneten Anforderung führen. Das Argument: Projekte haben meist knappe Zeit- und Budgetressourcen, daher ist es entscheidend, verfügbare Ressourcen nur auf das einzusetzen, was tatsächlich gefordert wurde.

Immer wenn du Features oder andere Entwicklungsartefakte findest, die sich nicht auf eine Anforderung zurückführen lassen, hat dein Team entweder Hellseherqualitäten für zukünftige Feature-Anfragen — oder ihr verschwendet wertvolle Ressourcen.

Betrachte im Beispiel „Testfall 2": Er ist mit „Impl. 2" verknüpft, was sinnvoll erscheint — jedoch ist „Impl. 2" mit keiner internen Anforderung verbunden und lässt sich damit auch keiner Kundenanforderung zuordnen. Das Feature wurde nie vom Kunden gefordert.

Beachte dabei: Nicht jeder solche Befund bedeutet zwingend „unnötig". Deine Erkenntnisse können auch darauf hinweisen, dass die Anforderungen unvollständig sind — wichtige Aspekte des Produkts wurden bei der Anforderungserhebung übersehen oder unterschätzt.

Frage 3: Was ist der Auswirkungsbereich einer Änderung?

Anforderungen sind in den meisten Fällen nicht in Stein gemeißelt. Manchmal ändern Kunden ihre Meinung, die Marktsituation ändert sich oder neue Gesetzgebung muss berücksichtigt werden.

Anforderungsänderungen werden kommen. Und wenn sie kommen, entstehen wichtige Fragen:

1. Wie lange dauert es, die Änderung umzusetzen?
2. Wie teuer wird es sein?
3. Habe ich noch die richtigen Entwicklungsressourcen?

Um diese Fragen zu beantworten, müssen zunächst alle Artefakte gefunden werden, die mit den geänderten Anforderungen zusammenhängen. Besonders in großen Projekten mit Zehntausenden von Anforderungen und Artefakten ist das ohne ein Traceability-Tool kaum vollständig zu leisten.

Mit einem Satz Requirements Traceability Matrices sind alle Links von den geänderten Anforderungen bis zur letzten Codezeile erfasst. Nehmen wir an, „CustReq. 1" ändert sich: Aus der Matrix ist direkt ablesbar, dass „IntReq. 1" und „IntReq. 3" betroffen sind — beides mit getesteten Implementierungen verknüpft. Damit sind durch die Änderung einer einzigen Anforderung insgesamt sechs Entwicklungsartefakte betroffen.

Du musst den Auswirkungsbereich zwar noch für jedes einzelne Artefakt analysieren — aber du kannst sicher sein, das vollständige Bild vor dir zu haben.

Frage 4: Was ist der aktuelle Projektstatus?

Kunden und Stakeholder wollen über den Fortschritt informiert werden — und „es läuft gut" reicht nicht als Antwort. Die Traceability-Daten enthalten genau die Informationen, die nötig sind, um den aktuellen Projektstand schnell abzulesen. Wie viele Anforderungen gibt es insgesamt? Wie viele wurden implementiert und erfolgreich getestet? Eine einfache Iteration entlang der Traces in den RTMs liefert die Antworten.

Im aktuellen Stand des Beispiels ist „CustReq. 1" vollständig implementiert und getestet, für „CustReq. 2" wurden zumindest interne Anforderungen abgeleitet, und „CustReq. 3" wurde noch nicht angefasst. Die RTM liefert jederzeit verlässliche Statusinformationen.

Werden die Metriken regelmäßig gespeichert, lässt sich der Fortschritt — oder sein Ausbleiben — über die Zeit beobachten.

Frage 5: Was ist als Nächstes zu tun?

Eine der Herausforderungen im Projektmanagement ist es zu bestimmen, wann was zu tun ist. Ein wichtiger Aspekt dabei ist zu wissen, wie verschiedene Entwicklungsartefakte zusammenhängen und welche Abhängigkeiten zwischen ihnen bestehen. Die Kombination aus Priorität und Traceability gibt dir einen roten Faden.

Aus dem Beispiel lassen sich folgende Aufgaben ableiten:

Inkonsistenzen klären (Backward Traceability):

• „Impl. 2" und „Impl. 5" sind mit keiner internen Anforderung verknüpft. Welchen Zweck haben sie? → Klären und beheben.
• „IntReq. 4" ist mit keiner Kundenanforderung verknüpft. Welchen Zweck hat sie? → Klären und beheben.

Anforderungen nach Priorität erfüllen (Forward Traceability):

• Implementierung für „IntReq. 2" erstellen, dann passende Testfälle verknüpfen.
• Interne Anforderungen für „CustReq. 3" erstellen, dann Implementierung und Testfälle verknüpfen.

+1: Lässt sich Traceability langfristig aufrechterhalten?

Dies ist natürlich ein winziges Beispiel, das mit keinem realen Projekt vergleichbar ist. Dennoch zeigt es, wie ein einfaches Werkzeug wie eine in Excel gepflegte Requirements Traceability Matrix helfen kann, komplexe Beziehungen im Projekt besser zu verstehen, Arbeit effizienter zu verteilen und den Auswirkungsbereich von Änderungen zuverlässig einzuschätzen.

Aber Vorsicht: Traceability ist nur nützlich, wenn sie kontinuierlich gepflegt wird. Der dafür nötige Aufwand steigt mit der Projektgröße erheblich an. Mit der nötigen Disziplin zahlt sich dieser Aufwand aus — wie Forschungsergebnisse von Prof. Dr. Mäder eindrucksvoll zeigen. Deshalb ist es entscheidend, ein Werkzeug zu haben, das die Pflege der Traceability so einfach und komfortabel wie möglich macht: ein Traceability-Tool, das mit dem Projekt wächst.

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 →