Management-Zusammenfassung dieses Beitrags:
Reviews werden im → Projektmanagement, im → Requirements Engineering und bei → Scrum zur Überprüfung von Dokumenten oder Arbeitsergebnissen herangezogen.
In diesem Beitrag werden Reviews vorgestellt und eingeordnet sowie die drei wesentlichen Review-Techniken beschrieben.
Reviews kommen in verschiedenen Disziplinen zum Einsatz und dienen der Qualitätserhöhung, häufig verbunden mit Abnahmeaspekten zwischen → Auftraggeber und Auftragnehmer. In diesem Beitrag werden Reviews in Projekten, bei agilem Vorgehen und im Requirements Engineering betrachtet (Abbildung 0.1).
Abbildung 0.1: Einordnung von Reviews (in Projekten, bei agilem Vorgehen und im Requirements Engineering)
1. Einleitung und Grundlagen
Um Sachverhalte zu überprüfen, können verschiedene Kontrollverfahren eingesetzt werden. Die Kontrollverfahren werden unterteilt in Reviews und Audits (Abbildung 1.1). Reviews überprüfen im Requirements-Engineering- oder Projekt-Umfeld die Inhalte, während Audits das Vorgehen / den Entwicklungsprozess betrachten. Inhalte können im → Projektumfeld Produkte oder → Dienstleistungen sein.
Abbildung 1.1: Kontrolltechniken im Requirements Engineering und in Projekten
1.1 Definitionen
Im BABOK /BBG17‑d/ wird definiert:
“Review (inspection): Formales, standardisiertes Verfahren der Qualitätssicherung durch Experten mit festen Rollen und eindeutigen Dokumentationsregeln, bei dem mögliche Mängel, Schwachstellen oder → Fehler sowie Kennzahlen ermittelt werden.”
In Jenny /Jenny19/ steht zum Review in Projekten:
“Ein Review ist ein mehr oder weniger → formal geplanter und strukturierter Analyse- und Bewertungsprozess, in dem Projektergebnisse einem Team von Gutachtern präsentiert und von diesem kommentiert oder genehmigt werden.”
Anmerkung:
In diesem Beitrag ist ein Review ein Neutrum, es heißt somit “das Review”.
1.2 Dimensionen der Reviews
Nach dem → IIBA sind bei den Reviews drei Dimensionen zu berücksichtigen /BBG17‑d/ (Abbildung 1.2):
- Die → Ziele: Was soll erreicht werden?
- Die Techniken: Welche Technik soll eingesetzt werden?
- Beteiligte: Wer ist beim Review beteiligt?
Abbildung 1.2: Die drei Dimensionen von Reviews (nach IIBA /BBG17‑d/)
1.3 Einordnung beim Requirements Engineering
Die Reviews werden im Requirements Engineering den Techniken zur Validierung zugeordnet (Abbildung 1.2). Es wird beim → IREB /IREB21/ unterschieden zwischen …
- Review-Techniken,
- Explorationstechniken und der
- Probe-Entwicklung.
Abbildung 1.3: Die Techniken zur Validierung von Anforderungen (modifiziert nach IREB /IREB21/)
In diesem Beitrag werden nur die drei wesentlichen Review-Techniken behandelt, die anderen Techniken werden im Beitrag “Das → Validieren von Anforderungen” auf dieser Website beschrieben.
1.4 Beteiligte Rollen / Stakeholder
Bei einem Review sind immer mindestens zwei → Stakeholder / Rollen beteiligt:
- Autor (oder auch Ersteller): Derjenige, der die Anforderungen verfasst oder die Arbeitsergebnisse erstellt hat
- Reviewer (auch Gutachter oder Inspektoren): Diejenigen, die die Anforderungen oder die Arbeitsergebnisse betrachten / beurteilen sollen
1.5 Die zeitliche Einordnung der Reviews
Reviews finden immer dann statt, wenn eine Qualitätssicherung oder Abnahme stattfinden soll oder muss. In Abbildung 1.4 sind die typischen Review-Zeitpunkte für das klassische Projektmanagement (PM), für den Sprint in Scrum und im Requirements Engineering (RE) dargestellt.
Abbildung 1.4: Die typischen Zeitpunkte für Reviews in Projekten, bei Scrum und im Requirements Engineering
2. Die drei wesentlichen Review-Techniken
Als wesentliche Review-Techniken werden …
- die Stellungnahme,
- die Inspektion und
- der Walkthrough
bezeichnet.
Abbildung 2.1: Wesentliche Review-Techniken (modifiziert nach IREB /IREB21/)
2.1 Stellungnahme
Bei der Stellungnahme werden einzelne Stakeholder um eine schriftliche Stellungnahme zum Inhalt und zur → Qualität von einzelnen oder mehreren Anforderungen gebeten — daher ist auch der Begriff Gutachten für dieses Verfahren gebräuchlich. Dabei verteilt der → Requirements Engineer die zu überprüfenden Anforderungen an die involvierten Stakeholder. In der Regel geschieht dies ohne gemeinsame Treffen: Es werden lediglich die Anforderungen, Bearbeitungshinweise und eine Zeitvorgabe ausgeliefert.
Technisch wird die Stellungnahme durch Kommentare der Stakeholder / Gutachter an den entsprechenden Textstellen realisiert. Mit Abschluss der Stellungnahme erhält der Requirements Engineer die einzelnen Stellungnahmen zurück und arbeitet die Kommentare ein.
Die Stellungnahme ist (zunächst) ein sehr einfaches Verfahren, welches jedoch nicht immer zuverlässig funktioniert, da je nach Vorkenntnis die Qualität der Stellungnahmen der Stakeholder stark schwanken kann.
2.2 Inspektion
Die Inspektion ist die formalste und aufwendigste der in diesem Beitrag vorgestellten Prüftechniken. Es werden Prüfungen anhand formaler (Qualitäts-)Kriterien und zugehöriger → Checklisten durchgeführt und dann anschließend ausgewertet.
Bei der Inspektionssitzung gibt es verschiedene Rollen – dies sind: Organisator, Moderator, Autor, Vorleser, Inspektoren und Protokollant (Abbildung 2.2). Der Moderator sollte neutral sein und kann auch gleichzeitig als Vorleser fungieren.
Abbildung 2.2: Die Rollen bei der Inspektion
Die Inspektion folgt einem (vierstufigen) Prozessschema (Abbildung 2.3), welches bei der Fehlersammlung endet: Die Fehlerkorrektur und Nachkontrolle gehört nicht (unbedingt) zur Inspektion.
Abbildung 2.3: Der Inspektions-Prozess
Anmerkung: Im BABOK /BBG17‑d/ wird Review mit Inspektion gleichgesetzt.
2.3 Walkthrough
Der Walkthrough ist eine schnelle Methode, um erste Fehler und Unklarheiten zu erkennen. Dabei wird in einer Sitzung durch den Autor (in der Regel der Requirements Engineer) das Anforderungsdokument vorgestellt. Dabei werden Fragen durch die anwesenden Reviewer (Gutachter) gestellt und diese wiederum durch den Autor beantwortet. Die Antworten werden durch den Protokollanten protokolliert und später in die Anforderungen / das Anforderungsdokument eingearbeitet.
Im BABOK /BBG17‑d/ wird definiert:
“Walkthrough: Systematisches Verfahren der Qualitätssicherung, bei dem die Beteiligten Schritt für Schritt ein Produkt oder eine Leistung überprüfen, um Anforderungen oder Designs zu validieren und dabei Fehler, ungelöste Sachverhalte, Inkonsistenzen oder → Konflikte zu ermitteln.”
Walkthroughs werden unterteilt in (Abbildung 2.4) /BBG17‑d/:
- Formale Walkthroughs oder auch Team Reviews: Dies entspricht dem in diesem Abschnitt vorgestellten Verfahren und betont das teambasierte, formale Vorgehen
- Informale Walkthroughs: Hierbei werden formale Aspekte weggelassen, um schnelle Ergebnisse erzielen zu können. Dieses Vorgehen ist besonders für Anforderungen und Arbeitsprodukte geeignet, die sich in einem frühen Entwicklungsstadium befinden
Abbildung 2.4: Zwei Arten von Walkthroughs
2.4 Vergleich der drei Review-Techniken
Generell können alle drei Review-Techniken gleichermaßen eingesetzt werden. Jedoch ist insbesondere der → Aufwand unterschiedlich hoch. In Abbildung 2.5 sind die drei Review-Techniken zusammengefasst dargestellt.
Abbildung 2.5: Die Review-Techniken im Vergleich
3. Nach der Durchführung des Reviews
Ist ein Review erfolgt, so können sich Fehler- oder Mängellisten ergeben, die dann eingearbeitet werden müssen. Ist dies erfolgt, so muss der Status “erfolgreich geprüft” notiert werden. Anschließend kann mit der Bearbeitung des Projekts / des → Vorhaben weitergemacht werden.
Im Requirements Engineering würde eine Anforderung den Status geprüft erhalten (Zustand “Geprüft” in Abbildung 3.1). Erst nach der → Prüfung wird in diesem Beispiel entschieden, ob die Anforderung zur Umsetzung gelangen soll (Zustand “Vereinbart”).
Abbildung 3.1: Ein Zustandsmodell für Anforderungen (Beispiel)
4. Ähnliche Begriffe
“Ähnliche” Begriffe wie Review sind:
- Rezension: Ein Review für Fachtexte oder ‑bücher
- Assessment: Gesamtbewertung eines Sachverhalts oder Systems
- Code Review: Bei einem Code Review (andere Schreibweise auch Code-Review) werden Software-Source-Codes (anstatt Anforderungen) überprüft
- → Softwarearchitektur Review: Bei einem Review der Softwarearchitektur wird die Softwarearchitektur — im Wesentlichen auf Basis der Softwarearchitektur-Dokumente — überprüft
- Single Issue Review (wird auch als technisches Review bezeichnet): Bei diesem Review wird das Augenmerk auf nur einen Sachverhalt gelenkt /BBG17‑d/
- Sprint Review: Ist ein Review, welches innerhalb es Sprints in Scrum stattfindet /Scrum-Guide-20‑d/
- Pass Around: Vorgehen bei einem Review mit mehreren Reviewern, bei denen die Review-Zwischenergebnisse reihum weitergereicht werden
- Ad-hoc-Review: Eine kurze, informelle Stellungnahme (die auch mündlich erfolgen kann) wird auch als Ad-hoc-Review bezeichnet
- Projektanalyse, Projektprüfung, Projektrevision, Projektüberprüfung: Die Begriffe können sowohl ein Projektreview als auch → Projektaudit bezeichnen
5. Anmerkungen zu den Reviews
Für die Durchführung von Reviews muss Zeit eingeplant werden. Dies bedeutet insbesondere, dass dabei auch Kosten entstehen, die durch das Vorhaben oder Projekt getragen werden müssen. Daher ist vorab eine Kosten‑, → Dauer- und Aufwandsabschätzung vorzunehmen und diese dem Kostenverantwortlichen (beispielsweise dem → Projektmanager) mitzuteilen.
Reviews sind keine “Finger-Pointing”-Veranstaltungen. Es geht darum, die Anforderungen zu verbessern und nicht darum, den Nachweis zu führen, dass Mitarbeiter Fehler gemacht haben. Die “menschliche” Komponente sollte also von der “fachlichen” getrennt werden. Dies bedeutet …
- Für den Requirements Engineer: Als Requirements Engineer sollten die Reviews genutzt werden, um wichtige und strittige Anforderungen zu besprechen und zu verbessern. Daher reicht ein Hinweis auf die eigene geleistete Arbeit, es müssen die eigenen Leistungen nicht in den Vordergrund gestellt werden
- Für die Reviewer: Die Reviewer sollten versuchen, Formulierungen, die den Requirements Engineer persönlich angreifen, zu vermeiden
- Für den Moderator: Zu Beginn eines Reviews sollte auf die Spielregeln hingewiesen werden. Und im laufenden Review sollte auf die Einhaltung dieser Regeln geachtet werden
Reviews sollten nicht als “Freigaberunden” verstanden werden: Auch wenn die “Zeichnungsverantwortlichen” am Review beteiligt sind, sollte auf eine Trennung zwischen Prüfung und Freigabe geachtet werden. Allerdings sollten die Reviews vor dem Hintergrund der Freigabe erfolgen: Sind die Anforderungen durch ein Review überprüft und verbessert worden, so sollte der Freigabeverantwortliche sich auch darauf verlassen können. Ein erneutes, detailliertes Überprüfen der Anforderungen auf dem gleichen Entwicklungsstand verursacht überflüssige Mehraufwände.
Anhang: Präsentationen, Literatur und Weblinks
- -
Literatur
- /BBG17‑d/ IIBA: BABOK v3: Leitfaden zur Business-Analyse BABOK Guide 3.0, Dr. Götz Schmidt, Wettenberg 2017, ISBN 978–3‑945997–03‑1
- /IREB15/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-→ Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt, Heidelberg 4. Auflage 2015, ISBN 978–3‑86490–283‑3
- /IREB21/ siehe /Pohl21/
- /Jenny19/ Bruno Jenny: Projektmanagement. Das Wissen für den Profi, Vdf Hochschulverlag, Zürich 4. Auflage 2019, ISBN 978–3‑7281–3967‑2
- /Pohl21/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt, Heidelberg 5. Auflage 2021, ISBN 978–3‑86490–814‑9
- /Rupp20/ Chris Rupp: Requirements-Engineering und ‑Management. Das Handbuch für Anforderungen in jeder Situation, Hanser, München 7. Auflage 2020, ISBN 978–3‑446–45587‑0
Weblinks
- /ISO20246/ ISO/IEC/IEEE 20246:2017 (“Systems and → software engineering – Work product reviews”); Standard zum Work Product (deutsch Arbeitsergebnis) Review (englisch)
- /#Scrum-Guide-20‑d/ Der Scrum Guide (deutsch), 19seitige Scrum-Kurzdarstellung von Ken Schwaber und Jeff Sutherland – deutsche Übersetzung, aktualisiert im November 2020
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 28.01.2021 © Peterjohann Consulting, 2005–2024
