Der Start eines Requirements-Projekts Diese ersten Schritte sollten immer durchgeführt werden

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Der Start eines Requi­re­ments-Pro­jekts (genau­er: Requi­re­ments-Engi­nee­ring-Pro­jekts) soll­te in einem geord­ne­ten Pro­zess erfol­gen, noch bevor die eigent­li­che Ermitt­lung beginnt.
In die­sem Bei­trag wird ein neun­stufi­ges Vor­ge­hen zum Start eines Requi­re­ments-Pro­jekts vorgestellt.

Um mit einem Requi­re­ments-Pro­jekt (hier auch RE-Pro­jekt genannt) zu star­ten, soll­te vor­ab geklärt sein, ob …

  • genü­gend Res­sour­cen und Finanz­mit­tel zur Durch­füh­rung vor­han­den sind.
  • die → Zie­le des Pro­jekts allen Betei­lig­ten klar sind.

Der Start eines RE-Pro­jekts fin­det vor den “klas­si­schen” drei Schrit­ten des Requi­re­ments Engi­nee­rings statt.

Einordnung des Starts eines RE-Projekts, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 0.1: Ein­ord­nung des Starts eines RE-Projekts

Dann sind im Ein­zel­nen vor dem Start der eigent­li­chen → Anfor­de­rungs­er­mitt­lung fol­gen­de Schrit­te durchzuführen:

  1. Bestim­men der → Visi­on und des Ziels des RE-Vorhabens
  2. Ermit­teln des Sys­tems und des Systemkontexts
  3. Bestim­men der → Stake­hol­der
  4. Bestim­men von → Per­so­nas und Szenarios
  5. Anle­gen / Aus­bau­en eines Glossars
  6. Auf­bau­en eines über­ge­ord­ne­ten → Use Cases
  7. Ein­set­zen des → Kano-Modells
  8. Zusam­men­stel­len / Berech­nen der “pas­sen­den” → Ermitt­lungs­tech­ni­ken
  9. Beginn des Ermit­telns der Anforderungen

Hin­weis:
Der sys­te­ma­ti­sche Start eines RE-Pro­jekts ist in der Lite­ra­tur nicht ein­deu­tig beschrie­ben. Das hier beschrie­be­ne Vor­ge­hen stammt daher von mir und basiert auf mei­nem Know-how und mei­nen Erfahrungen.

Wo kann ich Sie unter­stüt­zen?
Beim Start eines RE-Pro­jekts wer­den häu­fig → Feh­ler gemacht, deren Aus­wir­kun­gen sich erst im wei­te­ren Ver­laufs des Pro­jekts zei­gen und dann nur schwer zu kor­ri­gie­ren sind. Daher bie­te ich zum Start eines Requi­re­ments-Pro­jekts mei­ne → Dienst­leis­tun­gen und Work­shops an, um die Feh­ler­fal­len zu erken­nen und die Feh­ler zu minimieren.

1. Bestimmen der Vision und des Ziels des RE-Vorhabens

Das Ziel des RE-Vor­ha­bens soll­te unbe­dingt zu Beginn aller RE-Akti­vi­tä­ten geklärt wer­den. Hier­zu bie­tet es sich an, → Mis­si­on und Visi­on des Unter­neh­mens zusam­men mit den Visio­nen und Zie­len des RE-Vor­ha­bens zu betrachten.

Der Unter­schied von Mis­si­on, Visi­on und Ziel ist in Abbil­dung 1.1 wiedergegeben.

Einordnung von Vision und Zielen bei einem RE-Projekt, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 1.1: Ein­ord­nung von Visi­on und Zie­len bei einem RE-Projekt

Wei­te­re Infor­ma­tio­nen zur Ermitt­lung der → Pro­dukt­vi­si­on Sie hier auf der Web­sei­te → Pro­dukt­vi­si­on.

2. Ermitteln des Systems und des Systemkontexts

Es ist sehr wich­tig, das Sys­tem und den → Sys­tem­kon­text abzu­gren­zen, um zu erfas­sen, was “dazu­ge­hört und was nicht”. Nur was zum Sys­tem und Sys­tem­kon­text gehört muss in einem RE-Pro­jekt berück­sich­tigt wer­den, alles ande­re nicht. Das Sys­tem und der Sys­tem­kon­text kann gut über ein Sys­tem­kon­text-Dia­gramm visua­li­siert wer­den, wel­ches in Abbil­dung 2.1 dar­ge­stellt ist.

System und Systemkontext, (C) Peterjohann Consulting, 2018-2024

Abbil­dung 2.1: Sys­tem und Systemkontext

Wei­te­re Infor­ma­tio­nen zum Ermit­teln des Sys­tems und des Sys­tem­kon­texts fin­den Sie hier auf der Web­sei­te → Sys­tem und Sys­tem­kon­text.

3. Bestimmen der Stakeholder

