Reviews Prüfen von Produktanforderungen

Manage­ment-Zusam­men­fas­sung zu die­sem Bei­trag:
Reviews wer­den im → Pro­jekt­ma­nage­ment, im → Requi­re­ments Engi­nee­ring und bei → Scrum zur Über­prü­fung von Doku­men­ten oder Arbeits­er­geb­nis­sen her­an­ge­zo­gen.
In die­sem Bei­trag wer­den Reviews vor­ge­stellt und ein­ge­ord­net sowie die drei wesent­li­chen Review-Tech­ni­ken beschrieben.

Reviews kom­men in ver­schie­de­nen Dis­zi­pli­nen vor und die­nen der Qua­li­täts­er­hö­hung, häu­fig ver­bun­den mit Abnah­measpek­ten zwi­schen Auf­trag­ge­ber und Auf­trag­neh­mer. In die­sem Bei­trag wer­den Reviews in Pro­jek­ten, bei agi­lem Vor­ge­hen und im Requi­re­ments Engi­nee­ring betrach­tet (Abbil­dung 0.1).

Einordnung von Reviews, (C) Peterjohann Consulting, 2019-2022

Abbil­dung 0.1: Ein­ord­nung von Reviews (in Pro­jek­ten, bei agi­lem Vor­ge­hen und im Requi­re­ments Engineering)

1. Einleitung und Grundlagen

Um Sach­ver­hal­te zu über­prü­fen, kön­nen ver­schie­de­ne Kon­troll­ver­fah­ren ein­ge­setzt wer­den. Die Kon­troll­ver­fah­ren wer­den unter­teilt in Reviews und Audits (Abbil­dung 1.1). Reviews über­prü­fen im Requi­re­ments-Engi­nee­ring- oder Pro­jekt-Umfeld die Inhal­te, wäh­rend Audits das Vor­ge­hen betrach­ten. Inhal­te kön­nen im → Pro­jekt­um­feld Pro­duk­te oder → Dienst­leis­tun­gen sein.

Kontrolltechniken im Requirements Engineering und in Projekten, (C) Peterjohann Consulting, 2019-2022

Abbil­dung 1.1: Kon­troll­tech­ni­ken im Requi­re­ments Engi­nee­ring und in Projekten

1.1 Definitionen

Im BABOK /BBG17‑d/ wird defi­niert:
“Review (inspec­tion): For­ma­les, stan­dar­di­sier­tes Ver­fah­ren der Qua­li­täts­si­che­rung durch Exper­ten mit fes­ten Rol­len und ein­deu­ti­gen Doku­men­ta­ti­ons­re­geln, bei dem mög­li­che Män­gel, Schwach­stel­len oder Feh­ler sowie Kenn­zah­len ermit­telt werden.”

In Jen­ny /Jenny19/ steht:
“Ein Review ist ein mehr oder weni­ger for­mal geplan­ter und struk­tu­rier­ter Ana­ly­se- und Bewer­tungs­pro­zess, in dem Pro­jekt­er­geb­nis­se einem Team von Gut­ach­tern prä­sen­tiert und von die­sem kom­men­tiert oder geneh­migt werden.”

Anmer­kung:
In die­sem Bei­trag ist ein Review ein Neu­trum, es heißt somit “das Review”.

1.2 Dimensionen der Reviews

Nach dem → IIBA sind bei den Reviews drei Dimen­sio­nen zu berück­sich­ti­gen /BBG17‑d/ (Abbil­dung 1.2):

  • Die → Zie­le: Was soll erreicht werden?
  • Die Tech­ni­ken: Wel­che Tech­nik soll ein­ge­setzt werden?
  • Betei­lig­te: Wer ist beim Review beteiligt?
Die drei Dimensionen von Reviews nach IIBA, (C) Peterjohann Consulting, 2021-2022

Abbil­dung 1.2: Die drei Dimen­sio­nen von Reviews (nach IIBA /BBG17‑d/)

1.3 Einordnung beim Requirements Engineering

Die Reviews wer­den im Requi­re­ments Engi­nee­ring den Tech­ni­ken zur Vali­die­rung zuge­ord­net (Abbil­dung 1.2). Es wird beim → IREB /IREB21/ unter­schie­den zwischen …

  • Review-Tech­ni­ken,
  • Explo­ra­ti­ons­tech­ni­ken und der 
  • Pro­be-Ent­wick­lung.
Die Techniken zur Validierung von Anforderungen, (C) Peterjohann Consulting, 2021-2022

Abbil­dung 1.3: Die Tech­ni­ken zur Vali­die­rung von Anfor­de­run­gen (modi­fi­ziert nach IREB /IREB21/)

