Der Requirements Engineer Aufgaben und Rollenbeschreibung

Manage­ment-Zusam­men­fas­sung zu die­sem Bei­trag:
Der Requi­re­ments Engi­neer (mög­li­che Abkür­zung: REeng) ist für die Ent­wick­lung und Ver­wal­tung von Anfor­de­run­gen in Orga­ni­sa­tio­nen zustän­dig. Was dies kon­kret bedeu­ten kann, soll­te für den jewei­li­gen Kon­text genau defi­niert wer­den, wobei → Rol­len­be­schrei­bun­gen hier­bei hel­fen.
In die­sem Bei­trag wer­den die Auf­ga­ben (und Rol­len) des Requi­re­ments Engi­neers kurz beschrieben.

Die Dar­stel­lung in die­sem Bei­trag ist in ers­ter Linie für Requi­re­ments Engi­neers geschrie­ben — es wird daher davon aus­ge­gan­gen, dass Sie (als Leser) bereits Requi­re­ments Engi­neer sind oder wer­den möch­ten. Der Begriff Busi­ness Ana­lyst wird dem Requi­re­ments Engi­neer gleichgesetzt.

1. Einleitung und Grundlagen

1.1 Definitionen

Im Lehr­plan zum CPRE steht zum Requi­re­ments Engi­neer /→ IREB-20/:
“Requi­re­ments Engi­neer ist typi­scher­wei­se kei­ne Berufs­be­zeich­nung, son­dern eine Rol­le, die Per­so­nen ein­neh­men, die:

  • Als Teil ihrer Auf­ga­ben Anfor­de­run­gen ermit­teln, doku­men­tie­ren, vali­die­ren und / oder verwalten.
  • Über fun­dier­te Kennt­nis­se im RE verfügen.
  • Die Lücke zwi­schen dem → Pro­blem und mög­li­chen Lösun­gen über­brü­cken können.

In der Pra­xis agie­ren Busi­ness-Ana­lys­ten, Anwen­dungs­spe­zia­lis­ten, → Pro­duct Owner, Sys­tem­in­ge­nieu­re und sogar Ent­wick­ler in der Rol­le eines Requi­re­ments Engineers.”

Schreib- und Sprech­wei­sen:
In die­sem Bei­trag wie auch auf die­ser Web­site wird durch­gän­gig der Begriff “Requi­re­ments Engi­neer” benutzt. Fol­gen­de Syn­ony­me fin­den sich in der Lite­ra­tur und Pra­xis: Anfor­de­rungs­in­ge­nieur, Sys­tem­ana­ly­ti­ker, Anfor­de­rungs­ana­ly­ti­ker oder Anfor­de­rungs­ent­wick­ler. Auf die Ver­wen­dung die­ser Syn­ony­me wird verzichtet.

1.2 Das Persönlichkeitsprofil des Requirements Engineers 

Bei Pohl /IREB21/ wer­den sie­ben → Soft Skills für Requi­re­ments Engi­neers benannt, die neben Metho­den­wis­sen und tech­ni­schen Kennt­nis­sen wich­tig sind; die­se wer­den zusam­men­fas­send als Per­sön­lich­keits­pro­fil bezeich­net (Abbil­dung 1.1).

Die Fähig­kei­ten im Einzelnen:

  • Ana­ly­ti­sches Denken
  • Empa­thie
  • Kom­mu­ni­ka­ti­ons­fä­hig­keit
  • Kon­flikt­lö­sungs­fä­hig­keit
  • Mode­ra­ti­ons­fä­hig­keit
  • Selbst­be­wusst­sein
  • Über­zeu­gungs­fä­hig­keit
Das Persönlichkeitsprofil des Requirements Engineers, (C) Peterjohann Consulting, 2020-2022

Abbil­dung 1.1: Das Per­sön­lich­keits­pro­fil des Requi­re­ments Engi­neers (nach /IREB21/)

Ent­spre­chend dem Per­sön­lich­keits­pro­fil muss der Requi­re­ments Engi­neer aus­ge­bil­det oder geschult sein.

1.3 Der Requirements Engineer in agilen Projekten

Die Rol­le des Requi­re­ments Engi­neers gibt es nicht in agi­len Pro­jek­ten: Die Auf­ga­be des Requi­re­ments Engi­nee­rings fällt dort dem Pro­duct Owner zu. Der Pro­duct Owner muss jedoch ähn­lich wie der Requi­re­ments Engi­neer in klas­si­schen Pro­jek­ten arbei­ten — daher sind die Rol­len­be­schrei­bun­gen für den Requi­re­ments Engi­neer auch für den Pro­duct Owner relevant.

2. Die Aufgaben des Requirements Engineers

Der Requi­re­ments Engi­neer agiert übli­cher­wei­se in Pro­jek­ten. Daher gibt es Schnitt­stel­len zu den ver­schie­de­nen Pro­jekt­be­tei­lig­ten. Bei Hrusch­ka /Hruschka19/ sind eini­ge Pro­jekt­be­tei­lig­te benannt und ihre Auf­ga­ben mit Bezug zum Requi­re­ments Engi­neer auf­ge­führt (Abbil­dung 2.1).

Die Aufgaben des Requirements Engineers im Projektkontext, (C) Peterjohann Consulting, 2020-2022

Abbil­dung 2.1: Die Auf­ga­ben des Requi­re­ments Engi­neers im Pro­jekt­kon­text (nach /Hruschka19/)

