Das Dokumentieren von Anforderungen Eine Haupttätigkeit im Requirements Engineering

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Das Doku­men­tie­ren (engl. Docu­men­ting) von Anfor­de­run­gen ist eine der Haupt­tä­tig­kei­ten im → Requi­re­ments Engi­nee­ring.
In die­sem Bei­trag wird das Doku­men­tie­ren mit sei­nen Pro­zes­sen, Werk­zeu­gen und Metho­den beschrieben.

In die­sem Bei­trag wird das Requi­re­ments Engi­nee­ring in die Berei­che Anfor­de­rungs­ent­wick­lung (Requi­re­ments Deve­lo­p­ment) und → Anfor­de­rungs­ver­wal­tung (→ Requi­re­ments Manage­ment) unter­teilt, wobei die­se wie­der­um in die vier Haupt­tä­tig­kei­ten (auch Hauptaktivitäten) …

• Ermit­teln (Eli­ci­ting),
• Doku­men­tie­ren (Docu­men­ting),
• Vali­die­ren (Vali­da­ting) und
• Ver­wal­ten (Mana­ging)

unter­glie­dert wer­den kön­nen (Abbil­dung 0.1). Im Fokus die­ses Bei­trags steht das Doku­men­tie­ren der Anforderungen.

Abbil­dung 0.1: Die Unter­tei­lung des Requi­re­ments Engi­nee­rings — Fokus “Doku­men­tie­ren”

Die Pro­zess­sicht auf das Doku­men­tie­ren von Anfor­de­run­gen ist in Abbil­dung 0.2 dargestellt.

Abbil­dung 0.2: Pro­zes­se im Requi­re­ments Engi­nee­rings nach → IREB — Fokus “Doku­men­tie­ren”

Ach­tung:
Doku­men­tie­ren ist nicht der Doku­men­ta­ti­on gleich­zu­set­zen: Das Doku­men­tie­ren beschreibt eine → Tätig­keit und die Doku­men­ta­ti­on eine (schrift­li­che) Beschrei­bung der Anfor­de­run­gen. Also ist die Anfor­de­rungs­do­ku­men­tie­rung nicht der Anfor­de­rungs­do­ku­men­ta­ti­on gleichzusetzen.

1. Einleitung und Grundlagen

1.1 Definitionen

Das Doku­men­tie­ren von Anfor­de­run­gen beschäf­tigt sich mit zwei Aspekten:

1. Zum einen mit Einzelanforderungen
2. Zum ande­ren mit dem Zusam­men­stel­len von (Einzel-)Anforderungen in einem Dokument

Abbil­dung 1.1: Aspek­te des Dokumentierens

1.2 Abgrenzung zum Dokumentieren von Code

Das Doku­men­tie­ren von Anfor­de­run­gen ist zu unter­schei­den von Doku­men­tie­ren von Code: Beim Doku­men­tie­ren von Anfor­de­run­gen geht es dar­um, war­um etwas gemacht wer­den muss, die Doku­men­ta­ti­on von Source Code dient in ers­ter Linie der Maintenance.

Abbil­dung 1.2: Das Doku­men­tie­ren von Anfor­de­run­gen und Source Code — Unterschiede

2. Das Dokumentieren von Einzelanforderungen

Ein­zel­an­for­de­run­gen kön­nen entweder …

• natür­lich­sprach­lich (oder auch natürlichsprachig),
• modell­ba­siert oder
• als Misch­form beschrie­ben werden.

Abbil­dung 2.1: Die Doku­men­ta­ti­ons­for­men (nach IREB /IREB21/)

In der Pra­xis wer­den alle For­men eingesetzt.

2.1 Die Satzschablone

→ Satz­scha­blo­nen die­nen der Erfas­sung von Ein­zel­an­for­de­run­gen: Durch Vor­ga­ben einer for­ma­len (syn­tak­ti­schen) Struk­tur wer­den ein­zel­ne Anfor­de­run­gen in vor­ge­ge­be­ner Art und Wei­se in jeweils einem Satz beschrieben.

Bei Rupp /Rupp14/ wird die Satz- oder → Anfor­de­rungs­scha­blo­ne wie folgt defi­niert:
“Eine Anfor­de­rungs­scha­blo­ne ist ein Bau­plan, der die Struk­tur eines ein­zel­nen Anfor­de­rungs­sat­zes festlegt.”

Abbil­dung 2.2: Die → Satz­scha­blo­ne

Wenn Satz­scha­blo­nen kon­se­quent und rich­tig ein­ge­setzt wer­den, redu­ziert sich der Inter­pre­ta­ti­ons­spiel­raum erheb­lich — die Anfor­de­run­gen wer­den ein­deu­ti­ger. Aller­dings wir­ken (Samm­lun­gen von) Anfor­de­run­gen auf Basis von Satz­scha­blo­nen häu­fig sehr ein­tö­nig und damit lang­wei­lig lesbar.