Die Stake­hol­der sind die­je­ni­gen, die das ent­ste­hen­de Pro­dukt nut­zen sol­len oder bei der Erstel­lung des Pro­dukts betei­ligt sind. In Pro­jek­ten und auch in Requi­re­ments-→ Vor­ha­ben wer­den häu­fig Stake­hol­der erfasst und beschrieben.

Stakeholder: Ziele, Betroffenheit, Macht, (C) Peterjohann Consulting, 2016-2024

Abbil­dung 3.1: Stake­hol­der: Zie­le, Betrof­fen­heit, Macht

In Abbil­dung 3.2 sind eini­ge typi­sche Stake­hol­der dar­ge­stellt. Die Dop­pel­pfei­le in der Abbil­dung ste­hen für zen­tra­le Ansprü­che, die die­se Stake­hol­der an ein (RE-)-Projekt haben.

Stakeholderidentifikation und Gliederung, (C) Peterjohann Consulting, 2016-2024

Abbil­dung 3.2: Stake­hol­der­iden­ti­fi­ka­ti­on und Gliederung

Das Iden­ti­fi­zie­ren von Stake­hol­dern ist eine zen­tra­le Auf­ga­be beim Start eines RE-Projekts.

Wei­te­re Infor­ma­tio­nen zur Ermitt­lung und Behand­lung von Stake­hol­dern fin­den Sie hier auf der Web­sei­te → Stake­hol­der­ma­nage­ment in Pro­jek­ten.

4. Bestimmen von Personas und Szenarios

Per­so­nas sind (fik­ti­ve) Nut­zer, die gan­ze Nut­zer­grup­pen reprä­sen­tie­ren. Anhand von Per­so­nas kön­nen Anwen­dungs­sze­na­ri­en (auch kurz: Sze­na­ri­os) auf­ge­baut wer­den, die dann Hin­wei­se auf die (wich­tigs­ten) Anwen­dungs­fäl­le geben.

Um von den Stake­hol­dern zu Per­so­nas zu gelan­gen, kön­nen die erfass­ten Stake­hol­der auf die Nut­zer des zu erstel­len­den Pro­dukts (oder der Dienst­leis­tung) ein­ge­schränkt wer­den: Es ent­ste­hen so die Nut­zer­grup­pen, die dann häu­fig auch geclus­tert werden.

Von den Stakeholdern zu den Personas, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 4.1: Von den Stake­hol­dern zu den Personas

Aus den Nut­zer­grup­pen wer­den die rele­van­tes­ten her­aus­ge­nom­men und für die­se die Per­so­nas erstellt.

Es kön­nen bei Per­so­nas eine Rei­he von Eigen­schaf­ten oder Merk­ma­len erfasst wer­den – hier­zu gehö­ren (Abbil­dung 4.2):

  • Name
  • Alter
  • Mot­to oder Zitat
  • Beruf
  • Ein­kom­men
  • Wohn­ort
  • Wohn­si­tua­ti­on
  • Hob­bys
  • Bezug zum Produkt
Personas-Attribute über ein Mindmap, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 4.2: Per­so­nas-Attri­bu­te über ein Mindmap

Wei­te­re Infor­ma­tio­nen zum Bestim­men von Per­so­nas fin­den Sie hier auf der Web­sei­te → Per­so­nas.

5. Anlegen / Ausbauen eines Glossars

In dem → Fachglos­sar zu einem RE-Pro­jekt wer­den Begrif­fe auf­ge­führt, die in dem spe­zi­fi­schen Kon­text wich­tig sind.

Aufbau eines Glossars (schematisch), (C) Peterjohann Consulting, 2020-2024

Abbil­dung 5.1: Auf­bau eines Glos­sars (sche­ma­tisch)

Wei­te­re Infor­ma­tio­nen zum Erstel­len und Ver­wen­den von Glos­sa­ren fin­den Sie hier auf der Web­sei­te → Das Glos­sar.

6. Aufbauen eines übergeordneten Use Cases

Der ers­te → Use Case zeigt den über­ge­ord­ne­ten Rah­men für das RE-Vor­ha­ben auf. Abbil­dung 6.1 einen ein­fa­chen Use Case.

Ein einfaches Beispiel eines Use-Case-Modells, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 6.1: Ein ein­fa­ches Bei­spiel eines Use-Case-Modells

Wei­te­re Infor­ma­tio­nen zum Auf­bau­en eines Use Cases fin­den Sie hier auf der Web­sei­te → Use Cases.

7. Einsetzen des Kano-Modells

Über das → Kano-Modell kön­nen die soge­nann­ten Basis‑, Leis­tungs- und Begeis­te­rungs­fak­to­ren beschrie­ben wer­den. Hier­über ist es mög­lich, mit Hil­fe der Zie­le oder Unter­zie­le zu visua­li­sie­ren, ob das RE-Vor­ha­ben “genü­gend her­aus­for­dernd” ist — und damit einen Bei­trag zur Wert­schöp­fung lie­fern kann.

