Eine Traceability Matrix ist eine Tabelle, die jede Anforderung mit den Testfällen, Testläufen und Defekten verknüpft, die ihre Umsetzung nachweisen. Sie beantwortet die zwei Fragen, die in jedem Audit gestellt werden: Ist jede Anforderung getestet? Und zu welcher Anforderung gehört dieser fehlgeschlagene Test? In regulierten Branchen ist diese Verknüpfung Pflicht, bei Banken genauso wie in der Medizintechnik. Der Begriff selbst steht in keiner Norm als verbindliche Vorlage. Welche Spalten Sie brauchen, hängt vom Prüfzweck ab.

Kurz gefasst: Eine Traceability Matrix verknüpft Anforderung, Testfall, Testergebnis und Defekt in einer Tabelle. Kein Normungsgremium gibt eine verbindliche Spaltenvorlage vor. Regulatoren verlangen die Verknüpfung trotzdem: DORA Art. 24(6) fordert von Finanzunternehmen mindestens jährliche Tests aller Systeme, die kritische Funktionen stützen.

Abbildung 1: Die Traceability-Kette von der Anforderung bis zum Defekt, in beide Richtungen lesbar.

Was ist eine Traceability Matrix?

Eine Traceability Matrix ist die tabellarische Darstellung der Beziehungen zwischen Anforderungen und den Artefakten, die ihre Erfüllung belegen. Das ISTQB definiert Verfolgbarkeit als „die Fähigkeit, zusammengehörige Teile von Dokumentation und Software zu identifizieren, insbesondere die Anforderungen mit den dazu gehörigen Testfällen“ (ISTQB/GTB Standardglossar V3.4, 2022).

Heisst es Verfolgbarkeit oder Rückverfolgbarkeit?

Beide Begriffe sind im DACH-Raum gebräuchlich. Das aktuelle ISTQB-Glossar führt „Verfolgbarkeit“ als Stichwort und beschreibt sie als „den Grad, zu dem eine Beziehung zwischen zwei oder mehr Arbeitsergebnissen hergestellt werden kann“ (ISTQB-Glossar). „Rückverfolgbarkeit von Anforderungen“ meint in der Praxis dieselbe Sache und taucht in Auditberichten häufiger auf.

ISO/IEC/IEEE 24765:2017 beschreibt Traceability als unterscheidbare Verbindung zwischen zwei oder mehr logischen Einheiten, etwa Anforderungen, Systemelementen, Verifikationen und Aufgaben (zitiert nach t2informatik). Für die Testarbeit heisst das: eine Anforderung ohne verknüpften Testfall ist eine Lücke, und die Matrix macht sie sichtbar.

Was gehört in eine Traceability Matrix?

Kein Normungsgremium veröffentlicht eine verbindliche Spaltenvorlage für die Rückverfolgbarkeit von Anforderungen. Weder ISO/IEC/IEEE 29119-3:2021 noch die FDA noch das ISTQB geben ein kanonisches Muster vor. Jede Vorlage, die Ihnen als „die richtige“ verkauft wird, ist eine Konvention, keine Norm. Der Zuschnitt hängt von Branche, Norm und Auditzweck ab.

Abbildung 2: Die sechs Kernspalten mit drei Beispielzeilen. Die letzte Zeile hat keinen Testfall.

In der Praxis hat sich ein Minimalsatz herausgebildet, der für Testmanagement in fast jedem Kontext trägt:

• Anforderungs-ID: eindeutig, stabil, versionierbar

• Anforderungsbeschreibung: eine Zeile, prüfbar formuliert

• Testfall-ID: eine oder mehrere pro Anforderung

• Teststatus: bestanden, fehlgeschlagen, blockiert, nicht ausgeführt

• Defekt-ID: die Verknüpfung zum Fehlerticket

• Abdeckungsstatus: der abgeleitete Gesamtwert je Anforderung

Wer mehr Tiefe braucht, ergänzt Quelle der Anforderung, Designelement und Verifikationsmethode. Jama Software zeigt für eine Infusionspumpe ein achtspaltiges Beispiel in dieser Form (Jama Software).

Ein Beispiel aus der Zahlungsfreigabe

Die letzte Zeile ist der Grund, warum die Matrix existiert. REQ-PAY-005 hat keinen Testfall. Ohne die Tabelle fällt das erst im Audit auf. Wie Sie solche Ketten in Jira sauber aufbauen, zeigt unser Beitrag zu Anforderungen und Tests mit Xray in Jira.

Was bedeuten vorwärts, rückwärts und bidirektional?

Vorwärtsverfolgbarkeit führt von der Anforderung zu Design, Code und Test, Rückwärtsverfolgbarkeit vom Artefakt zurück zur Anforderung, die es begründet. Microsoft formuliert es in der Azure-DevOps-Dokumentation so: „Requirements traceability is the ability to relate and document two or more phases of a development process, which can then be traced both forward or backward from its origin.“ (Microsoft Learn, 2026).

