Requirements Traceability Matrix (RTM): Vorlage + Beispiele

Eine Requirements Traceability Matrix (RTM), auf Deutsch Anforderungs-Rückverfolgbarkeitsmatrix, ist eine Tabelle, die jede Anforderung mit den Testfällen verknüpft, die sie prüfen, dazu mit deren letzten Ergebnissen, offenen Fehlern und den Nachweisen hinter jedem Ergebnis. Sie zeigt auf einen Blick, welche Anforderungen bestanden haben, welche fehlgeschlagen sind und welche noch gar keinen Test haben.

Du brauchst eine, wenn ein Vertrag, ein Audit oder ein Product Owner fragt: „Sind wir für Release 3.4 abgedeckt?“ Sie gehört zu den zentralen Dokumenten im QA-Testing. Unten bekommst du eine Vorlage, ein ausgefülltes Beispiel, Formeln, die Lücken finden, und Nachweise, die ein Auditor prüfen kann.

Was ist eine Requirements Traceability Matrix?

Eine Requirements Traceability Matrix ist eine Abdeckungstabelle: eine Zeile pro Anforderung, mit Spalten für ihre Tests, Ergebnisse, Fehler und Nachweise. Das ISTQB-Glossar beschreibt eine Verfolgbarkeitsmatrix als Matrix, die Arbeitsergebnisse miteinander in Beziehung setzt, „um die erreichte Überdeckung zu bestimmen“. Verfolgbarkeit (englisch Traceability) selbst ist die Fähigkeit, explizite Beziehungen zwischen zusammengehörigen Arbeitsergebnissen herzustellen, etwa zwischen einer Anforderung und ihrem Test.

Eine RTM im Testing beantwortet drei Fragen: Ist jede Anforderung getestet, was hat auf welchem Build bestanden, und was geht kaputt, wenn sich eine Anforderung ändert?

• Sie findet ungetestete Anforderungen, bevor ein Kunde es tut.
• Sie zeigt, was eine Änderung kaputt macht, denn jeder verknüpfte Test muss erneut laufen.
• Sie ordnet jeden Fehler einer Anforderung zu.
• Sie liefert Auditoren Belege: ein Ergebnis plus die Datei dahinter.

Bei Verträgen, Audits und regulierter Software wird eine erwartet, zum Beispiel nach den General Principles of Software Validation der FDA (2002) für Software in Medizinprodukten, nach IEC 62304, nach ISO 26262 im Automobilbau und nach DO-178C in der Luftfahrt. Für Testtools und Software des Qualitätsmanagementsystems gilt stattdessen die FDA-Leitlinie Computer Software Assurance. Das Format gibt dein Qualitätsmanagementsystem vor, und die Matrix allein beweist noch keine Konformität.

Meist ist ein QA-Lead oder Business Analyst für die RTM verantwortlich. Im Projektmanagement verfolgt eine Traceability-Matrix mit derselben Tabelle Anforderungen bis zu den Liefergegenständen statt bis zu Tests.

Arten der Rückverfolgbarkeit: vorwärts, rückwärts und bidirektional

Es gibt drei Arten der Rückverfolgbarkeit, und eine einzige Tabelle deckt alle drei ab.

Ein Test ohne Verknüpfung kann ein Regressions- oder Sicherheitstest sein, also halte seine Quelle fest, statt ihn zu löschen. Führe eine Tabelle mit zwei Filteransichten: nach Anforderung und nach Test.

Wo eine RTM zwischen den Testdokumenten steht

Die RTM steht über dem Testplan und den Testfällen und verknüpft beide zurück mit den Anforderungen.

Alle drei sind technische Dokumente, die QA-Teams pflegen, und die Endekriterien eines Testplans verlangen oft „keine Zeilen mit Not covered“.

Vorlage für die Requirements Traceability Matrix (zum Kopieren)

Kopier diese RTM-Vorlage als Markdown für ein Repo oder Wiki oder als CSV für Google Sheets und Excel.

| Anforderungs-ID | Beschreibung | Quelle | Priorität | Testfall-IDs | Status | Fehler-IDs | Nachweis-Link |
| --- | --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |

