Prozesse im Requirements Engineering Unterteilung des Vorgehens in einzelne Ablaufschritte

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Pro­zes­se im → Requi­re­ments Engi­nee­ring geben vor, in wel­cher Rei­hen­fol­ge Anfor­de­run­gen ermit­telt, doku­men­tiert, vali­diert und bei Bedarf ver­wal­tet wer­den.
In die­sem Bei­trag wer­den Pro­zes­se und Vor­ge­hens­mo­del­le für das Requi­re­ments Engi­nee­ring beschrieben.

Hin­weis:
Grund­sätz­lich kann das Requi­re­ments Engi­nee­ring über Pro­zes­se gesteu­ert wer­den. Nach → IREB gibt es jedoch nur einen Requi­re­ments-Engi­nee­ring-Pro­zess (RE-Pro­zess), der ledig­lich ange­passt wer­den muss. Die­se Sicht- und Sprech­wei­se weicht von der Sicht­wei­se im → Pro­jekt­ma­nage­ment ab. In die­sem Bei­trag kön­nen Pro­zes­se — abwei­chend von der IREB-Sicht — auch Teil eines Gesamt-RE-Pro­zes­ses sein.

1. Einleitung und Grundlagen

1.1 Definitionen

Im → Glos­sar des IREB steht zum Pro­zess /#IREB-Glossar-24/:
“A set of inter­re­la­ted acti­vi­ties per­for­med in a given order to pro­cess infor­ma­ti­on or mate­ri­als.“
Die deut­sche Über­set­zung lau­tet:
“Eine Rei­he von zusam­men­hän­gen­den Tätig­kei­ten, die in einer bestimm­ten Rei­hen­fol­ge aus­ge­führt wer­den, um Infor­ma­tio­nen oder Mate­ria­li­en zu verarbeiten.”

Die­se Defi­ni­ti­on lässt Spiel­räu­me, denn damit kön­nen sowohl umfang­rei­che als auch wenig auf­wen­di­ge The­men gemeint sein.

Wesent­lich ist, dass es kei­nen Uni­ver­sal-RE-Pro­zess für alle Arten von RE-→ Vor­ha­ben gibt, son­dern dass ein RE-Pro­zess vor­ab pas­send zusam­men­ge­stellt wer­den muss. 

1.2 Der RE-Prozess nach IREB

Der RE-Pro­zess des IREB unter­teilt 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), wobei die­se wie­der­um in die vier Haupt­tä­tig­kei­ten (auch Haupt­ak­ti­vi­tä­ten oder Prozessschritte) …

  • 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 1.1). Die Pfei­le sym­bo­li­sie­ren eine Abar­bei­tungs­rei­hen­fol­ge, wobei die gepunk­te­ten Pfei­le mög­li­che Rück­sprün­ge aufzeigen.

Der Prozess für das Requirements Engineerings nach IREB, (C) Peterjohann Consulting, 2023-2024

Abbil­dung 1.1: Der Pro­zess für das Requi­re­ments Engi­nee­rings nach IREB

Das → Ver­wal­ten von Anfor­de­run­gen ist nicht in eine Pro­zess­rei­hung ein­ge­bun­den und hier nur der Voll­stän­dig­keit hal­ber dargestellt.

1.3 Der RE-Prozess nach Wiegers

Bei Wie­gers fin­det sich ein RE-Pro­zess (nur für die Anfor­de­rungs­ent­wick­lung), der gro­ße Ähn­lich­kei­ten mit dem IREB-Pro­zess auf­weist (Abbil­dung 1.2). Das Docu­men­ting aus dem IREB-Pro­zess ist auf­ge­teilt in Ana­ly­sis und Spe­ci­fi­ca­ti­on. Zudem wer­den bei den Rück­sprün­gen Tätig­kei­ten benannt.

Der RE-Prozess nach Wiegers, (C) Peterjohann Consulting, 2023-2024

Abbil­dung 1.2: Der RE-Pro­zess nach Wie­gers /Wiegers23/

1.4 Die Einbettung des Requirements-Engineering-Prozesses

Ein Requi­re­ments-Engi­nee­ring-Pro­zess ist immer in einen über­span­nen­den Pro­jekt- oder Pro­dukt­pro­zess ein­ge­bun­den (Abbil­dung 1.3). Zudem erfolgt die Sys­tem- oder → Soft­ware­ent­wick­lung über den Sys­tem­ent­wick­lungs­pro­zess in enger Abstim­mung mit dem Requi­re­ments-Engi­nee­ring-Pro­zess, zwi­schen bei­den gibt es Rückkopplungen.

