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
Notwendiges Know-how: Gute 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.”

Das → IIBA definiert /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.”

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-2021

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-2021

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 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 — es wird eine technische Vorgabe gemacht.
Buchstabe zur Abkürzung: O

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

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-2021

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

2. Horizontale und vertikale Traceability

Generell kann zwischen horizontaler und vertikaler Traceability unterschieden werden:

Unter horizontaler Traceability wird die Nachvollziehbarkeit der Anforderungen “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 2.1 zeigt ein Trace-Netz mit 3 Business-Anforderungen, 4 Stakeholder-Anforderungen und 3 Solution-Anforderungen.

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

Abbildung 2.1: 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 (Abbildung 2.2). Die Doppelpfeile bedeuten dann “haben inhaltliche Verbindung mit”.

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

Abbildung 2.2: 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” oder eben “haben inhaltliche Verbindung mit”.

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

Abbildung 2.3: 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 jetzt genau zu den “eigenen” Requirements gehört, kann über den → Systemkontext oder den Requirements-Prozess festgelegt werden. Die Pre- und Post-Traces können / sollten ebenfalls festgehalten werden.

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 keinerlei 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. 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” wird 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

6. 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.

7. 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
/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:

/#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

Traceability Verbindungen zwischen den Anforderungen