Das Kano-Diagramm: Darstellung, (C) Peterjohann Consulting, 2014-2024

Abbil­dung 7.1: Das → Kano-Dia­gramm: Dar­stel­lung

Zudem zeigt der Ein­satz des Kano-Dia­gramms auf, wel­che Arten von Ermitt­lungs­tech­ni­ken zum Ein­satz kom­men sollten.

Wei­te­re Infor­ma­tio­nen zum Kano-Modell fin­den Sie hier auf der Web­sei­te → Das Kano-Modell.

8. Zusammenstellen der “passenden” Ermittlungstechniken

Aus dem Kano-Modell und den gene­rell ver­füg­ba­ren Res­sour­cen ergibt sich, wel­che Ermitt­lungs­tech­ni­ken zum Ein­satz kom­men kön­nen und soll­ten. Dabei wer­den aus der Viel­zahl der Tech­ni­ken die pas­sen­den zusam­men­ge­stellt. → Inter­views und → Brain­stor­ming kom­men in der Regel immer zum Ein­satz, bei ande­ren Tech­ni­ken muss genau betrach­tet wer­den, wel­chen Nut­zen sie im RE-Pro­jekt zu wel­chen Kos­ten bringen.

Die Ermittlungstechniken nach IREB, (C) Peterjohann Consulting, 2021-2024

Abbil­dung 8.1: Die Ermitt­lungs­tech­ni­ken (nach → IREB /IREB21/)

Wei­te­re Infor­ma­tio­nen zum Zusam­men­stel­len der “pas­sen­den” Ermitt­lungs­tech­ni­ken fin­den Sie hier auf der Web­sei­te → Ermitt­lungs­tech­ni­ken für das Requi­re­ments Engi­nee­ring.

9. Beginnen des Ermittelns der Anforderungen

Sind alle Vor­ar­bei­ten erle­digt, kann mit der eigent­li­chen Ermitt­lung begon­nen wer­den. Hier­bei soll­te unbe­dingt früh­zei­tig eine Auf­wands­ab­schät­zung erfol­gen: Es müs­sen die → Auf­wän­de für die Betei­lig­ten geklärt werden.

Wei­te­re Infor­ma­tio­nen zum Beginn des Ermit­telns von Anfor­de­run­gen (in einem RE-Pro­jekt) fin­den Sie hier auf der Web­sei­te → Das Ermit­teln von Anfor­de­run­gen.

10. Häufig gestellte Fragen und Antworten (FAQ) zum Start eines Requirements-Engineering-Projekts

Eini­ge Fra­gen zu dem RE-Start wer­den häu­fig gestellt – die­se wer­den hier wiedergegeben.

  • F: Müs­sen vor Beginn der Ermitt­lungs­tä­tig­kei­ten alle Schrit­te des RE-Starts durch­lau­fen wer­den?
    A: Ja. Dies ist sinn­voll. Lei­der wird dies häu­fig ver­ges­sen, was sich dann spä­ter bemerk­bar machen kann.
  • F: Wel­che Doku­men­te / Arte­fak­te / Ergeb­nis­se des RE-Starts kann man im spä­te­ren RE-Ver­lauf wie­der- oder wei­ter­ver­wen­den?
    A: Alle. Alle Arte­fak­te, die beim RE-Start erstellt wer­den, kön­nen im RE-Pro­jekt wei­ter­ver­wen­det wer­den. Aller­dings muss beach­tet wer­den, dass das Up-to-date-Hal­ten der ein­zel­nen Arte­fak­te → Auf­wand ver­ur­sacht — ent­spre­chend muss der Nut­zen der Arte­fak­te früh geklärt werden.

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

Der “Start eines Requi­re­ments-Pro­jekts” wird in mei­ner Prä­sen­ta­ti­on zum → Requi­re­ments Engi­nee­ring beschrie­ben. Zudem gibt es ein DIN-A3-→ Pos­ter, wel­ches die hier vor­ge­stell­ten Schrit­te zusammenfasst.

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
Requi­re­ments Engi­nee­ring: Der Start eines Requi­re­ments-Engi­nee­ring-Pro­jekts –
Die­se ers­ten Schrit­te soll­ten immer durch­ge­führt wer­den (DIN-A3-Pos­ter)
pdf

In fol­gen­den Büchern wer­den als Teil­aspekt “Start eines Requi­re­ments-Pro­jekts” erläutert:

  • /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
  • /IREB21/ sie­he /Pohl21/
  • /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
  • /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
  • /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

Auf fol­gen­de Web­links zum “Start eines Requi­re­ments-Pro­jekts” wird hier Bezug genommen:

  • /IREB/ IREB – Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board: Web­site (deut­sche Fassung)

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