In ähn­li­cher Form wie Hrusch­ka beschreibt Wie­gers den Aus­tausch (mit Aus­tau­sch­in­for­ma­tio­nen) eines Busi­ness Ana­lys­ten mit den Pro­jekt­be­tei­lig­ten (Abbil­dung 2.2).

Die Aufgaben ses Business Analysten im Projektkontext, (C) Peterjohann Consulting, 2020-2022

Abbil­dung 2.2: Die Auf­ga­ben des Busi­ness Ana­lys­ten im Pro­jekt­kon­text (nach /Wiegers13/)

2.1 Der Requirements Engineer und die Stakeholder

Bei Pohl /IREB21/ wer­den eini­ge Rech­te und Pflich­ten des Requi­re­ments Engi­neers benannt, die in einer “→ Sta­ke­hol­der-Ver­ein­ba­rung” fest­ge­hal­ten wer­den kön­nen. Dort steht:
“Der Requi­re­ments Engineer …

  • spricht die Spra­che der Stakeholder,
  • arbei­tet sich in das Fach­ge­biet gründ­lich ein,
  • erstellt ein Anforderungsdokument,
  • kann die Arbeits­er­geb­nis­se ver­ständ­lich machen (z.B. mit­hil­fe von Dia­gram­men oder Grafiken),
  • pflegt einen respekt­vol­len Umgang mit den Stakeholdern,
  • prä­sen­tiert sei­ne Ideen und Alter­na­ti­ven und deren Realisierung,
  • ermög­licht es den Sta­ke­hol­dern, Eigen­schaf­ten zu for­dern (z.B. um das Sys­tem ein­fach und benut­zer­freund­li­cher zu machen),
  • sorgt dafür, dass die Anfor­de­rungs­spe­zi­fi­ka­tio­nen des zu ent­wi­ckeln­den Sys­tems den funk­tio­na­len und qua­li­ta­ti­ven Ansprü­chen der Sta­ke­hol­der gerecht wird.”

2.2 Der Requirements Engineer in klassischen Projekten

Der Requi­re­ments Engi­neer kann in Pro­jek­te invol­viert sein. Auch wenn die eigent­li­che Auf­ga­be des Requi­re­ments Engi­neer das Erfas­sen und nicht das Umset­zen der Anfor­de­run­gen ist, so hat der Requi­re­ments Engi­neer in der Regel einen sehr guten Über­blick über das von ihm bear­bei­te­te Teil­ge­biet. Daher ist sei­ne Mit­ar­beit in klas­si­schen Pro­jek­ten sinn- und wert­voll. Er nimmt dabei typi­scher­wei­se fol­gen­de Rol­len an:

  • Exper­te: Auf­grund sei­ner Kennt­nis­se über das von ihm erar­bei­te­te Fach­ge­biet, kann / muss der Requi­re­ments Engi­neer immer als Exper­te agie­ren und bei Bedarf sei­ne Expertenmeinung
  • Teil­pro­jekt­ma­na­ger / ‑lei­ter: Es kann sein, dass der Requi­re­ments Engi­neer für die Umset­zung von Teil­pro­jek­ten ver­ant­wort­lich ist. Als Teil­pro­jekt­ma­na­ger soll­te er zumin­dest die Grund­la­gen des Pro­jekt­ma­nage­ments kennen
  • Tech­ni­scher → Pro­jekt­ma­na­ger / ‑lei­ter: Falls das Pro­jekt groß ist und der Pro­jekt­ma­na­ger stark mit der rei­nen Pro­jekt­ab­wick­lung beschäf­tigt ist, kann der Pro­jekt­ma­na­ger auch als tech­ni­scher Pro­jekt­ma­na­ger fun­gie­ren. Ähn­lich wie der Pro­duct Owner beim agi­len Vor­ge­hen, ist er dann Ansprech­part­ner für alle Pro­dukt­the­men im Pro­jekt. Der Pro­jekt­ma­na­ger bleibt zwar gesamt­ver­ant­wort­lich, ver­lässt sich aber bei den Inhal­ten auf den tech­ni­schen Pro­jekt­ma­na­ger, der dem Pro­jekt­ma­na­ger “zuar­bei­tet”

3. Häufige Fragen und Antworten zum Requirements Engineer

Eini­ge Fra­gen zum Requi­re­ments Engi­neer 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 (for­ma­le) Aus­bil­dung haben?
    A: Ja und Nein. Auch wenn es ohne “for­ma­le” Aus­bil­dung mög­lich ist, Anfor­de­run­gen zu ent­wi­ckeln (und zu ver­wal­ten), so hilft eine Aus­bil­dung dabei, die “rich­ti­gen” Anfor­de­run­gen “rich­tig” zu entwickeln.
  • F: Muss es in jedem Pro­jekt einen oder meh­re­re Requi­re­ments Engi­neers geben?
    A: Ja — auch wenn die­se Rol­le viel­fach durch ande­re Rol­len mit aus­ge­führt wird.
  • F: Kann der Requi­re­ments Engi­neers in einem Pro­jekt auch gleich­zei­tig der Pro­jekt­ma­na­ger sein?
    A: Ja. Aber dies soll­te ver­mie­den wer­den, da dann eine Kon­troll­in­stanz fehlt. 

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 Requirements Engineer

Die Auf­ga­ben des Requi­re­ments Engi­neers wer­den 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)

pdf

A.2 Literatur

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

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