Die Einbettung des RE-Prozesses, (C) Peterjohann Consulting, 2023-2024

Abbil­dung 1.3: Die Ein­bet­tung des RE-Prozesses

2. Einflussfaktoren auf den Requirements-Engineering-Prozess

Das IREB benennt neun Ein­fluss­fak­to­ren auf den Requi­re­ments-Engi­nee­ring-Pro­zess (Abbil­dung 2.1). Dies sind:

  1. Eig­nung im Gesamt­pro­zess (eng­lisch: Over­all pro­cess fit): Der RE-Pro­zess muss zum Gesamt­ent­wick­lungs­pro­zess passen
  2. Ent­wick­lungs­kon­text (Deve­lo­p­ment con­text): Hier­bei geht es in ers­ter Linie um Art der Zusam­men­ar­beit und Ver­trau­en zwi­schen den Betei­lig­ten. Es muss beach­tet wer­den, wie die Kun­den-Lie­fe­ran­ten-Bezie­hung ist, wie ein Ver­trag aus­ge­stal­tet ist und wer wel­che Tätig­kei­ten übernimmt 
  3. Fähig­keit und Ver­füg­bar­keit von Stake­hol­dern (Capa­bi­li­ty and avai­la­bi­li­ty of stake­hol­ders): Ein zen­tra­ler Punkt ist die Fähig­keit und Ver­füg­bar­keit der → Stake­hol­der. Wenn die Stake­hol­der nicht oder kaum ver­füg­bar sind, so kön­nen ent­spre­chend → Inter­views nur ein­ge­schränkt genutzt wer­den. Sind die Stake­hol­der in der Lage, in Requi­re­ments-Engi­nee­ring-Struk­tu­ren zu den­ken, so kann dies das RE-Vor­ha­ben beschleunigen
  4. Gemein­sa­mes Ver­ständ­nis (Shared under­stan­ding): Wenn es bereits ein gemein­sa­mes Ver­ständ­nis der Betei­lig­ten über die Fach­do­mä­ne gibt, so kön­nen die Vor­lauf- oder Ein­ar­bei­tungs­the­men kurz behan­delt wer­den. Zudem kann ein leicht­ge­wich­ti­ge Vor­ge­hen gewählt werden
  5. → Kom­ple­xi­tät und Kri­ti­k­ali­tät des zu ent­wi­ckeln­den Sys­tems (Com­ple­xi­ty and Cri­ti­cal­i­ty to be deve­lo­ped): Je kom­ple­xer oder kri­ti­scher das zu ent­wi­ckeln­de Sys­tem ist, umso mehr muss detail­liert spe­zi­fi­ziert wer­den. Ein Sys­tem, wel­ches ein hohes Maß an Sicher­heit (“→ Safe­ty und → Secu­ri­ty”) ver­langt, soll­te eine ande­re Form des RE-Pro­zes­ses ver­wen­den als ein­fa­che Sys­te­me (wie bei­spiels­wei­se eine Informations-Website)
  6. Rand­be­din­gun­gen (Cons­traints): Der RE-Pro­zess kann durch orga­ni­sa­to­ri­sche Vor­ga­ben ein­ge­schränkt wer­den. Eben­so kann es von (außen kom­men­de) regu­la­to­ri­sche Vor­ga­ben geben, wie bei­spiels­wei­se ein­zu­hal­ten­de Geset­ze, Nor­men oder Standards
  7. Ver­füg­ba­re Zeit und Bud­get (Available time and bud­get): Die ver­füg­ba­re Zeit und das ver­füg­ba­re Bud­get haben Ein­fluss auf das RE-Vor­ha­ben und damit auf den RE-Pro­zess. Aber Ach­tung: Die­ser Ein­fluss­fak­tor kann im Wider­spruch zur Durch­führ­bar­keit eines Vor­ha­bens ste­hen: Wenn Zeit oder Bud­get nicht aus­rei­chend zur Ver­fü­gung ste­hen, kann das RE-Vor­ha­ben nicht erfolg­reich abge­schlos­sen werden
  8. Vola­ti­li­tät von 
Anfor­de­run­gen (Vola­ti­li­ty of requi­re­ments): Wenn sich die Anfor­de­run­gen im Lau­fe eines RE-Vor­ha­bens oder RE-Pro­jekts ändern kön­nen, so muss dies der RE-Pro­zess ent­spre­chend berücksichtigen
  9. Erfah­run­gen
 der Requi­re­ments Engi­neers (Expe­ri­ence of requi­re­ments engi­neers): Wenn die Requi­re­ments Engi­neers pas­sen­de Erfah­run­gen haben, so kann dies zur Ver­schlan­kung und Beschleu­ni­gung des RE-Pro­zes­ses führen