In die­sem Bei­trag wer­den nur die drei wesent­li­chen Review-Tech­ni­ken behan­delt, die ande­ren Tech­ni­ken wer­den im Bei­trag “Das → Vali­die­ren von Anfor­de­run­gen” auf die­ser Web­site beschrieben.

1.4 Beteiligte Rollen / Stakeholder

Bei einem Review sind immer min­des­tens zwei → Sta­ke­hol­der / Rol­len beteiligt:

  • Autor (oder auch Erstel­ler): Der­je­ni­ge, der die Anfor­de­run­gen ver­fasst oder die Arbeits­er­geb­nis­se erstellt hat
  • Review­er (auch Gut­ach­ter oder Inspek­to­ren): Die­je­ni­gen, die die Anfor­de­run­gen oder die Arbeits­er­geb­nis­se betrach­ten / beur­tei­len sollen

1.5 Die zeitliche Einordnung der Reviews

Reviews fin­den immer dann statt, wenn eine Qua­li­täts­si­che­rung oder Abnah­me statt­fin­den soll oder muss. In Abbil­dung 1.4 sind die typi­schen Review-Zeit­punk­te dargestellt.

Die typischen Zeitpunkte für Reviews in Projekten, bei Scrum und im Requirements Engineering, (C) Peterjohann Consulting, 2021-2022

Abbil­dung 1.4: Die typi­schen Zeit­punk­te für Reviews in Pro­jek­ten, bei Scrum und im Requi­re­ments Engineering

2. Die drei wesentlichen Review-Techniken

Als wesent­li­che Review-Tech­ni­ken werden …

  • die Stel­lung­nah­me,
  • die Inspek­ti­on und
  • der Walkthrough

bezeich­net.

Review-Techniken nach IREB, (C) Peterjohann Consulting, 2017-2022

Abbil­dung 2.1: Wesent­li­che Review-Tech­ni­ken (modi­fi­ziert nach IREB /IREB21/)

2.1 Stellungnahme

Bei der Stel­lung­nah­me wer­den ein­zel­ne Sta­ke­hol­der um eine schrift­li­che Stel­lung­nah­me zum Inhalt und zur → Qua­li­tät von ein­zel­nen oder meh­re­ren Anfor­de­run­gen gebe­ten — daher ist auch der Begriff Gut­ach­ten für die­ses Ver­fah­ren gebräuch­lich. Dabei ver­teilt der → Requi­re­ments Engi­neer die zu über­prü­fen­den Anfor­de­run­gen an die invol­vier­ten Sta­ke­hol­der. In der Regel geschieht dies ohne gemein­sa­me Tref­fen: Es wer­den ledig­lich die Anfor­de­run­gen, Bear­bei­tungs­hin­wei­se und eine Zeit­vor­ga­be ausgeliefert.

Tech­nisch wird die Stel­lung­nah­me durch Kom­men­ta­re der Sta­ke­hol­der / Gut­ach­ter an den ent­spre­chen­den Text­stel­len rea­li­siert. Mit Abschluss der Stel­lung­nah­me erhält der Requi­re­ments Engi­neer die ein­zel­nen Stel­lung­nah­men zurück und arbei­tet die Kom­men­ta­re ein.

Die Stel­lung­nah­me ist (zunächst) ein sehr ein­fa­ches Ver­fah­ren, wel­ches jedoch nicht immer zuver­läs­sig funk­tio­niert, da je nach Vor­kennt­nis die Qua­li­tät der Stel­lung­nah­men der Sta­ke­hol­der stark schwan­ken kann.

2.2 Inspektion

Die Inspek­ti­on ist die for­mals­te und auf­wen­digs­te der in die­sem Bei­trag vor­ge­stell­ten Prüf­tech­ni­ken. Es wer­den Prü­fun­gen anhand for­ma­ler (Qualitäts-)Kriterien und zuge­hö­ri­ger → Check­lis­ten durch­ge­führt und dann anschlie­ßend ausgewertet.

Bei der Inspek­ti­ons­sit­zung gibt es ver­schie­de­ne Rol­len – dies sind: Orga­ni­sa­tor, Mode­ra­tor, Autor, Vor­le­ser, Inspek­to­ren und Pro­to­kol­lant (Abbil­dung 2.2). Der Mode­ra­tor soll­te neu­tral sein und kann auch gleich­zei­tig als Vor­le­ser fungieren.

Die Rollen bei der Inspektion, (C) Peterjohann Consulting, 2020-2022

Abbil­dung 2.2: Die Rol­len bei der Inspektion

Die Inspek­ti­on folgt einem (vier­stu­fi­gen) Pro­zess­sche­ma (Abbil­dung 2.3), wel­ches bei der Feh­ler­samm­lung endet: Die Feh­ler­kor­rek­tur und Nach­kon­trol­le gehört nicht (unbe­dingt) zur Inspektion.

