Traceability Verbindungen zwischen den Anforderungen

Manage­ment-Zusam­men­fas­sung zu die­sem Bei­trag:
Tracea­bi­li­ty bezeich­net die Eigen­schaft oder Fähig­keit der Nach­voll­zieh­bar­keit und ist ein essen­zi­el­ler Bestand­teil des Requi­re­ments Engi­nee­rings. Nur mit Traces besteht die Mög­lich­keit, (dau­er­haft) die Ver­bin­dun­gen von Anfor­de­run­gen dar­zu­stel­len und zu nut­zen.
In die­sem Bei­trag wer­den Traces beschrie­ben und der Auf­wand und der Nut­zen erläutert.

Unter Tracea­bi­li­ty wird all­ge­mein die Eigen­schaft oder Fähig­keit der Nach­voll­zieh­bar­keit ver­stan­den. “Traces” (zu Deutsch: Spu­ren) sind Ver­bin­dun­gen zwi­schen Ele­men­ten eines Sys­tems. Die Tracea­bi­li­ty ist ein wesent­li­cher Bestand­teil des Sys­tems oder Requi­re­ments Engi­nee­rings. Gene­rell soll­te ein Sys­tem über Anfor­de­run­gen voll­stän­dig beschrie­ben sein: Nur das, was in den Anfor­de­run­gen steht, wird umge­setzt — das, was nicht in den Anfor­de­run­gen steht, wird nicht umge­setzt. Anfor­de­run­gen, die kei­ne “Traces” besit­zen, soll­ten nicht umge­setzt wer­den / sein.

  • Stich­wor­te: Tracea­bi­li­ty, Tracea­bi­li­ty Graph, Trace-Netz, Tracea­bi­li­ty Matrix, Requi­re­ments Tracea­bi­li­ty Matrix (RTM), Impact Ana­ly­sis, Coverage Analysis
  • Syn­ony­me: Nach­voll­zieh­bar­keit, Rückverfolgbarkeit
  • Not­wen­di­ges Know-how: Gute Requirements-Engineering-Kenntnisse
  • Schwie­rig­keits­grad: Mittel

Die all­ge­mei­ne Beschrei­bung zum → Requi­re­ments Engi­nee­ring fin­det sich
hier

1. Einleitung und Grundlagen

In der Wiki­pe­dia steht /#Wiki-Traceability/:
“Rück­ver­folg­bar­keit (auch Nach­voll­zieh­bar­keit oder engl. Requi­re­ments Tracea­bi­li­ty) bezeich­net in der Sys­tem- und Soft­ware­ent­wick­lung die Zuor­den­bar­keit von Anfor­de­run­gen zu belie­bi­gen Arte­fak­ten über den gesam­ten Ent­wick­lungs­pro­zess und ist somit Teil des Anforderungsmanagements.”

Das → IIBA defi­niert /BBG17‑d/:
“Nach­voll­zieh­bar­keit von Anfor­de­run­gen (tracea­bi­li­ty of requi­re­ments): Fähig­keit, die Bezie­hun­gen zwi­schen Grup­pen von Anfor­de­run­gen vom ursprüng­li­chen Bedarf des Sta­ke­hol­ders bis zur aktu­ell ein­ge­führ­ten Lösung zurück­zu­ver­fol­gen. Die Nach­voll­zieh­bar­keit unter­stützt die Über­wa­chung von Ände­run­gen, indem die Quel­le einer Anfor­de­rung oder eines Designs iden­ti­fi­ziert wer­den kann und ande­re ver­bun­de­ne Anfor­de­run­gen und Designs, die von einer Ände­rung eben­falls betrof­fen sein kön­nen, ersicht­lich sind.”

Gene­rell wer­den Anfor­de­run­gen von ihrer Quel­le bis zu ihrer Sen­ke getract (sie­he Abbil­dung 1.1). Für Anfor­de­run­gen bedeu­tet dies zumeist eine Ver­fol­gung vom Busi­ness- oder → Sta­ke­hol­der-Level bis zur Umset­zung oder vom Gesamt-Pro­dukt zum Einzelbestandteil.

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

Abbil­dung 1.1: Typi­scher Auf­bau von Traces

Über Traces kann im Requi­re­ments Engi­nee­ring sicher­ge­stellt wer­den, dass eine Ursprungs­an­for­de­rung auch zu einer Umsetzung(sanforderung) führt.

