Was ist Requirements Coverage und wie lässt sie sich analysieren?

Wer sich mit dem Begriff Requirements Coverage im Kontext der System- oder Softwareentwicklung beschäftigt, stößt schnell auf eine Ambivalenz: Einerseits lässt Requirements Coverage Interpretationsspielraum, weil der Begriff nicht einheitlich definiert ist. Andererseits fordern mehrere klar definierte Prozessstandards und Reifegradmodelle, dass Coverage gemessen werden muss — besonders in sicherheitskritischen Entwicklungen.

In diesem Artikel berichte ich über Erfahrungen, die wir gemacht haben, als wir mit dieser Ambivalenz konfrontiert wurden, und wie wir uns einer „anpassbaren Definition" des Begriffs Coverage genähert haben.

Bestehende Definitionen von „Requirements Coverage"

Schauen wir uns drei verschiedene Quellen für eine Definition des Begriffs Requirements Coverage an. Allen gemeinsam ist: Requirements Coverage bezeichnet die direkte Beziehung zwischen Anforderungen und Testfällen.

Eine Google-Suche liefert mehrere Definitionen, jedoch keine universelle. Die meisten sind an kommerzielle Anforderungsmanagement-Tools gebunden und damit tool-spezifisch. Gemeinsam haben sie: Eine Anforderung gilt als abgedeckt, wenn ihr mindestens ein Testfall zugeordnet ist.

Wikipedia liefert (zumindest auf Englisch und Deutsch) keine Definition von Requirements Coverage. Definiert wird hingegen Code Coverage als Maß dafür, „in welchem Grad der Quellcode ausgeführt wird, wenn eine Testsuite läuft."

Automotive SPICE ist ein Standard zur Bewertung der Prozessreife in der Entwicklung von Steuergeräten in der Automobilindustrie. Das A-SPICE Process Assessment Model nutzt das V-Modell und fordert, dass „die Auswahl der Testfälle eine ausreichende Abdeckung gewährleisten soll."

Requirements Coverage in der Praxis

Das Titelbild dieses Artikels veranschaulicht einen Entwicklungsprozess nach dem V-Modell.

(Kundentestfälle liegen in der Verantwortung des Kunden und werden hier nicht berücksichtigt.)

In einem konkreten Projekt forderte der Kunde regelmäßige Fortschrittsberichte auf Basis seiner Kundenanforderungen. Er wollte wissen, wie viele davon analysiert, implementiert und abgedeckt sind. Die Begriffe wurden durch Coverage-Metriken definiert:

• analysiert: durch High-Level-Anforderungen abgedeckt — eine Kundenanforderung muss mindestens eine High-Level-Anforderung zugeordnet haben.
• implementiert: tief durch Low-Level-Anforderungen abgedeckt — analysiert + alle abgeleiteten High-Level-Anforderungen sind durch Low-Level-Anforderungen abgedeckt.
• abgedeckt: tief durch Testfälle abgedeckt — implementiert + alle abgeleiteten Anforderungen sind durch Testfälle abgedeckt.

Zur Veranschaulichung zwei Beispiele:

Kundenanforderung Cust-Req 3 ist abgedeckt: High-Level-Anforderung HL-Req 11 und Low-Level-Anforderung LL-Req 18 sind abgeleitet, beide haben passende Testfälle zugeordnet (HL-Test g bzw. LL-Test d).

Kundenanforderung Cust-Req 2 ist nur analysiert — sie gilt nicht als implementiert, weil HL-Req 19 keine Low-Level-Anforderung hat.

Was haben wir aus diesem Projekt gelernt? Die Definition von Requirements Coverage als „direkte Beziehung zwischen Anforderungen und Testfällen" reicht nicht aus:

• Coverage ist nicht nur auf der gleichen Ebene des V-Modells relevant, sondern auch entlang des linken Astes.
• Es muss unterschieden werden zwischen direkter Coverage (die Standard-Definition) und tiefer oder transitiver Coverage, die Anforderungen nicht nur horizontal auf der gleichen Ebene verfolgt (linker zu rechtem Ast), sondern auch vertikal zwischen Ebenen (von einer höheren zu einer tieferen Ebene im linken Ast).