Speichere die CSV unten als rtm.csv und importiere sie dann in Google Sheets über Datei > Importieren > Hochladen oder in Excel über Daten > Aus Text/CSV.

Anforderungs-ID,Beschreibung,Quelle,Priorität,Testfall-IDs,Status,Fehler-IDs,Nachweis-Link
REQ-002,"Abgelehnte Karte zeigt eine Meldung zum erneuten Versuch, Rechnung bleibt unbezahlt",PRD-12 Abschn. 2.3,Hoch,"TC-103, TC-104",Fail,BUG-418,evidence/3.4/REQ-002_TC-103_3.4.0-rc2_fail_2026-10-27.gif

So füllst du die Spalten aus:

Leg die Spalte Status als Dropdown mit fünf Werten an: Not covered (nicht abgedeckt), Not run (nicht ausgeführt), Pass (bestanden), Fail (fehlgeschlagen) und Blocked (blockiert). (Im Layout mit zwei Blättern weiter unten wird daraus eine Formel.) Die Formeln weiter unten prüfen genau diese englischen Werte. Wenn du deutsche Werte verwendest, passe die Texte in den Formeln entsprechend an. Setz eine Zeile nur dann auf Pass, wenn jeder verknüpfte Test auf dem Ziel-Build bestanden hat und kein verknüpfter Fehler mehr offen ist.

Optionale Spalten: Build der Verifizierung, Owner, Verifizierungsmethode (Test, Inspektion, Analyse oder ein automatischer visueller Diff aus dem Visual Regression Testing) und eine Design-Referenz, die vorwärts in dein Software-Design-Dokument führt.

Beispiel für eine Requirements Traceability Matrix

Hier ist eine ausgefüllte Software Requirements Traceability Matrix für Release 3.4 einer Demo-App für B2B-Rechnungsstellung, getestet auf Build 3.4.0-rc2 (26. bis 30. Oktober) und rc3 (2. November).

Der Nachweis für REQ-007 ist ein Ergebnis aus dem Kontrast-Checker plus ein Screenshot des Farbpaars. WCAG 2.2 AA verlangt 4,5:1 für normalen Text und 3:1 für großen Text und UI-Komponenten, und ein kostenloser Farbkontrast-Checker liefert dir das Verhältnis.

Die Rückwärtsprüfung findet TC-999, „Dark-Mode-Schalter“, ohne Anforderung. Der Product Owner ergänzt eine Anforderung oder legt den Test still.

Fünf Aufgaben bleiben offen: BUG-418 beheben und TC-103 erneut ausführen, die E-Mail-Sandbox wiederherstellen, TC-201 aktualisieren, den CSV-Export testen (oder aus 3.4 streichen) und TC-999 verknüpfen oder stilllegen.

Dann berichtest du zwei Zahlen. Die Zuordnungsabdeckung liegt bei 6 von 7 (86 %), weil sechs Anforderungen einen Test haben. Die verifizierte Abdeckung liegt bei 3 von 7 (43 %), weil nur drei auf rc3 mit Nachweis bestanden haben.

Eine hohe Zuordnungsabdeckung kann verschleiern, dass ein Release noch nicht fertig ist.

So erstellst du eine RTM in Excel oder Google Sheets (6 Schritte)

In sechs Schritten wird aus einem leeren Blatt eine funktionierende RTM-Vorlage in Excel oder Google Sheets.

1. Anforderungen mit stabilen IDs sammeln. Nutze User Stories oder bei riskanten Stories die Akzeptanzkriterien, mit einer Zeile pro Kriterium. Ergänze die nicht-funktionalen Zeilen, die Teams gern vergessen, etwa Sicherheit und Barrierefreiheit.

2. Ein Layout wählen. Für kleine Releases reicht ein Tabellenblatt: Tipp die Test-IDs in Spalte E ein. Für größere legst du ein zweites Blatt namens Tests an, mit einer Zeile pro Paar aus Test und Anforderung (A Test-ID, B Titel, C Anforderungs-ID, D Ergebnis, E Build).

3. Die Formeln einfügen. Sie nutzen Funktionen, die es in Google Sheets und in Excel gibt. FILTER braucht Google Sheets oder Excel 2021 oder neuer (einschließlich Microsoft 365), und TEXTJOIN (im deutschen Excel TEXTVERKETTEN) braucht Excel 2019 oder neuer.