Gotel und Finkelstein haben diese Doppelrichtung 1994 auf der ersten IEEE-Konferenz zu Requirements Engineering eingeführt und Anforderungsverfolgbarkeit sinngemäss als die Fähigkeit beschrieben, das Leben einer Anforderung vorwärts und rückwärts zu verfolgen.

• Vorwärts: Anforderung → Testfall → Testlauf. Beantwortet: Ist alles getestet, was gefordert war?

• Rückwärts: Defekt → Testfall → Anforderung. Beantwortet: Welche Fachanforderung ist von diesem Fehler betroffen?

• Bidirektional: beide Richtungen gleichzeitig gepflegt. Genau das verlangen die Sicherheitsnormen.

Welche Regularien verlangen Rückverfolgbarkeit?

Rückverfolgbarkeit ist in mindestens fünf Regelwerken eine Prüfanforderung, und das Finanzwesen gehört dazu. Wichtig für die Genauigkeit: DORA verwendet den Begriff Traceability Matrix nirgends und schreibt keine Matrix vor. Die Verordnung (EU) 2022/2554 verlangt in Art. 24(5) von Finanzunternehmen ausserhalb der Kleinstunternehmen Verfahren und Leitlinien, im englischen Verordnungstext: „prioritise, classify and remedy all issues revealed throughout the performance of the tests“. Dazu kommen interne Prüfmethoden, die bestätigen, dass alle festgestellten Schwächen, Mängel und Lücken vollständig behoben sind (EUR-Lex, Verordnung (EU) 2022/2554, 2022). Art. 24(6) fordert von denselben Unternehmen mindestens jährliche Tests aller ICT-Systeme und Anwendungen, die kritische oder wichtige Funktionen stützen.

Abbildung 3: Sechs Regelwerke verlangen Verfolgbarkeit. DORA nennt den Begriff Matrix nicht.

Art. 24(5) ist der stärkste Anknüpfungspunkt. Jeden im Test gefundenen Mangel zu priorisieren, zu klassifizieren, zu beheben und die Behebung nachzuweisen setzt genau die Verknüpfung zwischen Anforderung, Testlauf und Defekt voraus, die ein lebender Verfolgbarkeitsbericht liefert.

Der EU-GMP-Leitfaden ist an dieser Stelle knapp und eindeutig: „User requirements should be traceable throughout the life-cycle“ (Annex 11, Abschnitt 4.4, wiedergegeben von der ECA Academy). Die FDA hat ihre finale Leitlinie zu Computer Software Assurance am 24. September 2025 im Federal Register angekündigt (Federal Register, Docket FDA-2022-D-0795).

Bei IEC 62304, DO-178C und ISO 26262 ist Vorsicht bei Klauselnummern angebracht. IEC 62304 wird üblicherweise mit Unterabschnitt 5.1.1(c) zitiert, die Primärtexte sind kostenpflichtig und die Nummern in Sekundärquellen nicht durchgängig geprüft. Mehr dazu in unserem Überblick zum Testen in regulierten Branchen und im Beitrag zu GxP-Testing und Computer System Validation.

Warum veralten manuell gepflegte Matrizen?

Manuell gepflegte Traceability-Matrizen veralten, weil jede Änderung an Anforderung, Testfall oder Ticket eine Handbewegung in einer zweiten Datei erfordert, die niemandem gehört. Jane Cleland-Huang beschreibt in ihrer Übersichtsarbeit auf der ICSE FOSE 2014 sinngemäss, dass die Kosten für Aufbau und Pflege von Trace-Links hoch sind und die Verknüpfungsstruktur über die Lebensdauer eines Systems erodiert, weil Links nach Änderungen nicht nachgezogen werden.

Ruiz, Hu und Dalpiaz kommen 2023 in der Zeitschrift Requirements Engineering zu einem ähnlichen Befund. Ihre Untersuchung mit 55 Umfrageteilnehmenden und 14 Interviews beschreibt Verfolgbarkeit sinngemäss als eine gewünschte, in der Praxis aber schwer erreichbare Eigenschaft softwareintensiver Systeme, trotz jahrzehntelanger Werkzeugforschung.

Eine Zahl dazu gibt es nicht. Uns ist keine Studie bekannt, die misst, wie schnell eine Excel-Matrix veraltet, und wir erfinden keine. Das Argument bleibt qualitativ: Eine Matrix, die jemand von Hand nachführt, zeigt den Stand des letzten Pflegetermins, nicht den Stand des letzten Testlaufs.

Wie erzeugen Werkzeuge die Matrix automatisch?

Moderne Werkzeuge erzeugen die Matrix als Bericht zur Abfragezeit aus verknüpften Objekten, statt sie als Dokument zu führen. Xrays Requirement Traceability Report „enables you to follow the life of a Requirement in both forward and backward directions“ und zeigt Anforderungen über Tests, Testläufe und Defekte hinweg (Xray-Dokumentation).

Abbildung 4: In fünf Schritten entsteht die Kette, aus der das Werkzeug den Bericht erzeugt.

