header-image

Traceability Verbindungen zwischen den Anforderungen

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.

Manage­ment-Zusam­men­fas­sung zu die­sem Bei­trag:
Tracea­bi­li­ty ist ein essen­ti­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äu­tert.

Die Tracea­bi­li­ty ist wesent­lich für die Nach­voll­zieh­bar­keit von Anfor­de­run­gen im Sys­tems oder Requi­re­ments Engi­nee­ring. 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 Ana­ly­sis
Syn­ony­me: Nach­voll­zieh­bar­keit, Rück­ver­folg­bar­keit
Not­wen­di­ges Know-how: Requi­re­ments-Engi­nee­ring-Kennt­nis­se
Schwie­rig­keits­grad: Mit­tel

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


1. Beschreibung

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 Anfor­de­rungs­ma­nage­ments.”

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

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

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

Somit stel­len die Traces im Requi­re­ments Engi­nee­ring sicher, das eine Ursprungs­an­for­de­rung auch zu einer Umsetzung(sanforderung) führt. 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) des Anfor­de­rungs­ma­nage­ments ori­en­tiert. Es wer­den fol­gen­de drei Klas­sen unter­schie­den:

  • 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.
    Buch­sta­be zur Abkür­zung: O

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

Abbil­dung 1.2: 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.

1.1 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 wer­den:

  • Unter hori­zon­ta­ler Tracea­bi­li­ty wird die Nach­voll­zieh­bar­keit “von der Idee bis zur Umset­zung” ver­stan­den
  • 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 bei 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”.

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

Abbil­dung 1.3: 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. 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-2019

Abbil­dung 1.4: Ein Trace-Netz mit Dop­pel­pfei­len

Sind ohne­hin alle Ver­bin­dun­gen bidi­rek­tio­nal, so kön­nen statt Dop­pel­pfei­le ein­fa­che Linie ver­wen­det wer­den. Die­se Lini­en bedeu­ten dann “sind bidi­rek­tio­nal ver­bun­den”.
Ein Trace-Netz mit Linien, (C) Peterjohann Consulting, 2018-2019

Abbil­dung 1.5: Ein Trace-Netz mit Lini­en

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 wer­den.

1.2 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) lie­fern.

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

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


2. 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 die Nach­voll­zieh­bar­keit gefor­dert wird.

Stich­wor­te hier­zu:

  • V‑Modell: Das V‑Modell ent­hält (viel­fach) ver­ti­ka­le und hori­zon­ta­le Traces
  • CMMI, A‑SPICE: Bei den höh­reren Rei­fe­gra­den des CMMI und des Auto­mo­ti­ve SPICE wird aus­drück­lich die Tracea­bi­li­ty gefor­dert
  • 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 Sto­ry
  • User Maps: User Maps ver­lin­ken ein­zel­ne User Sto­ries und bil­den somit auto­ma­tisch Traces

3. Anmerkungen

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

Fol­gen­de Phä­no­me­ne kön­nen dann — bevor­zugt bei Über­prü­fun­gen des Sys­tems — auf­tre­ten:

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

4. 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 wie­der­ge­ge­ben.

  • F: Kann Tracea­bi­li­ty auch mit “ein­fa­chen Tabel­len” 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 nutz­los.
  • 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 zusam­men­hän­gen.
  • 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 ab. Mini­mal dürf­ten es zwei Trace-Ebe­nen sein (Sta­ke­hol­der­an­for­de­run­gen und Lösungs­an­for­de­run­gen).

A. Präsentationen, Literatur und Weblinks

Die Tracea­bi­li­ty wird in der Prä­sen­ta­ti­on zum Requi­re­ments Engi­nee­ring beschrie­ben.

InhaltVer­si­onStandSei­tenGrö­ßeTyp
Requi­re­ments Engi­nee­ring (und Busi­ness Ana­ly­sis) – Eine Ein­füh­rung (RE-Basis­prä­sen­ta­ti­on)0.9603/20172481,3 MB pdf (pdf)

In fol­gen­den Büchern wird als Teil­as­pekt die Tracea­bi­li­ty erläu­tert:

  • /BAPG15/ Pro­ject Manage­ment Insti­tu­te: Busi­ness Ana­ly­sis For Prac­ti­tio­ners: A Prac­tice 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
  • /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 hier Bezug genom­men:

Legen­de zu den Web­links
/ / 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 Web­site
/#V/ Ver­weis auf ein Video auf einer Web­site