Die Formeln stehen hier mit englischen Funktionsnamen und Kommas. In einem deutschen Excel heißen die Funktionen anders (etwa WENN statt IF und ZÄHLENWENN statt COUNTIF), und du trennst die Argumente mit Semikolons. Google Sheets mit deutschem Gebietsschema erwartet ebenfalls Semikolons.

Lücken-Markierung (Layout mit einem Blatt, in einer Hilfsspalte neben Status):

=IF(TRIM(E2)="","Not covered","")

Verwaister Test (Blatt Tests, Spalte F):

=IF(OR(TRIM(C2)="",COUNTIF(RTM!A:A,C2)=0),"Orphan test","")

Gesamtstatus (Spalte F im Blatt RTM beim Layout mit zwei Blättern; Zelle K1 enthält den Ziel-Build, etwa 3.4.0-rc3):

=IF(COUNTIF(Tests!C:C,A2)=0,"Not covered",IF(COUNTIFS(Tests!C:C,A2,Tests!D:D,"Fail")>0,"Fail",IF(COUNTIFS(Tests!C:C,A2,Tests!D:D,"Blocked")>0,"Blocked",IF(COUNTIFS(Tests!C:C,A2,Tests!D:D,"Pass",Tests!E:E,$K$1)=COUNTIF(Tests!C:C,A2),"Pass","Not run"))))

Ein leeres, vertipptes oder auf einem alten Build erzieltes Ergebnis führt im Gesamtstatus zu Not run, nie zu Pass. Die Formel liest nur Ergebnisse, also prüf die verknüpften Fehler, bevor du ein Pass akzeptierst, oder ergänze eine Spalte für den Fehlerstatus.

Test-IDs (Spalte E im Blatt RTM beim Layout mit zwei Blättern):

=IFERROR(TEXTJOIN(", ",TRUE,FILTER(Tests!A:A,Tests!C:C=A2)),"")

Abdeckung (zuerst zugeordnet, dann verifiziert; formatiere beide als Prozent):

=1-COUNTIF(F2:F200,"Not covered")/COUNTA(A2:A200)
=COUNTIF(F2:F200,"Pass")/COUNTA(A2:A200)

4. Dropdown und Farben ergänzen. Bei zwei Blättern kommt das Dropdown mit Pass, Fail, Blocked und Not run in die Spalte Ergebnis im Blatt Tests, denn der Status im Blatt RTM ist eine Formel. Bei einem Blatt kommt es in die Spalte Status.

Färbe Fail rot, Blocked gelb und Not covered grau. Sieh dir dazu die Google-Hilfe zu Dropdowns und bedingter Formatierung an oder die Excel-Hilfe zu Dropdownlisten und bedingter Formatierung.

5. Drei Filteransichten speichern: Not covered, Fail oder Blocked und Pass ohne Nachweis.

6. Einen Owner und Auslöser für Updates festlegen. Aktualisiere die Tabelle, wenn sich eine Anforderung ändert, ein Test hinzukommt oder stillgelegt wird, ein Fehler geöffnet oder geschlossen wird oder ein Release-Build bereitsteht. Speichere bei der Abnahme einen datierten PDF- oder CSV-Export oder einen langen, scrollenden Screenshot der Tabelle (auf dem Mac oder unter Windows).

Eine scrollende Aufnahme folgt der Tabelle nur nach unten. Blende also zuerst Spalten aus oder mach sie schmaler (oder zoom heraus), bis die Tabelle in die Fensterbreite passt.

So bleibt sie aktuell, wenn sich eine Anforderung ändert

Wenn sich eine Anforderung ändert, aktualisierst du ihre Tests, führst sie erneut aus und behältst den alten Nachweis. Für REQ-004 (von 8 auf 12 Zeichen):

1. Aktualisiere TC-201, sodass er 12 Zeichen prüft.
2. Führe ihn auf 3.4.0-rc3 erneut aus.
3. Nimm einen neuen Nachweis auf und verlinke ihn in der Zeile.
4. Markiere die alte Datei mit 8 Zeichen als überholt und behalte sie.
5. Prüfe, ob die Release Notes die neue Regel erwähnen.

