Traceability Verbindungen zwischen Anforderungen herstellen

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
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, Covera­ge Analysis
  • Syn­ony­me: Nach­voll­zieh­bar­keit, Rück­ver­folg­bar­keit, Verfolgbarkeit
  • Not­wen­di­ges Know-how: Gute Requirements-Engineering-Kenntnisse
  • Schwie­rig­keits­grad: Mittel

1. Einleitung und Grundlagen

In der Wiki­pe­dia steht zur Rück­ver­folg­bar­keit /#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 die Nach­voll­zieh­bar­keit wie folgt /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 Stake­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.”

Ebert beschreibt die Ver­folg­bar­keit /Ebert22/:
“Erkenn­ba­re Bezie­hung (engl. Tracea­bi­li­ty) zwi­schen zwei oder meh­re­ren logi­schen Ein­hei­ten (Arbeits­er­geb­nis) durch doku­men­tier­te Iden­ti­fi­ka­ti­on.
Das Ziel der Ver­folg­bar­keit ist die Sicher­stel­lung der Ände­rungs­kon­trol­le und der Kon­sis­tenz.
Bei­spiel: Ver­folg­bar­keit von Kun­den­an­for­de­run­gen zu Test­fäl­len. Bei der Ver­folg­bar­keit wird zwi­schen hori­zon­ta­ler und ver­ti­ka­ler Ver­folg­bar­keit unterschieden.”

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 → Stake­hol­der-Level bis zur Umset­zung oder vom Gesamt-Pro­dukt zum Einzelbestandteil.

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

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

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
  • Stake­hol­der Requi­re­ment, auch Benut­zer­an­for­de­rung, Stake­hol­der-Anfor­de­rung oder User-Anfor­de­rung: Ein Stake­hol­der Requi­re­ment erfasst die Anfor­de­rung eines Stake­hol­ders, sodass sie sowohl vom Stake­hol­der als 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-2024

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

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

1.3 Was ohne Traces nicht geht

Wird auf Traces ver­zich­tet, so feh­len­de wesent­li­che Funk­tio­nen des Requi­re­ments Engi­nee­rings. Es kann dann Fol­gen­des nicht durch das Requi­re­ments Engi­nee­ring getan wer­den /#→ IREB-CPRE-FL-Hand­buch-24/:

  • “Den Nach­weis erbrin­gen, dass eine bestimm­te Anfor­de­rung erfüllt ist 
  • Nach­wei­sen, dass und mit wel­chen Mit­teln eine Anfor­de­rung umge­setzt wurde 
  • Kon­for­mi­tät der Pro­duk­te mit den gel­ten­den Geset­zen und Nor­men zu zeigen 
  • Nach feh­len­den Arbeits­pro­duk­ten suchen (z.B. her­aus­fin­den, ob Test­fäl­le für alle Anfor­de­run­gen existieren)
  • Die Aus­wir­kun­gen einer Ände­rung auf Anfor­de­run­gen analysieren”

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:

  • Mit hori­zon­ta­ler Tracea­bi­li­ty (eng­lisch: Within-level-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, also bei­spiels­wei­se alle Busi­ness-Anfor­de­run­gen, die mit­ein­an­der ver­bun­den sind
  • Unter ver­ti­ka­ler Tracea­bi­li­ty (eng­lisch: Bet­ween-levels-tracea­bi­li­ty) wird die Nach­voll­zieh­bar­keit der Anfor­de­run­gen “von der Idee bis zur Umset­zung” ver­stan­den, also bei­spiels­wei­se alle Stake­hol­der- und Solu­ti­on-Anfor­de­run­gen, die von einer (ein­zel­nen) Busi­ness-Anfor­de­rung abge­lei­tet werden

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 Stake­hol­der-Anfor­de­run­gen und 3 Solution-Anforderungen.

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

Abbil­dung 2.1: Ein Trace-Netz

In Abbil­dung 2.1 sind die Anfor­de­run­gen einer Anfor­de­rungs­klas­se in einer Spal­te ange­ord­net. Daher bezeich­nen die ver­ti­ka­len Pfei­le (blau gestri­chelt in Abbil­dung 2.2) die hori­zon­ta­len Traces und die hori­zon­ta­len Pfei­le die ver­ti­ka­len Traces (schwarz und durch­ge­zo­gen in Abbil­dung 2.2).

Ein Trace-Netz mit horizontalen und vertikalen Traces, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 2.2: Ein Trace-Netz mit hori­zon­ta­len und ver­ti­ka­len Traces

Die Dar­stel­lung der Tra­ce­rich­tun­gen (Ver­tau­schen von hori­zon­ta­len von ver­ti­ka­len Traces) in Abbil­dung 2.2 ist ver­wir­rend. Wenn man die Dar­stel­lung um 90 Grad kippt (Abbil­dung 2.3), so passt die Visua­li­sie­rung besser. 

Horizontale und vertikale Traces, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 2.3: Hori­zon­ta­le und ver­ti­ka­le Traces

Auch wenn sich die Dar­stel­lungs­form in Abbil­dung 2.3 an dem → V‑Modell ori­en­tiert — der lin­ke Zweig eines Vs ist erkenn­bar — so wird ist die Erfas­sung der Anfor­de­run­gen in Abbil­dung 2.1 oder 2.2 ein­fa­cher. Bei­de Dar­stel­lungs­for­men sind jedoch gleichwertig.

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.4). 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-2024

