Zum Hauptinhalt springen

Requirements Coverage

Requirements Coverage (Anforderungsabdeckung) bezeichnet den Grad, zu dem Anforderungen durch andere Entwicklungsartefakte abgedeckt sind — typischerweise durch Testfälle. Eine Anforderung gilt als „abgedeckt", wenn sie direkt oder indirekt über Trace-Links mit mindestens einem Artefakt des Zieltyps verknüpft ist. Voraussetzung für die Messung ist deshalb Requirements Traceability.

Wie sich Coverage in der Praxis sinnvoll definieren und analysieren lässt, beschreibt unser Artikel Was ist Requirements Coverage und wie lässt sie sich analysieren?

Warum ist der Begriff nicht eindeutig?

Requirements Coverage ist nicht einheitlich definiert: Die meisten verfügbaren Definitionen sind an kommerzielle Anforderungsmanagement-Tools gebunden und beschränken sich auf die direkte Beziehung zwischen Anforderung und Testfall. Gleichzeitig fordern Prozessstandards wie Automotive SPICE, dass die Auswahl der Testfälle eine ausreichende Abdeckung gewährleistet — besonders in sicherheitskritischen Entwicklungen. In der Praxis muss die Coverage-Definition deshalb an den eigenen Entwicklungsprozess angepasst werden.

Direkte vs. transitive Coverage

Im Entwicklungsprozess nach dem V-Modell reicht die direkte Beziehung zwischen Anforderung und Testfall nicht aus:

  • Direkte Coverage: Eine Anforderung ist mit mindestens einem Testfall auf derselben Ebene verknüpft.
  • Transitive (tiefe) Coverage: Eine Anforderung gilt erst dann als abgedeckt, wenn auch alle daraus abgeleiteten Anforderungen tieferer Ebenen — rekursiv — abgedeckt sind. Eine Kundenanforderung ist also erst „durch Tests abgedeckt", wenn die gesamte Ableitungskette bis zu den Low-Level-Tests geschlossen ist.

So lassen sich abgestufte Fortschrittsaussagen treffen — etwa: eine Kundenanforderung ist analysiert (durch High-Level-Anforderungen abgedeckt), implementiert (tief durch Low-Level-Anforderungen abgedeckt) oder abgedeckt (tief durch Testfälle abgedeckt).

Coverage-Analyse in der Praxis

Der verbreitete Einstiegsansatz ist eine Traceability-Matrix — bei mehreren V-Modell-Ebenen und Tausenden Artefakten wird sie jedoch schnell unwartbar. Skalierbare Coverage-Analysen erfordern ein dediziertes Traceability-Tool mit dynamischen Abfragen über den Artefakt-Graphen. Mehr dazu auf unserer Seite Requirements Traceability.

Häufige Fragen

Was ist der Unterschied zwischen Requirements Coverage und Code Coverage?
Requirements Coverage misst, ob Anforderungen durch andere Artefakte — typischerweise Testfälle — abgedeckt sind. Code Coverage misst, in welchem Grad der Quellcode ausgeführt wird, wenn eine Testsuite läuft. Beide Metriken ergänzen sich, sind aber nicht austauschbar.
Was bedeutet direkte vs. transitive Coverage?
Direkte Coverage betrachtet nur unmittelbare Verknüpfungen, etwa Anforderung zu Testfall auf derselben V-Modell-Ebene. Transitive (tiefe) Coverage verfolgt Anforderungen zusätzlich vertikal über Ebenen hinweg: Eine Kundenanforderung gilt erst als abgedeckt, wenn auch alle daraus abgeleiteten Anforderungen abgedeckt sind.
Warum ist Requirements Coverage ein Fortschrittsindikator?
Fehlende Verknüpfungen zeigen offene Arbeitsschritte: Eine Anforderung ohne Testfall wurde wahrscheinlich nicht getestet oder noch nicht umgesetzt. Coverage-Metriken machen den Projektfortschritt damit auf Anforderungsebene messbar — auf Basis echter Daten statt Annahmen.

Verwandte Begriffe

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