Einflussfaktoren auf den Requirements-Engineering-Prozess nach IREB, (C) Peterjohann Consulting, 2023-2024

Abbil­dung 2.1: Ein­fluss­fak­to­ren auf den Requi­re­ments-Engi­nee­ring-Pro­zess nach IREB /IREB-24/

3. Die Facetten des Requirements-Engineering-Prozesses

Das IREB defi­niert “drei Facet­ten” des Requi­re­ments-Engi­nee­ring-Pro­zes­ses (Abbil­dung 3.1) die eine ziel­ge­rich­te­te Anpas­sung des Pro­zes­ses erleich­tern sollen.

Die drei Facet­ten sind:

  • Zeit: Ein RE-Pro­zess kann line­ar oder → ite­ra­tiv sein. Ein linea­res Vor­ge­hen ist in der Regel “schwer­ge­wich­tig”, wäh­rend ein ite­ra­ti­ves Vor­ge­hen “leicht­ge­wich­tig” ist
  • Ziel: Das RE-Pro­dukt und damit ein RE-Pro­zess kann auf den Kun­den oder auf den Markt aus­ge­rich­tet sein
  • Zweck: Ein RE-Pro­zess kann prä­skrip­tiv oder explo­ra­tiv sein. Bei einem prä­skrip­ti­ven wer­den die Anfor­de­run­gen mög­lichst früh und umfas­send beschrie­ben, um auf die­ser Basis ein → Las­ten­heft mit einem Ver­trag erstel­len zu können
Die Facetten des Requirements-Engineering-Prozesses nach IREB, (C) Peterjohann Consulting, 2023-2024

Abbil­dung 3.1: Die Facet­ten des Requi­re­ments-Engi­nee­ring-Pro­zes­ses nach IREB /#IREB-CPRE-FL-Handbuch-24/

Die Bestim­mung der Facet­ten soll­te vor dem → Start eines RE-Pro­jekts erfol­gen. Im Zusam­men­spiel mit den Ein­fluss­fak­to­ren kann dann ein “maß­ge­schnei­der­ter” RE-Pro­zess zusam­men­ge­stellt wer­den. Dabei emp­fiehlt das IREB ein Vor­ge­hen in fünf Schrit­ten /#IREB-CPRE-FL-24, #IREB-CPRE-FL-Hand­buch-24/ (Abbil­dung 3.2):

  1. Ana­ly­sie­ren der Einflussfaktoren
  2. Beur­tei­len der Facettenkriterien
  3. Kon­fi­gu­rie­ren des Prozesses
  4. Arbeits­pro­duk­te bestimmen
  5. Geeig­ne­te Prak­ti­ken auswählen
Fünf Schritte zur Zusammenstellung eines
 RE-Prozesses nach IREB, (C) Peterjohann Consulting, 2023-2024

Abbil­dung 3.2: Fünf Schrit­te zur Zusam­men­stel­lung eines
 RE-Pro­zes­ses nach IREB /#IREB-CPRE-FL-24/

Hin­weis:
Die Erstel­lung eines “maß­ge­schnei­der­ten” RE-Pro­zes­ses ist nicht tri­vi­al, hat aber enor­me Aus­wir­kun­gen auf Kos­ten und Durch­führ­bar­keit. Daher soll­ten Aus­wahl und Anpas­sung nur durch einen erfah­re­nen → Requi­re­ments Engi­neer oder Bera­ter vor­ge­nom­men werden.

4. Der Einsatz von Prozessen im Requirements Engineering

Über Pro­zes­se kann eine Zuord­nung von Werk­zeu­ge, Metho­den, Auf­ga­ben, Tätig­kei­ten, Arbeits­pro­duk­ten und Prak­ti­ken erfol­gen. Hier­bei kön­nen alle mög­li­chen Ele­men­te zusam­men­ge­tra­gen und dann die nicht-benö­tig­ten “weg­ge­stri­chen” werden.

5. Prozesse in der Business Analysis

Die Sicht auf Pro­zes­se ist in der → Busi­ness Ana­ly­sis nach → IIBA und → PMI eine ande­re: Dort wird der Ablauf über → Wis­sens­ge­bie­te (Know­ledge Are­as) gesteu­ert, die wie­der­um Pro­zes­se oder Tasks beinhalten. 

5.1 Die BA-Tasks beim IIBA

