Zum Hauptinhalt springen

Requirements Traceability

Requirements Traceability (Anforderungs-Nachverfolgbarkeit) ist die Fähigkeit, jede Anforderung von ihrem Ursprung über Architektur, Implementierung und Tests bis zur Validierung nachzuverfolgen — und zwar in beide Richtungen. Grundlage sind Trace-Links: gerichtete Verknüpfungen zwischen Entwicklungsartefakten wie „Anforderung wird verifiziert durch Testfall" oder „Anforderung wird erfüllt durch Komponente".

Eine ausführliche Einführung mit Nutzen, Analysearten und Praxisherausforderungen bietet unser Artikel Was ist Traceability? Nutzen und Herausforderungen in der Softwareentwicklung.

Warum ist Requirements Traceability gefordert?

Normen und Reifegradmodelle für regulierte Branchen machen Traceability zum Pflichtbestandteil des Entwicklungsprozesses: ISO 26262 und IEC 61508 für Functional Safety, ISO/SAE 21434 und IEC 62443 für Cyber Security, der Cyber Resilience Act für vernetzte Produkte. Automotive SPICE setzt bidirektionale Traceability als Basispraktik voraus. Ohne nachvollziehbare Beziehungen zwischen Anforderungen, Implementierung und Tests lassen sich Compliance-Nachweise nicht auditierbar erbringen.

Was leistet Traceability über Compliance hinaus?

Trace-Links strukturieren Projektdaten als Graph und ermöglichen zwei zentrale Analysekategorien:

  • Impact-Analyse: Was ist verknüpft? Bei einer Anforderungsänderung zeigt sie, welche Komponenten, Testfälle und Nachweise betroffen sind.
  • Coverage-Analyse: Was ist nicht verknüpft? Eine Anforderung ohne zugeordneten Testfall wurde wahrscheinlich nicht getestet — fehlende Links sind ein zuverlässiger Indikator für offene Arbeitsschritte und den Projektfortschritt. Mehr dazu unter Requirements Coverage.

Der bekannteste Einstiegsansatz ist die Traceability-Matrix — eine Tabelle, die Artefakte über eindeutige IDs zueinander in Beziehung setzt.

Die Herausforderung: Werkzeuggrenzen

In der Praxis scheitert Traceability häufig an fragmentierten Tool-Landschaften: Anforderungen liegen in DOORS oder Polarion, Architekturmodelle entstehen in MBSE-Werkzeugen, Entwicklung läuft in GitLab, Tests werden separat verwaltet. Zwischen diesen Systemen entstehen Lücken, in denen Nachvollziehbarkeit verloren geht. Durchgängige Traceability über Werkzeuggrenzen hinweg erfordert deshalb eine integrierende Traceability-Schicht — und ein Traceability Information Model (TIM), das definiert, welche Artefakte miteinander verbunden sein müssen.

Wie durchgängige, auditierbare Traceability in regulierten Projekten aufgebaut wird, beschreibt unsere Seite Requirements Traceability.

Häufige Fragen

Was bedeutet bidirektionale Traceability?
Trace-Links lassen sich in beide Richtungen auswerten: Forward Traceability folgt einer Anforderung bis zu ihrer Validierung, Backward Traceability führt von einem Testfall oder Code-Fragment zurück zur auslösenden Anforderung. Standards wie Automotive SPICE fordern beide Richtungen als Basispraktik.
Welche Normen fordern Requirements Traceability?
Unter anderem ISO 26262, IEC 61508, ISO/SAE 21434, IEC 62443 und der Cyber Resilience Act fordern nachvollziehbare Beziehungen zwischen Anforderungen, Implementierung, Tests und Validierung. ASPICE setzt bidirektionale Traceability als Basispraktik voraus.
Woran scheitert Traceability in der Praxis am häufigsten?
An fragmentierten Tool-Landschaften: Anforderungen liegen in DOORS oder Polarion, Architekturmodelle in MBSE-Werkzeugen, Code in GitLab, Tests werden separat verwaltet. Zwischen diesen Systemen entstehen Lücken, in denen Nachvollziehbarkeit verloren geht.

Verwandte Begriffe

Fachlich geprüft von Florian Antony, Principal Software Engineer & IT Consultant am 20. Juli 2026