Der Inspektions-Prozess, (C) Peterjohann Consulting, 2017-2022

Abbil­dung 2.3: Der Inspektions-Prozess

Anmer­kung: Im BABOK /BBG17‑d/ wird Review mit Inspek­ti­on gleichgesetzt. 

2.3 Walkthrough

Der Walkthrough ist eine schnel­le Metho­de, um ers­te Feh­ler und Unklar­hei­ten zu erken­nen. Dabei wird in einer Sit­zung durch den Autor (in der Regel der Requi­re­ments Engi­neer) das Anfor­de­rungs­do­ku­ment vor­ge­stellt. Dabei wer­den Fra­gen durch die anwe­sen­den Review­er (Gut­ach­ter) gestellt und die­se wie­der­um durch den Autor beant­wor­tet. Die Ant­wor­ten wer­den durch den Pro­to­kol­lan­ten pro­to­kol­liert und spä­ter in die Anfor­de­run­gen / das Anfor­de­rungs­do­ku­ment eingearbeitet.

Im BABOK /BBG17‑d/ wird defi­niert:
“Walkthrough: Sys­te­ma­ti­sches Ver­fah­ren der Qua­li­täts­si­che­rung, bei dem die Betei­lig­ten Schritt für Schritt ein Pro­dukt oder eine Leis­tung über­prü­fen, um Anfor­de­run­gen oder Designs zu vali­die­ren und dabei Feh­ler, unge­lös­te Sach­ver­hal­te, Inkon­sis­ten­zen oder → Kon­flik­te zu ermitteln.”

Walkthroughs wer­den unter­teilt in (Abbil­dung 2.4) /BBG17‑d/:

  • For­ma­le Walkthroughs oder auch Team Reviews: Dies ent­spricht dem in die­sem Abschnitt vor­ge­stell­ten Ver­fah­ren und betonnt das team­ba­sier­te, for­ma­le Vorgehen
  • Infor­ma­le Walkthroughs: Hier­bei wer­den for­ma­le Aspek­te weg­ge­las­sen, um schnel­le Ergeb­nis­se erzie­len zu kön­nen. Die­ses Vor­ge­hen ist beson­ders für Anfor­de­run­gen und Arbeits­pro­duk­te geeig­net, die sich in einem frü­hen Ent­wick­lungs­sta­di­um befinden
Zwei Arten von Walkthroughs, (C) Peterjohann Consulting, 2021-2022

Abbil­dung 2.4: Zwei Arten von Walkthroughs

2.4 Vergleich der drei Review-Techniken

Gene­rell kön­nen alle drei Review-Tech­ni­ken glei­cher­ma­ßen ein­ge­setzt wer­den. Jedoch ist ins­be­son­de­re der Auf­wand unter­schied­lich hoch. In Abbil­dung 2.5 sind die drei Review-Tech­ni­ken zusam­men­ge­fasst dargestellt.

Die Review-Techniken im Vergleich, (C) Peterjohann Consulting, 2020-2022

Abbil­dung 2.5: Die Review-Tech­ni­ken im Vergleich

3. Nach der Durchführung des Reviews

Ist ein Review erfolgt, so kön­nen sich Feh­ler- oder Män­gel­lis­ten erge­ben, die dann ein­ge­ar­bei­tet wer­den müs­sen. Ist dies erfolgt, so muss der Sta­tus “erfolg­reich geprüft” notiert wer­den. Anschlie­ßend kann mit der Bear­bei­tung des Pro­jekts / des → Vor­ha­ben wei­ter gemacht werden.

Im Requi­re­ments Engi­nee­ring wür­de eine Anfor­de­rung den Sta­tus geprüft erhal­ten (Zustand “Geprüft” in Abbil­dung 3.1). Erst nach der Prü­fung wird in die­sem Bei­spiel ent­schie­den, ob die Anfor­de­rung zur Umset­zung gelan­gen soll (Zustand “Ver­ein­bart”).

Ein Zustandsmodell für Anforderungen - Beispiel, (C) Peterjohann Consulting, 2013-2022

Abbil­dung 3.1: Ein Zustands­mo­dell für Anfor­de­run­gen (Bei­spiel)

4. Ähnliche Begriffe