Abbil­dung 2.4: 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 (Abbil­dung 2.5). 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-2024

Abbil­dung 2.5: 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 genau zu den “eige­nen” Requi­re­ments (mit­tel­ers Recht­eck mit den Anfor­de­run­gen A1 bis A5 in Abbil­dung 3.1) gehört, kann über den → Sys­tem­kon­text oder über den Requi­re­ments-Pro­zess fest­ge­legt wer­den. Die Pre- und Post-Traces wer­den idea­ler­wei­se über das ein­ge­setz­te → RE-Tool erfasst.

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­ne 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 Stake­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 Stake­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 Stake­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 Stake­hol­der-Anfor­de­run­gen vor­han­den sind

5. Traces zwischen Anforderungen, Testfällen und Source Code

Traces sind ins­be­son­de­re bei der Soft­ware­ent­wick­lung hilf­reich, wenn es dar­um geht, Ver­bin­dun­gen zwi­schen den Anfor­de­run­gen, Test­fäl­len und dem Source Code her­zu­stel­len. In Abbil­dung 5.1 ist bei­spiel­haft eine Anfor­de­rung dar­ge­stellt, aus der sich Test­fäl­le und Source Code ableiten.

Zusammenhang Anforderung, Testfall und Source Code über Traces, (C) Peterjohann Consulting, 2021-]lj]

Abbil­dung 5.1: Zusam­men­hang Anfor­de­rung, → Test­fall und Source Code über Traces

Anmer­kung:
Die Rei­hen­fol­ge der Ent­wick­lung ist über die Abbil­dung 5.1 nicht fest­ge­legt. In der Regel wer­den jedoch zunächst die Anfor­de­run­gen erfasst, anschlie­ßend die Test­fäl­le beschrie­ben und dann der Source Code erstellt.

6. 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” ist 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 Stake­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 Stake­hol­der-Anfor­de­run­gen, die Traces sind vertikal

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

8. 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 (Stake­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.

Inhalt Typ
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
  • /Ebert22/ Chris­tof Ebert: Sys­te­ma­ti­sches Requi­re­ments Engi­nee­ring. Anfor­de­run­gen ermit­teln, doku­men­tie­ren, ana­ly­sie­ren und ver­wal­ten, dpunkt, Hei­del­berg 7. Auf­la­ge 2022, ISBN 978–3‑86490–919‑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 (all­ge­mein)
/*/ Ver­weis auf eine Web­site, die als Ergän­zung zu einem Buch dient
/#/ Ver­weis auf ein ein­zel­nes The­ma auf einer Website
/#V/ Ver­weis auf ein Video auf einer Website