Traceability - Peterjohann Consulting

Management-Zusammenfassung zu diesem Beitrag:
Traceability bezeichnet die Eigenschaft oder Fähigkeit der Nachvollziehbarkeit und ist ein essenzieller Bestandteil des Requirements Engineerings. Nur mit Traces besteht die Möglichkeit, (dauerhaft) die Verbindungen von Anforderungen darzustellen und zu nutzen.
In diesem Beitrag werden Traces beschrieben und der → Aufwand und der Nutzen erläutert.

Unter Traceability wird allgemein die Eigenschaft oder Fähigkeit der Nachvollziehbarkeit verstanden. “Traces” (zu Deutsch Spuren) sind Verbindungen zwischen Elementen eines Systems. Die Traceability ist ein wesentlicher Bestandteil des Systems oder Requirements Engineerings. Generell sollte ein System über Anforderungen vollständig beschrieben sein: Nur das, was in den Anforderungen steht, wird umgesetzt — das, was nicht in den Anforderungen steht, wird nicht umgesetzt. Anforderungen, die keine “Traces” besitzen, sollten nicht umgesetzt werden / sein.

Stichworte: Traceability, Traceability Graph, Trace-Netz, Traceability → Matrix, Requirements Traceability Matrix (RTM), Impact Analysis, Coverage Analysis
Synonyme: Nachvollziehbarkeit, Rückverfolgbarkeit, Verfolgbarkeit
Notwendiges Know-how: Gute Requirements-Engineering-Kenntnisse
Schwierigkeitsgrad: Mittel

Inhaltsverzeichnis Verbergen

1. Einleitung und Grundlagen
2. Horizontale und vertikale Traceability
3. Pre- and Post-Traceability
4. Der Einsatz von Traces / Traceability
5. Traces zwischen Anforderungen, Testfällen und Source Code
6. Varianten
7. Anmerkungen
8. Häufige Fragen und Antworten zur Traceability
A. Präsentationen, Literatur und Weblinks
- Ähnliche Beiträge

1. Einleitung und Grundlagen

In der Wikipedia steht zur Rückverfolgbarkeit /#Wiki-Traceability/:
“Rückverfolgbarkeit (auch Nachvollziehbarkeit oder engl. Requirements Traceability) bezeichnet in der System- und → Softwareentwicklung die Zuordenbarkeit von Anforderungen zu beliebigen Artefakten über den gesamten Entwicklungsprozess und ist somit Teil des Anforderungsmanagements.”

Das → IIBA definiert die Nachvollziehbarkeit wie folgt /BBG17‑d/:
“Nachvollziehbarkeit von Anforderungen (traceability of requirements): Fähigkeit, die Beziehungen zwischen Gruppen von Anforderungen vom ursprünglichen Bedarf des Stakeholders bis zur aktuell eingeführten Lösung zurückzuverfolgen. Die Nachvollziehbarkeit unterstützt die Überwachung von Änderungen, indem die Quelle einer Anforderung oder eines Designs identifiziert werden kann und andere verbundene Anforderungen und Designs, die von einer Änderung ebenfalls betroffen sein können, ersichtlich sind.”

Ebert beschreibt die Verfolgbarkeit /Ebert22/:
“Erkennbare Beziehung (engl. Traceability) zwischen zwei oder mehreren logischen Einheiten (Arbeitsergebnis) durch dokumentierte Identifikation.
Das Ziel der Verfolgbarkeit ist die Sicherstellung der Änderungskontrolle undder Konsistenz. Beispiel: Verfolgbarkeit von Kundenanforderungen zu
Testfällen. Bei der Verfolgbarkeit wird zwischen horizontaler und vertikaler Verfolgbarkeit unterschieden.”

Generell werden Anforderungen von ihrer Quelle bis zu ihrer Senke getract (siehe Abbildung 1.1). Für Anforderungen bedeutet dies zumeist eine Verfolgung vom Business- oder → Stakeholder-Level bis zur Umsetzung oder vom Gesamt-Produkt zum Einzelbestandteil.

Typischer Aufbau von Traces, (C) Peterjohann Consulting, 2018-2023

Abbildung 1.1: Typischer Aufbau von Traces

Über Traces kann im → Requirements Engineering sichergestellt werden, dass eine Ursprungsanforderung auch zu einer Umsetzung(sanforderung) führt.

1.1 Erfassung und Darstellung von Traces