1.1 Erfassung und Darstellung von Traces

Sol­len Traces erfasst wer­den, so gibt es ver­schie­de­ne Mög­lich­kei­ten, die gene­rell ent­we­der tex­tu­el­le oder gra­fi­sche Ansät­ze ver­wen­den (Abbil­dung 1.2).

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

Abbil­dung 1.2: Erfas­sungs- und Dar­stel­lungs­mög­lich­kei­ten von Traces

In der Pra­xis wer­den häu­fig Requi­re­ments-Werk­zeu­ge ein­ge­setzt, bei denen Traces “tex­tu­ell” erzeugt wer­den. Die erzeug­ten Traces kön­nen dann über Trace-Net­ze visua­li­siert werden. 

1.2 Ein einfaches Modell zur Trace-Darstellung

In Abbil­dung 1.2 ist ein ein­fa­ches Modell dar­ge­stellt, wel­ches sich an den Klas­sen (der IIBA und des → PMI) der Anfor­de­run­gen ori­en­tiert. Es wer­den in die­sem Bei­trag fol­gen­de drei Klas­sen unterschieden:

  • Busi­ness Requi­re­ment, auch Geschäfts­an­for­de­rung oder Busi­ness-Anfor­de­rung: Unter Busi­ness Requi­re­ments wer­den die über­ge­ord­ne­ten High-Level-Anfor­de­run­gen erfasst. Die­se sind häu­fig abs­trakt for­mu­liert.
    Buch­sta­be zur Abkür­zung: B
  • Sta­ke­hol­der Requi­re­ment, auch Benut­zer­an­for­de­rung, Sta­ke­hol­der-Anfor­de­rung oder User-Anfor­de­rung: Ein Sta­ke­hol­der Requi­re­ment erfasst die Anfor­de­rung eines Sta­ke­hol­ders, sodass sie sowohl vom Sta­ke­hol­der wie auch vom Requi­re­ments Engi­neer ver­stan­den wer­den kann.
    Buch­sta­be zur Abkür­zung: S
  • Solu­ti­on Requi­re­ment, auch Umset­zungs- oder Lösungs­an­for­de­rung: Hier­über wird beschrie­ben, wie die Lösung aus­se­hen soll­te — es wird eine tech­ni­sche Vor­ga­be gemacht.
    Buch­sta­be zur Abkür­zung: O
Dreistufiger Aufbau von Traces, (C) Peterjohann Consulting, 2018-2021

Abbil­dung 1.3: Drei­stu­fi­ger Auf­bau von Traces

Es soll­te sich jede Anfor­de­rung von einer vor­ge­la­ger­ten Anfor­de­rung ablei­ten las­sen. Die gerich­te­ten Pfei­le in Abbil­dung 1.3 bedeu­ten “haben Ein­fluss auf”. 

In der Pra­xis wer­den mehr als nur drei Klas­sen von Anfor­de­run­gen ver­wen­det: Hier­durch ent­ste­hen Anfor­de­rungs­ket­ten von dem Busi­ness Requi­re­ment bis zum Test Case (Abbil­dung 1.4).

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

Abbil­dung 1.4: Sechs­stu­fi­ger Auf­bau von Traces

In Abbil­dung 1.4 sind fol­gen­de Anfor­de­rungs­klas­sen hinzugekommen:

  • Tech­ni­cal Requi­re­ment: Dies ist eine Ver­fei­ne­rung des Solu­ti­on Requi­re­ments.
    Buch­sta­be zur Abkür­zung: E
  • Test Requi­re­ment: Ein Test Requi­re­ment beschreibt die Tests, die durch­ge­führt wer­den sol­len, um die vor­ge­la­ger­ten Requi­re­ments zu über­prü­fen / tes­ten.
    Buch­sta­be zur Abkür­zung: T
  • Test Case: Dies ist kei­ne “ech­te” Anfor­de­rung, son­dern die Detail­lie­rung / Aus­ar­bei­tung des Test Requi­re­ments.
    Buch­sta­ben zur Abkür­zung: TC

2. Horizontale und vertikale Traceability

Gene­rell kann zwi­schen hori­zon­ta­ler und ver­ti­ka­ler Tracea­bi­li­ty unter­schie­den werden:

  • Unter hori­zon­ta­ler Tracea­bi­li­ty wird die Nach­voll­zieh­bar­keit der Anfor­de­run­gen “von der Idee bis zur Umset­zung” verstanden
  • Mit ver­ti­ka­ler Tracea­bi­li­ty ist die Ver­bin­dung von Anfor­de­run­gen auf der glei­chen (hori­zon­ta­len) Trace-Ebe­ne gemeint