In agilen Teams sind die Zeilen Stories oder Akzeptanzkriterien, die du in jedem Sprint aktualisierst statt erst vor Audits. Baue sie aus Links im Tracker auf, nicht aus abgetippten IDs, und speichere pro Release einen datierten Snapshot.

Häufige Fehler bei der RTM

Diese acht Fehler machen die meisten Matrizen kaputt:

• IDs, die sich ändern oder wiederverwendet werden. Leg alte IDs stattdessen still.
• Drei Anforderungen in einer Zeile. Teil sie auf.
• Entwicklungsstatus in der Spalte Status. „In Review“ ist kein Ergebnis.
• Tests, die nur verknüpft werden, um die Abdeckung zu schönen. Verknüpf nur echte Prüfungen.
• Nachweise im Chat oder als schnelle Share-Links. Verlinke die Datei selbst.
• Keine Build-Nummer. Ein Pass auf rc1 sagt nichts über rc3.
• Echte Kundendaten in Screenshots. Nutze eingespielte Testdaten.
• Updates nur vor Audits. Nutze die Auslöser aus Schritt 6.

Von den Machern dieser Seite

Genug von langweiligen Screenshots? Probier ScreenSnap Pro.

Schöne Hintergründe, professionelle Anmerkungen, GIF-Aufnahme und sofortiges Teilen in der Cloud, alles in einer App. Einmal 39 $ zahlen, für immer besitzen.

Preis und Funktionen ansehen

So baust du eine RTM in Jira, Xray, TestRail oder Azure DevOps

Testtools pflegen diese Verknüpfungen für dich, sodass die Matrix zu einem Bericht wird.

• Jira. Eine Requirements Traceability Matrix in Jira beginnt mit Verknüpfungen. Verknüpfe jede Story über einen eigenen Verknüpfungstyp mit ihren Test-Arbeitselementen. Atlassian bietet eine RTM-Vorlage für Jira an, die auf Arbeitselementen für Anforderungen, Verknüpfungen und Dashboards aufbaut.
• Xray. Xray ergänzt die Arbeitselemente Test, Test Execution und Test Plan und gibt jeder Anforderung einen Abdeckungsstatus: OK, NOK, NOTRUN, UNKNOWN oder UNCOVERED. Der Requirement Traceability Report verfolgt Anforderungen über Tests, Testläufe und Fehler in beide Richtungen und exportiert als CSV.
• TestRail. Anforderungs-Keys trägst du im Feld References jedes Testfalls ein. Die Berichte Coverage for References (Cases), Comparison for References (Results) und Summary for References (Defects) zeigen Zuordnung, Ergebnisse und Bugs. Der Jira Coverage Check braucht eine aktive Jira-Requirements-Integration, findet Jira-Elemente ohne Tests und exportiert als CSV.
• Azure DevOps. In Azure Test Plans bleiben Tests, die du über das Board oder in anforderungsbasierten Suites hinzufügst, mit ihrer Anforderung verknüpft.
• Teams, die nur GitHub nutzen. Nimm ein Issue pro Anforderung, Test-IDs in den Testnamen und eine RTM als CSV im Repo. Ergänze im Issue-Formular ein Feld für die Anforderungs-ID (GitHub erzwingt Pflichtfelder nur in öffentlichen Repositorys).

Eine Tabelle funktioniert, solange eine Person sie aktuell hält. Sie kostet aber Pflegezeit, von Hand getippte IDs laufen auseinander, und zwischen Audits veraltet sie. Wechsle zu einem Tool, wenn sich mehrere Teams, Konfigurationen oder Releases Tests teilen. So oder so: Exportiere bei der Abnahme einen datierten Snapshot.

Den Kreis schließen: Testnachweise, die Auditoren öffnen können

Ein Pass in einer Zelle ist eine Behauptung, und der Nachweis-Link ist der Beweis.

Ein gültiger Nachweis-Link zeigt auf die Datei selbst (am Testlauf, am Ticket oder in einem Nachweisordner pro Release), die jede Person im Projekt ohne Chat-Zugriff öffnen kann. Wenn du die Datei an das Jira-Arbeitselement anhängst, liegt der Beweis direkt am Ticket. Der Share-Link eines Screenshot-Tools reicht für einen schnellen Blick, ist aber kein dauerhafter Beleg, also hat er in der Spalte Nachweis-Link nichts zu suchen.