Sollen Traces erfasst werden, so gibt es verschiedene Möglichkeiten, die generell entweder textuelle oder grafische Ansätze verwenden (Abbildung 1.2).

Erfassungs- und Darstellungsmöglichkeiten von Traces, (C) Peterjohann Consulting, 2020-2023

Abbildung 1.2: Erfassungs- und Darstellungsmöglichkeiten von Traces

In der Praxis werden häufig Requirements-Werkzeuge eingesetzt, bei denen Traces “textuell” erzeugt werden. Die erzeugten Traces können dann über Trace-Netze visualisiert werden.

1.2 Ein einfaches Modell zur Trace-Darstellung

In Abbildung 1.2 ist ein einfaches Modell dargestellt, welches sich an den Klassen (der IIBA und des → PMI) der Anforderungen orientiert. Es werden in diesem Beitrag folgende drei Klassen unterschieden:

Business Requirement, auch Geschäftsanforderung oder Business-Anforderung: Unter Business Requirements werden die übergeordneten High-Level-Anforderungen erfasst. Diese sind häufig abstrakt formuliert.
Buchstabe zur Abkürzung: B
Stakeholder Requirement, auch Benutzeranforderung, Stakeholder-Anforderung oder User-Anforderung: Ein Stakeholder Requirement erfasst die Anforderung eines Stakeholders, sodass sie sowohl vom Stakeholder als auch vom → Requirements Engineer verstanden werden kann.
Buchstabe zur Abkürzung: S
Solution Requirement, auch Umsetzungs- oder Lösungsanforderung: Hierüber wird beschrieben, wie die Lösung aussehen sollte — es wird eine technische Vorgabe gemacht.
Buchstabe zur Abkürzung: O

Dreistufiger Aufbau von Traces, (C) Peterjohann Consulting, 2018-2023

Abbildung 1.3: Dreistufiger Aufbau von Traces

Es sollte sich jede Anforderung von einer vorgelagerten Anforderung ableiten lassen. Die gerichteten Pfeile in Abbildung 1.3 bedeuten “haben Einfluss auf”.

In der Praxis werden mehr als nur drei Klassen von Anforderungen verwendet: Hierdurch entstehen Anforderungsketten von dem Business Requirement bis zum Test Case (Abbildung 1.4).

Sechsstufiger Aufbau von Traces, (C) Peterjohann Consulting, 2019-2023

Abbildung 1.4: Sechsstufiger Aufbau von Traces

In Abbildung 1.4 sind folgende Anforderungsklassen hinzugekommen:

Technical Requirement: Dies ist eine Verfeinerung des Solution Requirements.
Buchstabe zur Abkürzung: E
Test Requirement: Ein Test Requirement beschreibt die Tests, die durchgeführt werden sollen, um die vorgelagerten Requirements zu überprüfen / → testen.
Buchstabe zur Abkürzung: T
Test Case: Dies ist keine “echte” Anforderung, sondern die Detaillierung / Ausarbeitung des Test Requirements.
Buchstaben zur Abkürzung: TC

1.3 Was ohne Traces nicht geht

Wird auf Traces verzichtet, so fehlende wesentliche Funktionen des Requirements Engineerings. Es kann dann Folgendes nicht durch das Requirements Engineering getan werden /#→ IREB-CPRE-FL-Handbuch-23/:

“Den Nachweis erbringen, dass eine bestimmte Anforderung erfüllt ist
Nachweisen, dass und mit welchen Mitteln eine Anforderung umgesetzt wurde
Konformität der Produkte mit den geltenden Gesetzen und Normen zu zeigen
Nach fehlenden Arbeitsprodukten suchen (z.B. herausfinden, ob Testfälle für alle Anforderungen existieren)
Die Auswirkungen einer Änderung auf Anforderungen analysieren”

2. Horizontale und vertikale Traceability

Generell kann zwischen horizontaler und vertikaler Traceability unterschieden werden:

Mit horizontaler Traceability ist die Verbindung von Anforderungen auf der gleichen (horizontalen) Trace-Ebene gemeint, also beispielsweise alle Business-Anforderungen, die miteinander verbunden sind
Unter vertikaler Traceability wird die Nachvollziehbarkeit der Anforderungen “von der Idee bis zur Umsetzung” verstanden, also beispielsweise alle Stakeholder- und Solution-Anforderungen, die von einer (einzelnen) Business-Anforderung abgeleitet werden