Bereits bei klei­ne­ren Sys­te­men tre­ten hori­zon­ta­le und ver­ti­ka­le Traces auf, sodass ein Trace-Netz (oder auch Trace-Graph) ent­steht. Die Rich­tungs­pfei­le bedeu­ten “haben inhalt­li­chen Ein­fluss auf”. Abbil­dung 2.1 zeigt ein Trace-Netz mit 3 Busi­ness-Anfor­de­run­gen, 4 Sta­ke­hol­der-Anfor­de­run­gen und 3 Solution-Anforderungen.

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

Abbil­dung 2.1: Ein Trace-Netz

In der Regel sind zwei Anfor­de­run­gen immer in zwei Rich­tun­gen ver­bun­den, zwei uni­di­rek­tio­na­le Pfei­le kön­nen dann durch einen bidi­rek­tio­na­len Dop­pel­pfeil ersetzt wer­den (Abbil­dung 2.2). Die Dop­pel­pfei­le bedeu­ten dann “haben inhalt­li­che Ver­bin­dung mit”.

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

Abbil­dung 2.2: Ein Trace-Netz mit Doppelpfeilen

Sind ohne­hin alle Ver­bin­dun­gen bidi­rek­tio­nal, so kön­nen statt Dop­pel­pfei­len ein­fa­che Lini­en ver­wen­det wer­den. Die­se Lini­en bedeu­ten dann “sind bidi­rek­tio­nal ver­bun­den” oder eben “haben inhalt­li­che Ver­bin­dung mit”.

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

Abbil­dung 2.3: Ein Trace-Netz mit Linien

3. Pre- and Post-Traceability

Gene­rell wird zwi­schen Pre- und Post-Traces unter­schie­den. Die Pre-Traces stel­len Ver­bin­dun­gen zu den “Ursprungs­an­for­de­run­gen” (Quel­len für Requi­re­ments) her, wäh­rend die Post-Traces die Ver­bin­dun­gen zu den nach­ge­la­ger­ten Umset­zun­gen (Design, Imple­men­ta­ti­on und Tests) liefern.

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

Abbil­dung 3.1: Pre- und Post-Tracea­bi­li­ty (nach /Hruschka19/)

Was jetzt genau zu den “eige­nen” Requi­re­ments gehört, kann über den → Sys­tem­kon­text oder den Requi­re­ments-Pro­zess fest­ge­legt wer­den. Die Pre- und Post-Traces kön­nen / soll­ten eben­falls fest­ge­hal­ten werden.

4. Der Einsatz von Traces / Traceability

Stellt sich im Lau­fe der Umset­zung der Anfor­de­run­gen her­aus, dass ein­zel­ne Anfor­de­run­gen ent­fal­len — weil sie nicht mehr benö­tigt wer­den oder weil sie nicht umsetz­bar sind — so müs­sen die vor- und nach­ge­la­ger­ten Anfor­de­run­gen eben­falls betrach­tet und gege­be­nen­falls ent­fernt werden.

In Abbil­dung 4.1 ist ein Trace-Netz dar­ge­stellt, wel­ches nach der Erstel­lung und Umset­zung der Anfor­de­run­gen ent­stan­den ist.

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

Abbil­dung 4.1: Bei­spiel 1: Trace-Netz mit Defekten

Fol­gen­de Auf­fäl­lig­kei­ten weist das Netz auf:

  • Es gibt eine Busi­ness-Anfor­de­rung (B4), die kei­ner­lei Traces aufweist
  • Die Lösungs­an­for­de­rung O4 weist eben­falls kei­ne Traces auf
  • Die Lösungs­an­for­de­rung O5 besetzt nur einen Trace, der zur Sta­ke­hol­der-Anfor­de­rung S5 führt. Die­se wie­der­um hat aber kei­ne wei­te­ren Traces

Dies bedeu­tet:

  • Die Busi­ness-Anfor­de­rung (B4) ist nicht wei­ter abge­lei­tet und ins­be­son­de­re nicht umge­setzt worden
  • Es ist eine Lösung (O4) umge­setzt wor­den, für die es kei­ne höhe­ren Anfor­de­run­gen gibt
  • Es gibt eine Lösung (O5), die zwar eine Sta­ke­hol­der-Anfor­de­rung (S5) kennt, aber kei­nen Bezug zu irgend­ei­ner Busi­ness-Anfor­de­rung hat

