header-image

Traceability Verbindungen zwischen den Anforderungen

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 essentieller 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
Einordnung: Requirements Engineering (siehe Übersicht hier auf der Website)
Notwendiges Know-how: Requirements-Engineering-Kenntnisse
Schwierigkeitsgrad: Mittel


1. Beschreibung

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.

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

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 so dass 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

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

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 System treten bei horizontale und vertikale Traces auf, so dass ein Trace-Netz (oder auch Trace-Graph) entsteht. Die Richtungspfeile bedeuten „haben inhaltlichen Einfluss auf“.

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

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

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

Abbildung 1.4: Ein Trace-Netz mit Doppelpfeilen

Sind ohnehin alle Verbindungen bidirektional, so können statt Doppelpfeile einfache Linie verwendet werden. Diese Linien bedeuten dann „sind bidirektional verbunden“.
Ein Trace-Netz mit Linien, (C) Peterjohann Consulting, 2018-2019

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]

Abbildung 1.6: Pre- und Post-Traceability (nach /Hruschka14/)


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öhreren 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 Maps: User Maps verlinken einzelne User Stories und bilden somit automatisch Traces

3. Anmerkungen

Die Erstellung und Pflege der Traces wird häufig unterschätzt. In der Folge werden die Traces nicht gepflegt und überprüft, so dass 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 kein Bezug 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.

InhaltVersionStandSeitenGrößeTyp
Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation)0.9603/20172481,3 MB pdf (pdf)

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
  • /Hruschka14/ Peter Hruschka: Business Analysis und Requirements Engineering: Prozesse und Produkte nachhaltig verbessern, Hanser, München 2014, ISBN 9978-3-446-43807-1
  • /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 wurde hier Bezug genommen:

  • /#Traceability-microtool/ Beitrag Traceability bei der Firma microtool
  • /#Traceability-t2informatik/ 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