Bereits bei kleineren Systemen treten horizontale und vertikale Traces auf, sodass ein Trace-Netz (oder auch Trace-Graph) entsteht. Die Richtungspfeile bedeuten “haben inhaltlichen Einfluss auf”. Abbildung 2.1 zeigt ein Trace-Netz mit 3 Business-Anforderungen, 4 Stakeholder-Anforderungen und 3 Solution-Anforderungen.

Ein Trace-Netz, (C) Peterjohann Consulting, 2018-2023

Abbildung 2.1: Ein Trace-Netz

In Abbildung 2.1 sind die Anforderungen einer Anforderungsklasse in einer Spalte angeordnet. Daher bezeichnen die vertikalen Pfeile (blau gestrichelt in Abbildung 2.2) die horizontalen Traces und die horizontalen Pfeile die vertikalen Traces (schwarz und durchgezogen in Abbildung 2.2).

Ein Trace-Netz mit horizontalen und vertikalen Traces, (C) Peterjohann Consulting, 2022-2023

Abbildung 2.2: Ein Trace-Netz mit horizontalen und vertikalen Traces

Die Darstellung der Tracerichtungen (Vertauschen von horizontalen von vertikalen Traces) in Abbildung 2.2 ist verwirrend. Wenn man die Darstellung um 90 Grad kippt (Abbildung 2.3), so passt die Visualisierung besser.

Horizontale und vertikale Traces, (C) Peterjohann Consulting, 2022-2023

Abbildung 2.3: Horizontale und vertikale Traces

Auch wenn sich die Darstellungsform in Abbildung 2.3 an dem → V‑Modell orientiert — der linke Zweig eines Vs ist erkennbar — so wird ist die Erfassung der Anforderungen in Abbildung 2.1 oder 2.2 einfacher. Beide Darstellungsformen sind jedoch gleichwertig.

In der Regel sind zwei Anforderungen immer in zwei Richtungen verbunden, zwei unidirektionale Pfeile können dann durch einen bidirektionalen Doppelpfeil ersetzt werden (Abbildung 2.4). Die Doppelpfeile bedeuten dann “haben inhaltliche Verbindung mit”.

Ein Trace-Netz mit Doppelpfeilen, (C) Peterjohann Consulting, 2018-2023

Abbildung 2.4: Ein Trace-Netz mit Doppelpfeilen

Sind ohnehin alle Verbindungen bidirektional, so können statt Doppelpfeilen einfache Linien verwendet werden (Abbildung 2.5). Diese Linien bedeuten dann “sind bidirektional verbunden” oder eben “haben inhaltliche Verbindung mit”.

Ein Trace-Netz mit Linien, (C) Peterjohann Consulting, 2018-2023

Abbildung 2.5: Ein Trace-Netz mit Linien

3. Pre- and Post-Traceability

Generell wird zwischen Pre- und Post-Traces unterschieden. Die Pre-Traces stellen Verbindungen zu den “Ursprungsanforderungen” (Quellen für Requirements) her, während die Post-Traces die Verbindungen zu den nachgelagerten Umsetzungen (Design, Implementation und Tests) liefern.

Pre- und Post-Traceability, (C) Peterjohann Consulting, 2019-]lj]

Abbildung 3.1: Pre- und Post-Traceability (nach /Hruschka19/)

Was genau zu den “eigenen” Requirements (mittelers Rechteck mit den Anforderungen A1 bis A5 in Abbildung 3.1) gehört, kann über den → Systemkontext oder über den Requirements-Prozess festgelegt werden. Die Pre- und Post-Traces werden idealerweise über das eingesetzte → RE-Tool erfasst.

4. Der Einsatz von Traces / Traceability

Stellt sich im Laufe der Umsetzung der Anforderungen heraus, dass einzelne Anforderungen entfallen — weil sie nicht mehr benötigt werden oder weil sie nicht umsetzbar sind — so müssen die vor- und nachgelagerten Anforderungen ebenfalls betrachtet und gegebenenfalls entfernt werden.

In Abbildung 4.1 ist ein Trace-Netz dargestellt, welches nach der Erstellung und Umsetzung der Anforderungen entstanden ist.

Beispiel 1: Trace-Netz mit Defekten, (C) Peterjohann Consulting, 2020-]lj]