2.2 Modellbasiertes Dokumentieren von Einzelanforderungen

Ein­zel­ne Anfor­de­run­gen kön­nen model­liert wer­den — dies geschieht in der Regel, wenn die ein­zel­ne Anfor­de­rung → kom­plex ist und nicht ein­fach tex­tu­ell beschrie­ben wer­den kann. Dabei kom­men häu­fig Model­le zum Ein­satz, die auf der → UML basieren.

2.3 Mischformen beim Dokumentieren von Einzelanforderungen

Häu­fig wer­den kom­men sowohl tex­tu­el­le als auch modell­ba­sier­te Tei­le bei der Doku­men­ta­ti­on von Ein­zel­an­for­de­run­gen zum Einsatz.

3. Das Zusammenstellen von (Einzel-)Anforderungen in einem Dokument

Nach IREB kann das Ergeb­nis der Doku­men­ta­ti­on eine Samm­lung von Ein­zel­an­for­de­rung sein, die als Anfor­de­rungs­spe­zi­fi­ka­ti­on bezeich­net wer­den kann. Im → Glos­sar wird dazu defi­niert /#IREB-Glossar-24/: “Anfor­de­rungs­spe­zi­fi­ka­ti­on: Requi­re­ments spe­ci­fi­ca­ti­on: A sys­te­ma­ti­cal­ly repre­sen­ted coll­ec­tion of requi­re­ments, typi­cal­ly for a sys­tem, that satis­fies given cri­te­ria.”
(Eige­ne Über­set­zung: “Anfor­de­rungs­spe­zi­fi­ka­ti­on: Eine sys­te­ma­tisch dar­ge­stell­te Samm­lung von Anfor­de­run­gen, typi­scher­wei­se für ein Sys­tem, das bestimm­te Kri­te­ri­en erfüllt.”)

In der Anfor­de­rungs­spe­zi­fi­ka­ti­on somit wer­den die ermit­tel­ten Anfor­de­run­gen in eine Form gebracht, die es erlaubt, sowohl mit den Kun­den / Stake­hol­dern als auch mit den Ent­wick­lern ein Gesamt­bild des zu erstel­len­den Pro­dukts zu gene­rie­ren. Hier­zu kön­nen Glie­de­rungs­vor­la­gen für Doku­men­te ein­ge­setzt wer­den — in der Pra­xis wer­den (im deutsch­spra­chi­gen Raum) häu­fig verwendet:

• Das Vole­re-Tem­p­la­te von Suzan­ne und James Robert­son /VOLERE/
• Die Struk­tur für Soft­ware Requi­re­ments Spe­ci­fi­ca­ti­on (SRS) nach IEEE 830‑1998
• Die Doku­men­ten­struk­tur nach dem → V‑Modell XT /V‑­Mo­dell-XT/

Im deutsch­spra­chi­gen Raum wer­den Anfor­de­rungs­do­ku­men­te häu­fig auch als → Las­ten­heft und → Pflich­ten­heft bezeich­net — Eine Beschrei­bung die­ser Begrif­fe fin­den Sie in dem Bei­trag “→ Las­ten­heft und Pflich­ten­heft”.

4. Zum Umfang und zur Qualität von Anforderungsdokumenten

Die Anfor­de­rungs­do­ku­men­te kön­nen bei Umfang und → Qua­li­tät star­ke Unter­schie­de auf­wei­sen. Inner­halb eines Requi­re­ments-Engi­nee­ring-Vor­ha­bens soll­ten daher vor­ab Betrach­tun­gen vor­ge­nom­men wer­den, wel­chen Umfang und wel­che Qua­li­tät gewünscht oder gefor­dert wird. Wenn gro­ßer Umfang und hohe Qua­li­tät gefor­dert ist, so treibt das den → Auf­wand und damit die Kos­ten hoch. 

Zur schnel­len Fest­le­gung kann ein ein­fa­ches Sche­ma ein­ge­setzt wer­den (Abbil­dung 4.1). Wenn Anfor­de­rungs­do­ku­men­te nur erstellt wer­den, weil dies vor­ge­ge­ben ist, so kön­nen sol­che Ali­bi-Doku­men­te auch vom Umfangs- und Qua­li­täts­sei­te her redu­ziert wer­den — “es liest ohne­hin nie­mand”. Bei häu­fig genutz­ten Arbeits-Doku­men­ten kann das deut­lich anders aus­se­hen: Hier soll­te dann eine Abschät­zung für Umfang, Qua­li­tät und der damit ver­bun­de­nen Kos­ten erfolgen.

Abbil­dung 4.1: Umfang und Qua­li­tät von Anforderungsdokumenten