Richte jeden Nachweis auf den Wert aus, der die Zeile belegt:

• REQ-001: ein finaler Screenshot mit nummerierten Markern passend zu den Schritten von TC-101, einem Callout an INV-1042 (Paid, $1,240.00) und Build 3.4.0-rc3 im Bild.
• REQ-002: die Aufnahme des Fehlschlags, verlinkt aus BUG-418 und aus der Zeile.
• REQ-005: die PDF-Summe neben der Summe auf dem Bildschirm: „Summe $1,240.00 stimmt mit dem PDF überein.“
• REQ-007: das Ergebnis des Kontrast-Checkers.
• Zeilen für API oder CLI: die Response oder eine Terminal-Aufnahme.

Bei einem Fehlschlag nimmst du 5 bis 15 Sekunden des Fehlers als Video auf, schneidest es zu und exportierst es als MP4 oder GIF. Eine direkte GIF-Aufnahme reicht, wenn nichts geschnitten werden muss (siehe GIF-Bildschirmaufnahme auf dem Mac oder unter Windows). Verlinke den Clip am Fehler und in der Zeile.

Tipp die Dateinamen von Hand ein, mit der REQ-ID vorne: REQ-002_TC-103_3.4.0-rc2_fail_2026-10-27.gif. Dann findet eine einzige Suche jeden Nachweis zu einer Anforderung. Capture-Tools benennen Dateien nach dem, was sie kennen, etwa Datum, App oder eine zufällige ID. Die REQ-ID musst du selbst ergänzen.

Behalte überholte Dateien: Der alte Nachweis mit 8 Zeichen für REQ-004 bleibt, als überholt markiert, neben der Datei von rc3 liegen.

Lass vor einem Audit den Filter „Pass ohne Nachweis“ laufen. Geh dann eine Zeile durch wie ein Auditor: Öffne den Link von REQ-005, vergleiche die Summen, gleiche den Build ab und prüfe, dass kein verknüpfter Fehler offen ist. Speichere bei der Abnahme den datierten Export aus Schritt 6.

Verdeck auf Screenshots Kartennummern, E-Mail-Adressen, Tokens sowie Patienten- und Kundendaten mit vollflächig gefüllten, undurchsichtigen Kästen, denn Weichzeichnen und Verpixeln lassen sich rückgängig machen (siehe den Guide zum Schwärzen von Text). Aufnahmen lassen sich später nur schwer schwärzen, also nimm nur eingespielte Testdaten auf, etwa eine Testkarte und einen Demo-Kunden. Halte Benachrichtigungen und andere Tabs aus dem Aufnahmebereich heraus und schneide lieber zu, statt weichzuzeichnen.

Kopier eine Fehlermeldung oder eine Anforderungs-ID aus einem Screenshot mit dem kostenlosen Tool zum Extrahieren von Text aus Bildern. Bei einer Spezifikation im PDF-Format machst du vorher einen Screenshot der Seite. Wie du Nachweise pro Testlauf aufnimmst, steht in der Testfall-Anleitung, die oben verlinkt ist.

In regulierten Teams kommen die Regeln für Aufbewahrung und elektronische Aufzeichnungen aus deinem Qualitätsmanagementsystem. Nachweise für die Freigabe im Abnahmetest (UAT) folgen demselben Prinzip.

Das Snipping Tool unter Windows und die Screenshot-Tools des Mac mit Markierungen erledigen einzelne Aufnahmen. Wenn du jeden Tag Nachweise ablegst, bündelt ScreenSnap Pro alles in einem Ablauf: Zähler-Nummern passend zu deinen Testschritten, deckende Kästen für Kartennummern und Tokens und die Scrolling Capture für einen langen Bericht hinter einem Login (Bereich auswählen, auf „Start Capture“ klicken, manuell nach unten scrollen, auf „Finish“ klicken).

Häufig gestellte Fragen

Wofür steht RTM beim Testen?