Abbildung 4.1: Beispiel 1: Trace-Netz mit Defekten

Folgende Auffälligkeiten weist das Netz auf:

Es gibt eine Business-Anforderung (B4), die keine Traces aufweist
Die Lösungsanforderung O4 weist ebenfalls keine Traces auf
Die Lösungsanforderung O5 besetzt nur einen Trace, der zur Stakeholder-Anforderung S5 führt. Diese wiederum hat aber keine weiteren Traces

Dies bedeutet:

Die Business-Anforderung (B4) ist nicht weiter abgeleitet und insbesondere nicht umgesetzt worden
Es ist eine Lösung (O4) umgesetzt worden, für die es keine höheren Anforderungen gibt
Es gibt eine Lösung (O5), die zwar eine Stakeholder-Anforderung (S5) kennt, aber keinen Bezug zu irgendeiner Business-Anforderung hat

Wenn man diese vier kritischen Anforderungen aus dem Trace-Netz streicht, so ergibt sich ein Netz, welches nur noch valide Anforderungen enthält (Abbildung 4.2).

Beispiel 1: Trace-Netz mit korrigierten Defekten (durch Streichung), (C) Peterjohann Consulting, 2020-]lj]

Abbildung 4.2: Beispiel 1: Trace-Netz mit korrigierten Defekten (durch Streichung)

Alternativ kann man das Trace-Netz auch überprüfen und Traces bei den kritischen Anforderungen ergänzen. Im einfachsten Fall werden über zwei zusätzliche Traces das Trace-Netz wieder valide (Abbildung 4.3).

Beispiel 1: Trace-Netz mit korrigierten Defekten (durch Ergänzung), (C) Peterjohann Consulting, 2020-]lj]

Abbildung 4.3: Beispiel 1: Trace-Netz mit korrigierten Defekten (durch Ergänzung)

Bei der Überprüfung des Systems mithilfe des Trace-Netzes fallen häufig folgende, kritische Phänomene auf:

Es gibt hoch-priorisierte Business- oder Stakeholder-Anforderungen, die nicht umgesetzt wurden
Es gibt technische Anforderungen, die umgesetzt wurden, deren Nutzen aber unklar ist, da keine Bezüge zu Business- oder Stakeholder-Anforderungen vorhanden sind

5. Traces zwischen Anforderungen, Testfällen und Source Code

Traces sind insbesondere bei der Softwareentwicklung hilfreich, wenn es darum geht, Verbindungen zwischen den Anforderungen, Testfällen und dem Source Code herzustellen. In Abbildung 5.1 ist beispielhaft eine Anforderung dargestellt, aus der sich Testfälle und Source Code ableiten.

Zusammenhang Anforderung, Testfall und Source Code über Traces, (C) Peterjohann Consulting, 2021-]lj]

Abbildung 5.1: Zusammenhang Anforderung, → Testfall und Source Code über Traces

Anmerkung:
Die Reihenfolge der Entwicklung ist über die Abbildung 5.1 nicht festgelegt. In der Regel werden jedoch zunächst die Anforderungen erfasst, anschließend die Testfälle beschrieben und dann der Source Code erstellt.

6. Varianten

Da Traceability die Verbindung von einzelnen Elementen (hier eben Anforderungen) meint, greift das Prinzip überall dort, wo Nachvollziehbarkeit gefordert wird.

Stichworte hierzu:

V‑Modell: Das V‑Modell enthält (vielfach) vertikale und horizontale Traces. Entsprechend sind über das verwendete V‑Modell die Anforderungsklassen festgelegt
CMMI, A‑SPICE: Bei den höheren Reifegraden des CMMI (Capability Maturity Model Integration) und des Automotive SPICE (A‑SPICE, ISO/IEC 15504) wird ausdrücklich die Traceability gefordert. Unter “höher” ist bereits der Reifegrad 2 zu verstehen — oder anders ausgedrückt: Ohne Requirements Engineering mit Traceability erreichen Sie nicht einmal den Reifegrad 2
ISO 26262: Die ISO 26262 verlangt Aktivitäten zur Nachvollziehbarkeit von Anforderungen
ISO 9000: Bei der ISO 9000 werden Bezüge / Traces zwischen den Qualitätssicherungsdokumenten verlangt
Impact Mapping: Das Impact Mapping beschreibt über ein mehrstufiges Modell einen Trace-Graphen im agilen Kontext — vom Stakeholder Level zur → User Story
User Story Maps: User Story Maps verlinken einzelne → User Stories und bilden somit automatisch Traces. Allerdings sind User Stories immer Stakeholder-Anforderungen, die Traces sind vertikal