Das IIBA ver­wen­det sechs Wis­sens­ge­bie­te zur Struk­tu­rie­rung des Vor­ge­hens in der Busi­ness Ana­ly­sis, denen wie­der­um 30 Auf­ga­ben / Tasks zuge­ord­net sind. Der Begriff Pro­zes­se wird in die­sem Zusam­men­hang nicht verwendet.

Wissensgebiete und Aufgaben nach IIBA, (C) Peterjohann Consulting, 2023-2024

Abbil­dung 5.1: Wis­sens­ge­bie­te und Auf­ga­ben nach IIBA /BBG15, BBG17‑d/

Auf­ga­ben / Tasks sind bei­spiels­wei­se die fünf Eli­ci­ta­ti­on-Tasks Prepa­re for Eli­ci­ta­ti­on, Con­duct Eli­ci­ta­ti­on, Con­firm Eli­ci­ta­ti­on Results, Com­mu­ni­ca­te Busi­ness Ana­ly­sis Infor­ma­ti­on und Mana­ge Stake­hol­der Col­la­bo­ra­ti­on. Die­sen Tasks kön­nen dann Metho­den zuge­ord­net werden.

5.2 Die BA-Prozesse beim PMI

In Abbil­dung 5.2 sind die sechs Wis­sens­ge­bie­te (Know­ledge Are­as) und sechs Pro­zess­grup­pen (Busi­ness Ana­ly­sis Groups) nach PMI gegen­über­ge­stellt, die Zahl­an­ga­ben stel­len die Anzahl der Pro­zes­se dar. Inge­samt gibt es 35 Pro­zes­se; die vier Pro­zes­se zum → Wis­sens­ge­biet Eli­ci­ta­ti­on hei­ßen Deter­mi­ne Eli­ci­ta­ti­on Appoach (gehört zur Pro­cess Group Plan­ning), Prepa­re for Eli­ci­ta­ti­on, Con­duct Eli­ci­ta­ti­on, Con­duct Eli­ci­ta­ti­on Results (alle drei gehö­ren zu Exe­cu­ting). Den ein­zel­nen Pro­zes­sen wer­den kön­nen dann Tools and Tech­ni­ques (→ Werk­zeu­ge und Metho­den) zuge­ord­net werden.

Wissensgebiete, Prozessgruppen und Prozesse nach PMI, (C) Peterjohann Consulting, 2023-2024

Abbil­dung 5.2: Wis­sens­ge­bie­te, Pro­zess­grup­pen und Pro­zes­se nach PMI /PMG-BA17/

6. Häufig gestellte Fragen und Antworten (FAQ) zu den Prozessen im Requirements Engineering

Eini­ge Fra­gen zu den Pro­zes­sen im Requi­re­ments Engi­nee­ring wer­den häu­fig gestellt – die­se wer­den hier wie­der­ge­ge­ben und beantwortet.

  • F: Müs­sen Pro­zes­se für das Requi­re­ments Engi­nee­ring benannt und beschrie­ben wer­den?
    A: Ja und nein. Bei klei­nen Vor­ha­ben, die mit der Erstel­lung eines Las­ten­hefts been­det sind, wer­den nicht unbe­dingt Pro­zes­se benötigt.
  • F: Wer ist für die Beschrei­bung von Pro­zes­sen im Requi­re­ments Engi­nee­ring ver­ant­wort­lich?
    A: Der zen­tra­le Ansprech­part­ner für die Pro­zes­se im Requi­re­ments Engi­nee­ring ist der­je­ni­ge, der die Pro­zes­se (für das Requi­re­ments Engi­nee­ring) vor­ge­ben darf.

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 zu den Prozessen im Requirements Engineering

Mei­ne Prä­sen­ta­ti­on zu den Werk­zeu­gen und Metho­den im Requi­re­ments Engi­nee­ring ent­hält star­ke Bezü­ge zu den Pro­zes­sen im Requi­re­ments Engineering.

Inhalt Typ
Requi­re­ments Engi­nee­ring: Werk­zeu­ge und Metho­den – Eine Übersicht
pdf

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. /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
  4. /Hruschka23/ 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 3. Auf­la­ge 2023, ISBN 978–3‑446–47692‑9
  5. /IREB21/ sie­he /Pohl21/
  6. /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
  7. /PMG-BA23/ 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 2nd Edi­ti­on 2023, ISBN 978–1‑62825–808‑0
  8. /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
  9. /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
  10. /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
  11. /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
  12. /Wiegers23/ Karl Wie­gers, Can­da­se Hokan­son: Soft­ware Requi­re­ments Essen­ti­als. Core Prac­ti­ces for Suc­cessful Busi­ness Ana­ly­sis, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2023, ISBN 978–0‑13–819028‑6

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