Zudem kön­nen sich die Adres­sa­ten von Anfor­de­rungs­do­ku­men­ten unter­schei­den. Wenn tech­ni­sche Tie­fe gefor­dert ist, weil bei­spiels­wei­se Tech­ni­ker dies spä­ter im Pro­duk­tiv­um­feld als Nach­schla­ge­werk benö­ti­gen, so sind meis­tens die → Auf­wän­de zur Erstel­lung sol­cher Anfor­de­rungs­do­ku­men­te hoch.

5. Häufig gestellte Fragen und Antworten (FAQ) zum Dokumentieren von Anforderungen

Eini­ge Fra­gen zum Doku­men­tie­ren von Anfor­de­run­gen wer­den häu­fig gestellt – die­se wer­den hier wie­der­ge­ge­ben und beantwortet.

• F: Muss der → Requi­re­ments Engi­neer eine spe­zi­fi­sche Aus­bil­dung für das Doku­men­tie­ren haben?
  A: Ja. Beim Doku­men­tie­ren von Anfor­de­run­gen soll­ten Hilfs­mit­tel wie Satz­scha­blo­nen oder Model­le (typi­scher­wei­se unter Ver­wen­dung der UML) zum Ein­satz kom­men. Die­se müs­sen trai­niert werden.
• F: Wie groß ist typi­scher­wei­se der Auf­wand zum Doku­men­tie­ren von Anfor­de­run­gen in einem → Vor­ha­ben?
  A: Als “gro­be Richt­schnur” kann etwa 20 bis 60 % des Gesamt­auf­wands für ein RE-Vor­ha­ben für das Doku­men­tie­ren ein­kal­ku­liert wer­den. Häu­fig geht das Doku­men­tie­ren mit den Doku­men­ta­ti­ons­ar­te­fak­ten in das Pro­dukt­ma­nage­ment / in die Pro­dukt­pfle­ge über, sodass hier lang­fris­ti­ger Pfle­ge­auf­wand ent­steht, der jedoch nicht mehr zum Ursprungs-RE-Vor­ha­ben gehört.

Haben Sie noch wei­te­re Fra­gen oder möch­ten Sie Ergän­zun­gen an der FAQ vor­neh­men? Am bes­ten schrei­ben Sie mir hier­zu eine E‑Mail an: kontakt@peterjohann-consulting.de.

A. Präsentationen, Literatur und Weblinks

A.1 Meine öffentliche Präsentation zum Dokumentieren von Anforderungen

Das Doku­men­tie­ren von Anfor­de­run­gen wird in der Prä­sen­ta­ti­on zum Requi­re­ments Engi­nee­ring 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)

A.2 Literatur

1. /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
2. /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
3. /Ebert19/ 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 6. Auf­la­ge 2019, ISBN 978–3‑86490–562‑9
4. /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
5. /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
6. /Naumann18/ Axel-Bru­no Nau­mann: Busi­ness-Ana­ly­se – Sys­te­ma­ti­sches → Anfor­de­rungs­ma­nage­ment für nut­zer­ori­en­tier­te Lösun­gen, Dr. Götz Schmidt, Wet­ten­berg 2018, ISBN 978–3‑945997–11‑6
7. /IREB21/ sie­he /Pohl21/
8. /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
9. /Pohl21/ auch /IREB21/ Klaus Pohl, Chris Rupp: Basis­wis­sen Requi­re­ments Engi­nee­ring: Aus- und Wei­ter­bil­dung nach IREB-→ Stan­dard zum Cer­ti­fied Pro­fes­sio­nal for Requi­re­ments Engi­nee­ring Foun­da­ti­on Level, dpunkt, Hei­del­berg 5. Auf­la­ge 2021, ISBN 978–3‑86490–814‑9
10. /Robertson12/ Suzan­ne Robert­son, James Robert­son: Mas­te­ring the Requi­re­ments Pro­cess, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 3rd Edi­ti­on 2012, ISBN 978–0‑321–81574‑3
11. /Rupp14/ Chris Rupp: Requi­re­ments-Engi­nee­ring und ‑Manage­ment. Aus der Pra­xis von klas­sisch bis agil, Han­ser, Mün­chen 6. Auf­la­ge 2014, ISBN 978–3‑446–43893‑4
12. /Rupp20/ Chris Rupp: Requi­re­ments-Engi­nee­ring und ‑Manage­ment. Das Hand­buch für Anfor­de­run­gen in jeder Situa­ti­on, Han­ser, Mün­chen 7. Auf­la­ge 2020, ISBN 978–3‑446–45587‑0
13. /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

A.3 Weblinks

• /IREB/ IREB – Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board: Web­site (deut­sche Fassung)
• /#IREB-Glossar-24/ IREB – Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board: Glos­sar des IREB, Ver­si­on 2.1.1 vom April 2024 (deutsch, eng­lisch, pdf-Datei, 65 Seiten)

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 

Letz­te Aktua­li­sie­rung: 02.04.2022 © Peter­jo­hann Con­sul­ting, 2005–2024