Wenn man die­se vier kri­ti­schen Anfor­de­run­gen aus dem Trace-Netz streicht, so ergibt sich ein Netz, wel­ches nur noch vali­de Anfor­de­run­gen ent­hält (Abbil­dung 4.2).

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

Abbil­dung 4.2: Bei­spiel 1: Trace-Netz mit kor­ri­gier­ten Defek­ten (durch Streichung)

Alter­na­tiv kann man das Trace-Netz auch über­prü­fen und Traces bei den kri­ti­schen Anfor­de­run­gen ergän­zen. Im ein­fachs­ten Fall wer­den über zwei zusätz­li­che Traces das Trace-Netz wie­der vali­de (Abbil­dung 4.3).

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

Abbil­dung 4.3: Bei­spiel 1: Trace-Netz mit kor­ri­gier­ten Defek­ten (durch Ergänzung)

Bei der Über­prü­fung des Sys­tems mit­hil­fe des Trace-Net­zes fal­len häu­fig fol­gen­de, kri­ti­sche Phä­no­me­ne auf:

  • Es gibt hoch-prio­ri­sier­te Busi­ness- oder Sta­ke­hol­der-Anfor­de­run­gen, die nicht umge­setzt wurden
  • Es gibt tech­ni­sche Anfor­de­run­gen, die umge­setzt wur­den, deren Nut­zen aber unklar ist, da kei­ne Bezü­ge zu Busi­ness- oder Sta­ke­hol­der-Anfor­de­run­gen vor­han­den sind

5. Varianten

Da Tracea­bi­li­ty die Ver­bin­dung von ein­zel­nen Ele­men­ten (hier eben Anfor­de­run­gen) meint, greift das Prin­zip über­all dort, wo Nach­voll­zieh­bar­keit gefor­dert wird.

Stich­wor­te hierzu:

  • V‑Modell: Das V‑Modell ent­hält (viel­fach) ver­ti­ka­le und hori­zon­ta­le Traces. Ent­spre­chend sind über das ver­wen­de­te V‑Modell die Anfor­de­rungs­klas­sen festgelegt
  • CMMI, A‑SPICE: Bei den höhe­ren Rei­fe­gra­den des CMMI (Capa­bi­li­ty Matu­ri­ty Model Inte­gra­ti­on) und des Auto­mo­ti­ve SPICE (A‑SPICE, ISO/IEC 15504) wird aus­drück­lich die Tracea­bi­li­ty gefor­dert. Unter “höher” wird bereits der Rei­fe­grad 2 zu ver­ste­hen — oder anders aus­ge­drückt: Ohne Requi­re­ments Engi­nee­ring mit Tracea­bi­li­ty errei­chen Sie nicht ein­mal den Rei­fe­grad 2
  • ISO 26262: Die ISO 26262 ver­langt Akti­vi­tä­ten zur Nach­voll­zieh­bar­keit von Anforderungen
  • ISO 9000: Bei der ISO 9000 wer­den Bezü­ge / Traces zwi­schen den Qua­li­täts­si­che­rungs­do­ku­men­ten verlangt
  • Impact Map­ping: Das Impact Map­ping beschreibt über ein mehr­stu­fi­ges Modell einen Trace-Gra­phen im agi­len Kon­text — vom Sta­ke­hol­der Level zur User Story
  • User Sto­ry Maps: User Sto­ry Maps ver­lin­ken ein­zel­ne → User Sto­ries und bil­den somit auto­ma­tisch Traces. Aller­dings sind User Sto­ries immer Sta­ke­hol­der-Anfor­de­run­gen, die Traces sind vertikal

6. Anmerkungen

Die Erstel­lung und die Pfle­ge der Traces wer­den häu­fig unter­schätzt. In der Fol­ge wer­den die Traces nicht gepflegt und über­prüft, sodass das beschrie­be­ne Sys­tem nicht mehr mit der Beschrei­bung übereinstimmt.

7. Häufige Fragen und Antworten zur Traceability