Azure DevOps verknüpft Testergebnisse automatisch mit Work Items und zeigt im Widget „Requirements quality“ Pass-Rate und Anzahl fehlgeschlagener Tests je Anforderung, einschliesslich der Anforderungen ohne zugeordneten Test (Microsoft Learn, 2026). Polarion von Siemens bringt Verfolgbarkeitsfelder mit und vergibt in LiveDocs absatzgenaue IDs für den ReqIF-Austausch; Siemens empfiehlt, Verfolgbarkeit in die Definition of Done aufzunehmen (Siemens). codebeamer von PTC rendert „Traceability Matrix“ und „Traceability Browser“ live zwischen Tracker-Typen (PTC).

So entsteht die Kette in der Praxis:

1. Anforderung als Work Item mit eindeutiger, stabiler ID anlegen.

2. Testfall mit dieser Anforderung verknüpfen, nicht nur im Titel referenzieren.

3. Automatisierte Testläufe an den Testfall zurückmelden, mit Zeitstempel und Build.

4. Defekte mit dem fehlgeschlagenen Lauf verknüpfen, nicht mit dem Testfall allein.

5. Den Bericht zum Prüfzeitpunkt erzeugen und als Nachweis archivieren.

Schritt 3 ist der Punkt, an dem Automatisierung ansetzt. Autemos ist eine Ausführungsengine und kein Testmanagement-Werkzeug: Die Tests laufen dort, die Ergebnisse fliessen über die Jira/Xray-Integration in die Managementebene zurück, wo die Matrix entsteht. In Kundenprojekten sehen wir, dass diese Rückmeldung der Punkt ist, an dem Traceability entweder funktioniert oder auseinanderfällt. Wie Sie diese Übergaben modellieren, zeigen die Test-Workflows in Autemos; zur Aufbewahrung der Nachweise passt der Beitrag zum Audit Trail im Testing.

Häufig gestellte Fragen

Ist eine Traceability Matrix gesetzlich vorgeschrieben?

Die Matrix als Dokumentform ist nirgends vorgeschrieben, die Rückverfolgbarkeit selbst schon. EU-GMP Annex 11 Abschnitt 4.4 verlangt, dass Benutzeranforderungen über den Lebenszyklus verfolgbar bleiben; IEC 62304, DO-178C und ISO 26262 verlangen Verfolgbarkeit für sicherheitsrelevante Software. DORA nennt den Begriff Matrix nicht.

Wie viele Spalten braucht eine Traceability Matrix?

So viele, wie der Prüfzweck verlangt. Sechs Spalten (Anforderungs-ID, Beschreibung, Testfall-ID, Teststatus, Defekt-ID, Abdeckungsstatus) tragen die meisten Projekte. Sicherheitsnormen verlangen zusätzliche Ebenen wie Designelement und Risikokontrollmassnahme. Eine kanonische Vorlage eines Normungsgremiums existiert nicht.

Was ist der Unterschied zwischen Testabdeckung und Traceability?

Testabdeckung misst einen Anteil, Traceability zeigt eine Verbindung. Eine Anforderung kann verknüpft und trotzdem unzureichend getestet sein. Die Matrix beantwortet, ob eine Verknüpfung existiert; die Testabdeckung beantwortet, wie gründlich getestet wurde.

Reicht Excel für eine Traceability Matrix?

Für ein kleines, abgeschlossenes Projekt ja. Sobald Anforderungen, Testfälle und Tickets sich wöchentlich ändern, zeigt die Datei den Stand der letzten manuellen Pflege. Werkzeuge wie Xray, Azure DevOps, Polarion und codebeamer erzeugen dieselbe Sicht live aus verknüpften Objekten.

Wer pflegt die Traceability Matrix im Team?

In einem verknüpften Setup pflegt sie niemand als Dokument. Die Verantwortung liegt bei den Rollen, die Objekte anlegen: Product Owner für Anforderungs-IDs, Testmanagement für die Testfallverknüpfung, die Pipeline für Testläufe. Mehr dazu in unserem Leitfaden zum Testmanagement.

Fazit

Rückverfolgbarkeit verbindet Anforderung, Testfall, Ergebnis und Defekt und macht Lücken sichtbar, bevor ein Prüfer sie findet. Die Spalten sind Konvention, die Verknüpfung ist Pflicht: EU-GMP Annex 11 Abschnitt 4.4 verlangt Verfolgbarkeit über den Lebenszyklus, DORA Art. 24(6) mindestens jährliche Tests kritischer Systeme, und die Sicherheitsnormen der Medizintechnik, Luftfahrt und Automobilindustrie verlangen beide Richtungen. Die Herstellung gehört ins Werkzeug: Der Bericht entsteht zur Abfragezeit aus verknüpften Objekten und zeigt damit den Stand des letzten Testlaufs. Wie die Ergebnisse aus automatisierten Läufen zurück in die Managementebene kommen, zeigt der Beitrag zum Testreporting.

Sie wollen Ihre Testergebnisse sauber an Anforderungen zurückbinden? Sprechen Sie mit uns.