Unsere Definition von Coverage

Zusammengefasst definieren wir Coverage wie folgt:

Auf Basis dieser Definition:

• „Cust-Req 3 ist durch Low-Level-Tests abgedeckt."
• „Cust-Req 2 ist durch High-Level-Anforderungen abgedeckt."
• „Cust-Req 2 ist nicht durch Low-Level-Anforderungen abgedeckt."

Was diese Definition auslässt

Dieser Artikel ist eine vereinfachte Zusammenfassung mehrerer Projekterfahrungen. Folgende Aspekte wurden bewusst ausgeklammert:

• Das V-Modell hat in der Praxis meist mehr Ebenen.
• Testergebnisse wurden nicht berücksichtigt. Bezieht man sie ein, lässt sich zusätzlich analysieren, ob eine Anforderung verifiziert ist.
• Eigenschaften von Entwicklungsartefakten spielen eine Rolle: Eine Low-Level-Anforderung, die noch nicht „freigegeben" ist, darf bei der Coverage-Analyse nicht berücksichtigt werden. Manchmal können Anforderungen auch als „abgedeckt durch…" markiert werden, ohne direkte Links — z. B. auf Anweisung des Projektleiters.
• In manchen Projekten ist die Ableitung von Anforderungen auf der gleichen Ebene erlaubt. Das erfordert eine Unterscheidung zwischen aufgeteilten Anforderungen (Vorläufer gilt als abgedeckt, wenn alle Nachfolger abgedeckt sind) und abgeleiteten Anforderungen (Vorläufer und Nachfolger müssen beide direkt oder indirekt mit tieferen Ebenen verknüpft sein).
• Selbst innerhalb desselben Projekts führen unterschiedliche Rollen zu Homonymen: „High-Level-Anforderungen sind abgedeckt" bedeutet etwas anderes, je nachdem ob die aussagende Person für High-Level-Tests oder Low-Level-Anforderungen verantwortlich ist.

Unser Ansatz: Werkzeuggestützte Traceability

Automotive SPICE formuliert es so: „Bidirektionale Traceability unterstützt Coverage-, Konsistenz- und Auswirkungsanalysen."

Wer Requirements Coverage messen will oder muss, braucht zunächst Traceability. Aber wie lässt sich das effizient umsetzen?

Eine Traceability Matrix ist der verbreitete Einstiegsansatz — auf den ersten Blick machbar, aber nicht skalierbar. Eine Matrix mit n Dimensionen (eine pro V-Modell-Ebene) und Tausenden von Zeilen und Spalten wird schnell unwartbar.

Was gebraucht wird, ist ein dediziertes Traceability-Tool. Gute Traceability-Tools:

• erkennen Artefakte schnell, damit sie einfach verknüpft werden können,
• unterstützen den Benutzer beim Erstellen von Links durch effiziente Such- und Auswahlmechanismen,
• leiten Links idealerweise auf Basis von Ähnlichkeiten ab,
• extrahieren Links, die bereits in anderen Tools gepflegt wurden.

Das Wichtigste dabei: Die Auswertung von Trace-Daten muss so einfach wie möglich sein. Gesucht ist ein Tool mit:

• Statischem Reporting: Ad-hoc- und automatisierte Berichte in verschiedenen Formaten.
• Dynamischen Abfragen: Eine menschenlesbare Abfragesprache mit ausdrucksstarken Features zum Traversieren des Artefakt-Graphen — nutzbar ohne Kenntnisse der Graphentheorie.
• Datenexport: Export von rohen und voraggregrierten Trace-Daten nach Excel, in Datenbanken oder andere Formate zur Weiterverarbeitung.

Coverage-Analyse in der Praxis

Der folgende Screenshot zeigt ein Beispiel einer Traceability-Analyseperspektive. Oben eine dynamische Abfrage, darunter das Ergebnis:

Der nächste Screenshot zeigt dieselben Daten als Excel-Export zur weiteren Auswertung und Visualisierung:

Dieser Ansatz ermöglicht es, die oben beschriebenen Coverage-Fragen auch in großen Projekten mit komplexen V-Modell-Hierarchien effizient zu beantworten.

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 →