Aufwand für das Requirements Engineering Ermittlung und Bewertung

Manage­ment-Zusam­men­fas­sung zu die­sem Bei­trag:
Um → Requi­re­ments Engi­nee­ring zu betrei­ben, muss der → Auf­wand dafür berück­sich­tigt wer­den.
Die­ser Bei­trag beschäf­tigt sich mit “typi­schen” Auf­wän­den für das RE.

Der Auf­wand zum Betrei­ben von Requi­re­ments Engi­nee­ring soll­te vor dem Start eines Requi­re­ments-Engi­nee­ring-→ Vor­ha­ben bestimmt wer­den. Hier­über kann ver­deut­licht wer­den, wie viel Arbeits­zeit für das das gesam­te Vor­ha­ben auf­ge­wandt wer­den muss.

In die­sem Bei­trag geht es um Auf­wand “für das RE” und nicht um Auf­wand “im RE” (Abbil­dung 0.1).

Aufwände beim Requirements Engineering, (C) Peterjohann Consulting, 2021-2022

Abbil­dung 0.1: Auf­wän­de beim Requi­re­ments Engineering

Der Auf­wand von Requi­re­ments Engi­nee­ring muss dem Nut­zen gegen­über­ge­stellt werden.

Wo kann ich Sie unter­stüt­zen?
Die Ermitt­lung von Auf­wän­den ist nicht ein­fach. Daher bie­te ich dazu → Dienst­leis­tun­gen / Work­shops an.

1. Einleitung und Grundlagen

Der Ein­satz Requi­re­ments Engi­nee­ring erfor­dert einen Auf­wand. In der Pra­xis wird die­ser häu­fig unter­schätzt, sodass dem Requi­re­ments Engi­nee­ring nicht genü­gend Res­sour­cen zuge­ord­net wer­den. Hier­aus resul­tie­ren dann in der Fol­ge eini­ge Miss­stän­de, so beispielsweise:

  • Das Ergeb­nis ist des Requi­re­ments Engi­nee­rings ist unzureichend
  • Die invol­vier­ten Mit­ar­bei­ter sind mit ihrer eige­nen Arbeits­leis­tung unzufrieden

Abgren­zun­gen:
Gene­rell wird in die­sem Bei­trag nur der Auf­wand für das “rei­ne” Requi­re­ments Engi­nee­ring betrach­tet, nicht jedoch der Test, nicht das vor­ge­la­ger­te Pro­dukt­ma­nage­ment und nicht das → Pro­jekt­ma­nage­ment. Es wird zudem ange­nom­men, dass nur die Basis­funk­tio­na­li­tät erfasst wer­den soll und dass die­se zu Beginn der Umset­zung festliegt.

1.1 Eine einfache Abschätzung des Aufwands

In der Lite­ra­tur wie auch in der Pra­xis wird häu­fig der Auf­wand für das Requi­re­ments Engi­nee­ring mit “5 bis 15 Pro­zent” vom Gesamt­auf­wand ange­ge­ben. Die­se Aus­sa­ge ist zunächst ein­mal sehr vage.

→ Merk­re­geln:

  • Etwa 5 bis 15 % des Gesamt­auf­wands zur Her­stel­lung eines Pro­dukts muss für das → Anfor­de­rungs­ma­nage­ment / Requi­re­ments Engi­nee­ring auf­ge­wen­det werden.
  • Die Basis­zahl ist 10 % — in einer ers­ten Nähe­rung kann man von 10 Pro­zent des Gesamt­auf­wands für das Requi­re­ments Engi­nee­ring ausgehen

Fall­stri­cke:

  • Wenn die­se Maß­zahl unter­schrit­ten wird, heißt dies zunächst ein­mal nichts
  • Wenn die­se Maß­zahl über­schrit­ten wird, heißt dies auch nichts

1.1 Die Kosten-Nutzen-Betrachtung

In Abbil­dung 1.1 ist eine Kos­ten-Nut­zen-Betrach­tung für den Ein­satz­grad von Requi­re­ments Engi­nee­ring zu sehen.

Die Balance zwischen Kosten und Nutzen beim Requirements Engineering, (C) Peterjohann Consulting, 2021-2022

Abbil­dung 1.1: Die Balan­ce zwi­schen Kos­ten und Nut­zen beim Requi­re­ments Engineering

1.2 Ein einfaches Beispiel

In einem Pro­jekt mit 10 Mit­ar­bei­tern soll eine Auf­wands­ab­schät­zung für das Requi­re­ments Engi­nee­ring vor­ge­nom­men wer­den. Es soll dabei nur das Pro­jekt betrach­tet wer­den. Ein RE-Pro­zess und ein → RE-Tool ist vor­han­den und eta­bliert. Die Pro­jekt­lauf­zeit beträgt 3 Jahre

2. Aspekte aus der Praxis