“Ähn­li­che” Begrif­fe wie Review sind:

  • Rezen­si­on: Ein Review für Fach­tex­te oder ‑bücher
  • Assess­ment: Gesamt­be­wer­tung eines Sach­ver­halts oder Systems
  • Code Review: Bei einem Code Review (ande­re Schreib­wei­se auch Code-Review) wer­den Soft­ware-Source-Codes (anstatt Anfor­de­run­gen) überprüft
  • → Soft­ware­ar­chi­tek­tur Review: Bei einem Review Soft­ware­ar­chi­tek­tur wird die Soft­ware­ar­chi­tek­tur — im Wesent­li­chen auf Basis der Soft­ware­ar­chi­tek­tur-Doku­men­te — überprüft
  • Sin­gle Issue Review (wird auch als tech­ni­sches Review bezeich­net): Bei die­sem Review wird der Augen­merk auf nur einen Sach­ver­halt gelenkt /BBG17‑d/
  • Sprint Review: Ist ein Review, wel­ches inner­halb es Sprints in Scrum statt­fin­det /Scrum-Gui­de-20‑­d/
  • Pass Around: Vor­ge­hen bei einem Review mit meh­re­ren Review­ern, bei denen die Review-Zwi­schen­er­geb­nis­se reih­um wei­ter­ge­reicht werden
  • Ad-hoc-Review: Eine kur­ze, infor­mel­le Stel­lung­nah­me (die auch münd­lich erfol­gen kann) wird auch als Ad-hoc-Review bezeichnet
  • Pro­jekt­ana­ly­se, Pro­jekt­prü­fung, Pro­jekt­re­vi­si­on, Pro­jekt­über­prü­fung: Die Begrif­fe kön­nen sowohl ein Pro­jekt­re­view wie auch → Pro­jekt­au­dit bezeichnen

5. Anmerkungen zu den Reviews

Für Reviews muss Zeit ein­ge­plant wer­den. Dies bedeu­tet ins beson­de­re, dass dort auch Kos­ten ent­ste­hen, die durch das Vor­ha­ben oder Pro­jekt getra­gen wer­den müs­sen. Daher ist vor­ab eine Kosten‑, → Dau­er- und Auf­wands­ab­schät­zung vor­zu­neh­men und die­se dem Kos­ten­ver­ant­wort­li­chen (bei­spiels­wei­se dem → Pro­jekt­ma­na­ger) mit­zu­tei­len.

Reviews sind kei­ne “Finger-Pointing”-Veranstaltungen. Es geht dar­um, die Anfor­de­run­gen zu ver­bes­sern und nicht dar­um, den Nach­weis zu füh­ren, dass Mit­ar­bei­ter Feh­ler gemacht haben. Die “mensch­li­che Kom­po­nen­te” soll­te also von der “fach­li­chen” getrennt wer­den. Dies bedeutet …

  • Für den Requi­re­ments Engi­neer: Als Requi­re­ments Engi­neer soll­ten die Reviews genutzt wer­den, um wich­ti­ge und strit­ti­ge Anfor­de­run­gen zu bespre­chen und zu ver­bes­sern. Daher reicht ein Hin­weis auf die eige­ne geleis­te­te Arbeit, es müs­sen die eige­nen Leis­tun­gen nicht in den Vor­der­grund gestellt werden
  • Für die Review­er: Die Review­er soll­ten ver­su­chen, For­mu­lie­run­gen, die den Requi­re­ments Engi­neer per­sön­lich angrei­fen, zu vermeiden
  • Für den Mode­ra­tor: Zu Beginn eines Reviews soll­te auf die Spiel­re­geln hin­ge­wie­sen wer­den. Und im lau­fen­den Review soll­te auf die Ein­hal­tung die­ser Regeln geach­tet werden

Reviews soll­ten nicht als “Frei­ga­berun­den” ver­stan­den wer­den: Auch wenn die “Zeich­nungs­ver­ant­wort­li­chen” am Review betei­ligt sind, soll­te auf eine Tren­nung zwi­schen Prü­fung und Frei­ga­be geach­tet wer­den. Aller­dings soll­ten die Reviews vor dem Hin­ter­grund der Frei­ga­be erfol­gen: Sind die Anfor­de­run­gen durch ein Review über­prüft und ver­bes­sert wor­den, so soll­te der Frei­ga­be­ver­ant­wort­li­che sich auch dar­auf ver­las­sen kön­nen. Ein erneu­tes, detail­lier­tes Über­prü­fen der Anfor­de­run­gen auf dem glei­chen Ent­wick­lungstand ver­ur­sacht über­flüs­si­ge Mehraufwände.

Anhang: Präsentationen, Literatur und Weblinks

→ Prä­sen­ta­tio­nen

  • -

Lite­ra­tur

  1. /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
  2. /IREB15/ 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 4. Auf­la­ge 2015, ISBN 978–3‑86490–283‑3
  3. /IREB21/ sie­he /Pohl21/
  4. /Jenny19/ Bru­no Jen­ny: Pro­jekt­ma­nage­ment. Das Wis­sen für den Pro­fi, Vdf Hoch­schul­ver­lag, Zürich 4. Auf­la­ge 2019, ISBN 978–3‑7281–3967‑2
  5. /Pohl21/ 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
  6. /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

Web­links

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