Unter Traceability wird allgemein die Eigenschaft oder Fähigkeit der Nachvollziehbarkeit verstanden. “Traces” (zu deutsch: Spuren) sind Verbindungen zwischen Elementen eines Systems.
Management-Zusammenfassung zu diesem Beitrag:
Traceability 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.
Die Traceability ist wesentlich für die Nachvollziehbarkeit von Anforderungen im Systems oder → Requirements Engineering. 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
Notwendiges Know-how: Requirements-Engineering-Kenntnisse
Schwierigkeitsgrad: Mittel
Die allgemeine Beschreibung zum Requirements Engineering findet sich
hier
1. Einleitung und Grundlagen
In der Wikipedia steht /#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.”
Generell werden also Anforderungen von ihrer Quelle bis zu ihrer Senke getraced (siehe Abbildung 1.1). Für Anforderungen bedeutet dies zumeist eine Verfolgung vom → Stakeholder-Level bis zur Umsetzung oder vom Gesamt-Produkt zum Einzelbestandteil.
Abbildung 1.1: Typischer Aufbau von Traces
Somit stellen die Traces im Requirements Engineering sicher, das eine Ursprungsanforderung auch zu einer Umsetzung(sanforderung) führt. In Abbildung 1.2 ist ein einfaches Modell dargestellt, welches sich an den Klassen (der IIBA und des → PMI) des Anforderungsmanagements orientiert. Es werden 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 wie 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.
Buchstabe zur Abkürzung: O
Abbildung 1.2: Dreistufiger Aufbau von Traces
Es sollte sich jede Anforderung von einer vorgelagerten Anforderung ableiten lassen.
1.1 Horizontale und vertikale Traceability
Generell kann zwischen horizontaler und vertikaler Traceability unterschieden werden:
- Unter horizontaler Traceability wird die Nachvollziehbarkeit “von der Idee bis zur Umsetzung” verstanden
- Mit vertikaler Traceability ist die Verbindung von Anforderungen auf der gleichen (horizontalen) Trace-Ebene gemeint
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 1.3: Ein Trace-Netz
In der Regel sind zwei Anforderungen immer in zwei Richtungen verbunden, zwei unidirektionale Pfeile können dann durch einen bidirektionalen Doppelpfeil ersetzt werden. Die Doppelpfeile bedeuten dann “haben inhaltliche Verbindung mit”.
Abbildung 1.4: Ein Trace-Netz mit Doppelpfeilen
Sind ohnehin alle Verbindungen bidirektional, so können statt Doppelpfeilen einfache Linien verwendet werden. Diese Linien bedeuten dann “sind bidirektional verbunden”.
Abbildung 1.5: Ein Trace-Netz mit Linien
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.
1.2 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, 2018-]lj]](https://www.peterjohann-consulting.de/_images/peco-re-traceability-pre-and-post-l.png "Pre- und Post-Traceability, (C) Peterjohann Consulting, 2018-2021")
Abbildung 1.6: Pre- und Post-Traceability (nach /Hruschka19/)
2. Varianten
Da Traceability die Verbindung von einzelnen Elementen (hier eben Anforderungen) meint, greift das Prinzip überall dort, wo die Nachvollziehbarkeit gefordert wird.
Stichworte hierzu:
- V‑Modell: Das V‑Modell enthält (vielfach) vertikale und horizontale Traces
- CMMI, A‑SPICE: Bei den höheren Reifegraden des CMMI und des Automotive SPICE wird ausdrücklich die Traceability gefordert
- 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
3. Anmerkungen
Die Erstellung und die Pflege der Traces wird 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.
Folgende Phänomene können dann — bevorzugt bei Überprüfungen des Systems — auftreten:
- Es gibt hoch-priorisierte 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
4. 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” 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: Wie viele horizontale Trace-Ebenen sind notwendig?
A: Das wird vorab / vor Projektstart festgelegt und hängt von der Größe des Systems ab. Minimal dürften es zwei Trace-Ebenen sein (Stakeholderanforderungen und Lösungsanforderungen).
A. Präsentationen, Literatur und Weblinks
Die Traceability wird in der Präsentation zum Requirements Engineering 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
- /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 hier Bezug genommen:
- /#microTOOL-Traceability/ Beitrag zur Traceability bei der Firma microTOOL
- /#t2informatik-Traceability/ Kurzbeitrag zur Traceability bei der Firma t2informatik
- /#Wiki-Traceability/ Rückverfolgbarkeit in der deutschen 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
Letzte Aktualisierung: 04.06.2019 © Peterjohann Consulting, 2005–2021