Eini­ge Fra­gen zur Tracea­bi­li­ty wer­den häu­fig gestellt – die­se wer­den hier wiedergegeben.

  • F: Kann Tracea­bi­li­ty auch mit “ein­fa­chen Tabel­len” (Anfor­de­rungs­lis­ten) her­ge­stellt wer­den?
    A: Nein. Die Über­sicht­lich­keit geht bei der Ver­wen­dung von Tabel­len (schnell) ver­lo­ren. Wird zudem auf His­to­ri­sie­rung (der Ände­run­gen) ver­zich­tet, sind “ein­fa­che Tabel­len” für die Anfor­de­rungs­ver­fol­gung nahe­zu nutzlos.
  • F: Kann in der Pra­xis auf Traces ver­zich­tet wer­den?
    A: Nein, in der Regel nicht. Ohne Traces wird nicht klar, wie die Anfor­de­run­gen zusammenhängen.
  • F: Kön­nen die Traces “auto­ma­tisch” erstellt wer­den?
    A: Nein, in der Regel nicht. Die Traces müs­sen immer “von Hand” hin­zu­ge­fügt werden.
  • F: Wie vie­le hori­zon­ta­le Trace-Ebe­nen sind not­wen­dig?
    A: Das wird vor­ab / vor Pro­jekt­start fest­ge­legt und hängt von der Grö­ße des Sys­tems und vom Requi­re­ments-Pro­zess ab. Mini­mal dürf­ten es zwei Trace-Ebe­nen sein (Sta­ke­hol­der-Anfor­de­run­gen und Lösungs­an­for­de­run­gen). In der Pra­xis erge­ben sich aber 3 bis 8 Ebenen.

A. Präsentationen, Literatur und Weblinks

Die Tracea­bi­li­ty wird in mei­ner Prä­sen­ta­ti­on zum Requi­re­ments Engi­nee­ring kurz beschrieben.

InhaltTyp
Requi­re­ments Engi­nee­ring (und Busi­ness Ana­ly­sis) – Eine Ein­füh­rung (RE-Basis­prä­sen­ta­ti­on)

pdf

In fol­gen­den Büchern wird als Teil­aspekt die Tracea­bi­li­ty erläutert:

  • /BAPG15/ Pro­ject Manage­ment Insti­tu­te: Busi­ness Ana­ly­sis For Prac­ti­tio­ners: A Prac­ti­ce Gui­de, Pro­ject Manage­ment Insti­tu­te, Phil­adel­phia, Penn­syl­va­nia 2015, ISBN 978–1‑62825–069‑5
  • /BBG15/ IIBA: A Gui­de to the Busi­ness Ana­ly­sis Body of Know­ledge (BABOK Gui­de), Inter­na­tio­nal Insti­tu­te of Busi­ness Ana­ly­sis, Mari­et­ta, Geor­gia 3rd Edi­ti­on 2015, ISBN 978–1‑927584–02‑6
  • /BBG17‑d/ IIBA: BABOK v3: Leit­fa­den zur Busi­ness-Ana­ly­se BABOK Gui­de 3.0, Dr. Götz Schmidt, Wet­ten­berg 2017, ISBN 978–3‑945997–03‑1
  • /Hruschka19/ Peter Hrusch­ka: Busi­ness Ana­ly­sis und Requi­re­ments Engi­nee­ring: Pro­zes­se und Pro­duk­te nach­hal­tig ver­bes­sern, Han­ser, Mün­chen 2. Auf­la­ge 2019, ISBN 978–3‑446–45589‑4
  • /PMG-BA17/ Pro­ject Manage­ment Insti­tu­te: The PMI Gui­de to Busi­ness Ana­ly­sis, Pro­ject Manage­ment Insti­tu­te, Phil­adel­phia, Penn­syl­va­nia 2017, ISBN 978–1‑62825–198‑2
  • /Wiegers13/ Karl E. Wie­gers, Joy Beat­ty: Soft­ware Requi­re­ments, Micro­soft Press, Red­mond, Washing­ton 3rd Edi­ti­on 2013, ISBN 978–0‑7356–7966‑5

Auf fol­gen­de Web­links zur Tracea­bi­li­ty wird in die­sem Bei­trag Bezug genommen:

Legen­de zu den Weblinks
/ / Ver­weis auf eine Web­site (gene­rell)
/*/ Ver­weis auf eine Web­site, die als Buch-Ergän­zung dient
/#/ Ver­weis auf ein­zel­nes The­ma auf einer Website
/#V/ Ver­weis auf ein Video auf einer Website 

Scroll to Top