Beim Testen steht RTM für Requirements Traceability Matrix, auf Deutsch Anforderungs-Rückverfolgbarkeitsmatrix. Sie ist eine Tabelle, die jede Anforderung den Testfällen zuordnet, die sie prüfen, und dazu deren Ergebnisse, verknüpfte Fehler und Nachweise festhält. Tester belegen damit die Abdeckung und finden Anforderungen ohne Test.

Wofür steht RTM in der IT?

In der IT steht RTM meist für Requirements Traceability Matrix, die Abdeckungstabelle in Softwareprojekten. Es kann auch „Release to Manufacturing“ bedeuten, also die Phase, in der ein Software-Build final ist und an die Produktion übergeben wird. Was gemeint ist, ergibt sich aus dem Kontext.

Was ist eine Requirements Traceability Matrix (RTM)?

Eine RTM ist eine Tabelle mit einer Zeile pro Anforderung. Jede Zeile verweist auf die Tests, die diese Anforderung prüfen, auf das letzte Ergebnis auf dem Ziel-Build, auf offene Fehler und auf die Nachweisdatei. Sie zeigt, was bestanden hat, was fehlgeschlagen ist und was keinen Test hat.

Wie erstelle ich eine Requirements Traceability Matrix?

Liste deine Anforderungen mit stabilen IDs und Quellen auf. Ergänze Spalten für Testfall-IDs, Status, Fehler-IDs und einen Nachweis-Link. Ordne jeden Test seiner Anforderung zu, füg Formeln hinzu, die Lücken markieren, färbe den Status ein und aktualisiere die Tabelle, sobald sich etwas ändert.

Gibt es ein Beispiel für eine Requirements Traceability Matrix?

Ja: In einem Demo-Release einer Rechnungs-App besagt REQ-002, dass eine abgelehnte Karte eine Meldung zum erneuten Versuch zeigt. Die Zeile verweist auf TC-103 und TC-104. TC-103 ist auf Build 3.4.0-rc2 fehlgeschlagen, also zeigt die Zeile Fail, nennt den Bug BUG-418 und verlinkt ein GIF des Fehlschlags.

Was sind die Top 10 Tools für das Anforderungsmanagement?

Eine offizielle Top 10 gibt es nicht. Zu den Tools für das Anforderungsmanagement, die Teams für die Rückverfolgbarkeit nutzen, gehören Jama Connect, IBM DOORS Next, Siemens Polarion, Perforce ALM, PTC Codebeamer und Visure. Viele Softwareteams kombinieren stattdessen Jira oder Azure DevOps mit einem Testtool wie Xray, Zephyr oder TestRail. Entscheide nach deinen Audit-Anforderungen, nicht nach einem Ranking.

Was steht in einer Traceability-Matrix?

Eine Traceability-Matrix enthält Anforderungs-ID, Beschreibung, Quelle, Priorität, verknüpfte Testfall-IDs, einen Verifizierungsstatus, verknüpfte Fehler-IDs und einen Nachweis-Link. Optionale Spalten sind der Build, in dem verifiziert wurde, ein Owner, die Verifizierungsmethode und eine Design-Referenz.

Wo finde ich eine Vorlage für eine Traceability-Matrix?

Kopier die Vorlagen für Markdown und CSV aus diesem Guide in ein Repo, in Google Sheets oder in Excel. Testtools wie Xray und TestRail erstellen dieselbe Ansicht als Bericht, und Atlassian bietet eine Vorlage für Jira an. Starte mit einer Tabelle, wenn eine einzelne Person sie pflegt.

Fang mit den Anforderungen an, die am meisten wehtun würden

Wähl die Anforderungen aus, die am meisten wehtun würden, wenn sie kaputtgingen, etwa Zahlungen, Sicherheit und Vertragsbedingungen. Gib jeder davon einen Test, ein Ergebnis und eine Datei.

Wenn du jede Woche Testnachweise aufnimmst, erledigt ScreenSnap Pro die Aufnahme, die nummerierten Schritte und die deckenden Schwärzungskästen in einer App. Es ist ein einmaliger Kauf für 39 $: 1 Lizenz für 2 Computer (2 Aktivierungen, Mac oder Windows). Zu den Preisen.