In der Pra­xis kann das Requi­re­ments Engi­nee­ring effi­zi­en­ter gestal­tet wer­den, indem die Auf­wän­de redu­ziert wer­den, die “Zeit­fres­ser” eli­mi­niert wer­den oder indem Mehr­wer­te geschaf­fen werden.

2.1 Reduzierung der Aufwände

Um den Auf­wand für das Requi­re­ments Engi­nee­ring zu redu­zie­ren, kön­nen fol­gen­de Maß­nah­men ergrif­fen werden:

  • Ver­zicht auf das Requi­re­ments Engineering
  • Nach­qua­li­fi­ka­ti­on der Mitarbeiter
  • Fokus­sie­rung auf wesent­li­che Aspekte
  • (Star­ke) Wiederverwendung

2.2 Erkennen der “Zeitfresser”

Gene­rell: Schlech­te Pro­zes­se und nicht aus­rei­chend vor­be­rei­te­te Mit­ar­bei­ter erhö­hen den Auf­wand / Zeit­be­darf.
Typi­sche zeit­auf­wen­di­ge The­men sind dabei:

  • → Inter­views: Wer­den die­se unzu­rei­chend durch­ge­führt, so führt dies in der Regel zu erheb­li­chen Mehr­auf­wän­den, die kei­nen Nut­zen bringen
  • Man­gel­haf­te Tool­un­ter­stüt­zung: Wer­den fal­sche Tools oder Tools falsch ein­ge­setzt, so ent­ste­hen häu­fig Mehrarbeiten

2.3 Generierung von Mehrwerten

Der Auf­wand für ein “gutes” Requi­re­ments Engi­nee­ring kann inner­halb eines Pro­jekts höher sein als der gene­rier­te Nut­zen. Wenn die Anfor­de­run­gen jedoch über das unmit­tel­ba­re Pro­jekt genutzt wer­den kön­nen, kön­nen Mehr­wer­te für die Orga­ni­sa­ti­on gene­riert wer­den.
Typi­sche Mehr­wer­te ent­ste­hen durch:

  • Impact Ana­ly­sis: Hier­über wer­den Aus­wir­kun­gen von Ver­än­de­run­gen an den Anfor­de­run­gen sehr schnell sichtbar
  • Ver­bin­dung mit Test Cases: Wenn die Anfor­de­run­gen direkt mit den Test Cases / Test­fäl­len ver­bun­den wer­den, so ent­steht schnell ein Mehr­wert, da sichj die Tests dann direkt aus den Anfor­de­run­gen ergeben

3. Szenarien und Berechnungsbeispiele

Fol­gen­des Sze­na­rio soll bei­spiel­haft betrach­tet wer­den: 20 Mit­ar­bei­ter in der Ent­wick­lungs­ab­tei­lung, Ziel: Län­ger­fris­ti­ges Pro­dukt­ma­nage­ment, Lebens­zy­klus: 2 Ent­wick­lung, 10 Jah­re im Feld, Sup­port und Ser­vice ist notwendig.

4. Häufige Fragen und Antworten zum Aufwand im Requirements Engineering

Eini­ge Fra­gen zum Auf­wand im Requi­re­ments Engi­nee­ring wer­den häu­fig gestellt – die­se wer­den hier wiedergegeben.

  • F: Muss man eine Auf­wands­be­trach­tung für das Requi­re­ments Engi­nee­ring vor­ge­nom­men wer­den?
    A: Dies ist sinn­voll. Da der Auf­wand für das Requi­re­ments Engi­nee­ring häu­fig unter­schätzt wird und sehr groß wer­den kann und zudem die Ergeb­nis­se des Ein­sat­zes erst sehr spät sicht­bar wird, ist eine Auf­wands­be­trach­tung sinnvoll.
  • F: Wann soll­te eine Auf­wands­be­trach­tung für das Requi­re­ments Engi­nee­ring vor­ge­nom­men wer­den?
    A: Sehr früh­zei­tig — und bevor mit dem Requi­re­ments Engi­nee­ring begon­nen wird, denn nur so kön­nen die Erwar­tun­gen den Auf­wän­den gegen­über­ge­stellt werden.
  • F: Wie kann der Auf­wand für das Requi­re­ments Engi­nee­ring mini­miert / opti­miert wer­den?
    A: Dies kommt auf den Kon­text an: Je nach Orga­ni­sa­ti­ons- und Pro­blem­grö­ße muss dies ein­zel­nen betrach­tet 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

A.1 Meine Präsentationen

Die Auf­wands­ab­schät­zung für das Requi­re­ments Engi­nee­ring wird (kurz) 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

In fol­gen­den Büchern wird als Aspekt der Auf­wand für das Requi­re­ments Engi­nee­ring 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
  • /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
  • /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/
  • /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
  • /Wiegers05/ Karl E. Wie­gers: Soft­ware-Requi­re­ments, Micro­soft Press Deutsch­land, Mün­chen 2005, ISBN 978–3‑860–63594‑0

Auf fol­gen­de Web­links wird hier Bezug genommen:

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