7. Anmerkungen

Die Erstellung und die Pflege der Traces werden häufig unterschätzt. In der Folge werden die Traces nicht gepflegt und überprüft, sodass das beschriebene System nicht mehr mit der Beschreibung übereinstimmt.

8. Häufige Fragen und Antworten zur Traceability

Einige Fragen zur Traceability werden häufig gestellt – diese werden hier wiedergegeben.

F: Kann Traceability auch mit “einfachen Tabellen” (Anforderungslisten) hergestellt werden?
A: Nein. Die Übersichtlichkeit geht bei der Verwendung von Tabellen (schnell) verloren. Wird zudem auf Historisierung (der Änderungen) verzichtet, sind “einfache Tabellen” für die Anforderungsverfolgung nahezu nutzlos.
F: Kann in der Praxis auf Traces verzichtet werden?
A: Nein, in der Regel nicht. Ohne Traces wird nicht klar, wie die Anforderungen zusammenhängen.
F: Können die Traces “automatisch” erstellt werden?
A: Nein, in der Regel nicht. Die Traces müssen immer “von Hand” hinzugefügt werden.
F: Wie viele horizontale Trace-Ebenen sind notwendig?
A: Das wird vorab / vor → Projektstart festgelegt und hängt von der Größe des Systems und vom Requirements-Prozess ab. Minimal dürften es zwei Trace-Ebenen sein (Stakeholder-Anforderungen und Lösungsanforderungen). In der Praxis ergeben sich aber 3 bis 8 Ebenen.

A. Präsentationen, Literatur und Weblinks

Die Traceability wird in meiner Präsentation zum Requirements Engineering kurz beschrieben.

Inhalt	Typ
Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation)

In folgenden Büchern wird als Teilaspekt die Traceability erläutert:

/BAPG15/ Project Management Institute: → Business Analysis For Practitioners: A Practice Guide, Project Management Institute, Philadelphia, Pennsylvania 2015, ISBN 978–1‑62825–069‑5
/BBG15/ IIBA: A Guide to the Business Analysis Body of Knowledge (BABOK Guide), International Institute of Business Analysis, Marietta, Georgia 3rd Edition 2015, ISBN 978–1‑927584–02‑6
/BBG17‑d/ IIBA: BABOK v3: Leitfaden zur Business-Analyse BABOK Guide 3.0, Dr. Götz Schmidt, Wettenberg 2017, ISBN 978–3‑945997–03‑1
/Ebert22/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 7. Auflage 2022, ISBN 978–3‑86490–919‑1
/Hruschka19/ Peter Hruschka: Business Analysis und Requirements Engineering: Prozesse und Produkte nachhaltig verbessern, Hanser, München 2. Auflage 2019, ISBN 978–3‑446–45589‑4
/PMG-BA17/ Project Management Institute: The PMI Guide to Business Analysis, Project Management Institute, Philadelphia, Pennsylvania 2017, ISBN 978–1‑62825–198‑2
/Wiegers13/ Karl E. Wiegers, Joy Beatty: Software Requirements, Microsoft Press, Redmond, Washington 3rd Edition 2013, ISBN 978–0‑7356–7966‑5

Auf folgende Weblinks zur Traceability wird in diesem Beitrag Bezug genommen:

/IREB/ IREB – International Requirements Engineering Board: Website (deutsche Fassung)
/#IREB-CPRE-FL-Handbuch-23/ IREB – International Requirements Engineering Board: Handbuch für das CPRE Foundation Level nach dem IREB-Standard, Version 1.1.1 vom März 2023 (deutsch, pdf-Datei, 158 Seiten)

/#Wiki-Traceability/ Rückverfolgbarkeit in der deutschen Wikipedia

/#Wiki-Traceability‑e/ Traceability in der englischen Wikipedia

Legende zu den Weblinks
/ / Verweis auf eine Website (generell)
/*/ Verweis auf eine Website, die als Buch-Ergänzung dient
/#/ Verweis auf einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website

Telefon:	0 54 85 / 830 17 29
Fax:	0 54 85 / 830 17 28
E-Mail:	kontakt@peterjohann-consulting.de