Wenn das Ziel definiert ist, das Budget steht und die Timeline geplant wurde, kann es oft nicht schnell genug gehen, um die Anforderungen festzulegen und mit der Umsetzung zu starten. Damit hierbei Fehler vermieden werden, kann ein Review der Anforderungen deren Qualität sichern.
Aber wie geht das eigentlich? Und ist eine detaillierte Prüfung der Anforderungen nicht ineffizient, wenn sich diese im Projekt sowieso häufig ändern? Eine wichtige Säule des Anforderungsmanagements ist das Prüfen und Abstimmen der Anforderungen. Die Implementierung eines effizienten Reviewprozesses schafft dabei Abhilfe, damit Ihr Projekt nicht ins Wanken gerät.
Fehlerhafte Anforderungen – warum ist das keine Seltenheit?
„Das Auto soll schnell und sicher sein.“ Auf den ersten Blick ergibt diese Anforderung in Bezug auf das Endprodukt Sinn. Allerdings wird diese Anforderung das liefernde Unternehmen nur mit vielen offenen Fragen dastehen lassen. Wie schnell soll es sein und was gilt eigentlich als sicher? Notgedrungen wird es sich wieder mit dem Auftraggeber in Verbindung setzen müssen und das Projekt gerät ins Stocken.
Der*die Anforderungsmanager*in (auch Requirements Engineer) fragt sich: Wie konnte es so eine unklare Anforderung in ein offizielles Lastenheft schaffen? Die Antwort ist ganz einfach. Das Unternehmen hat am falschen Ende Kosten gespart und keinen oder einen ungeeigneten Reviewprozess der Anforderungen durchgeführt. Dadurch ist eine nicht eindeutige, sowie nicht testbare Anforderung an den Lieferanten gesendet worden. Das beispielhafte Unternehmen ist hierbei kein Einzelfall.
Ursache für das Scheitern von Projekten oder für den Abschluss eines Projekts mit Funktionseinschränkungen und/oder Ressourcenüberschreitungen kann ein unzureichendes Anforderungsmanagement sein, bei dem die Qualität der Anforderungen im Projekt nicht ausreichend geprüft wurde.
Der CHAOS-Report ist eine von der Standish Group veröffentlichte Studie, welche die Erfolgs- und Misserfolgsfaktoren in IT-Projekten untersucht. Die Projekte werden dabei in drei Typen unterteilt: Erfolgreich, Gescheitert und Abgeschlossen mit Ressourcenüberschreitung bzw. Funktionseinschränkungen. Ressourcenüberschreitungen können sowohl finanziell als auch zeitlich auftreten.
Beim Vergleich der Jahre 1994 und 2015 ist die Zahl der erfolgreichen Projekte um ca. 45 % gestiegen und die der gescheiterten um 39 % gesunken. Insgesamt zeigt sich ein Trend, dass die Zahl der gescheiterten Projekte im Laufe der Jahre zurückgegangen ist. Eine Ursache, die zur Minderung beigetragen hat, ist die höhere Qualität von Anforderungen. Allerdings sind nach wie vor die ausschlaggebenden Faktoren für einen Projektmisserfolg:
- Fehlende Zuarbeit durch Nutzer,
- Unvollständige/unklare Anforderungen,
- Häufige Anforderungsänderungen.
Zwei dieser drei Faktoren lassen sich durch ein effektiv durchgeführtes Review im Anforderungsmanagement vermeiden. Was genau bedeutet Review? Die Übersetzung des Begriffs Review auf Deutsch ist Rückblick oder Rezensieren. Ein Review ist also eine im Nachhinein durchgeführte Überprüfung. Führt dabei ein zusätzlicher Prozess der Überprüfung aller Anforderungen nicht automatisch zur Kostenerhöhung? Um dies zu beurteilen, sollten die Auswirkungen von fehlerhaften Anforderungen näher betrachtet werden.
Die Kosteneffizienz eines Reviewprozesses
Ein Grund für die Notwendigkeit von Reviews zur Prüfung und Abstimmung von Anforderungen liegt in der exponentiellen Kostenentwicklung, die das Auftreten eines Fehlers und dessen Behebung zu einem fortgeschrittenen Projektzeitpunkt hervorrufen kann. Die Kostenentwicklung kann durch die Kostenkurve beschrieben werden, welche auf einem Modell des amerikanischen Softwareingenieurs Barry W. Boehm basiert. Es besagt, dass im Entwicklungsprozess später auftretende Anforderungen bzw. Änderungen der Anforderungen deutlich höhere Kosten verursachen. Wie bei der Zehnerregel der Fehlerkosten (englisch auch „rule of ten“), steigen die Kosten je Entwicklungsschritt um den Faktor 10.
Kostenkurve nach Boehm
Die Darstellung zeigt deutlich, dass mit fortschreitendem Entwicklungsprozess eines Produkts/Services auch die Höhe der Kosten zunimmt für eine mögliche Fehlerbehebung. Falls eine Anforderung in der Phase der Implementierung noch einmal geändert werden muss, kann dies die 100-fachen Kosten verursachen, als wenn die Anpassung in der Analysephase geschehen wäre.
Denn je später im Prozess eine Änderung geschieht, desto höher ist die Wahrscheinlichkeit, dass sie Auswirkungen auf weitere Requirements hat. Je später also eine Anforderung als unrealistisch, inkorrekt oder wenig qualitativ identifiziert wird, desto teurer wird es.
Im Umkehrschluss bedeutet das, dass ein möglichst früh durchgeführtes Review das Risiko minimiert und eine solche Anforderung frühzeitig entdeckt und mit geringem Aufwand korrigiert werden kann.
Deshalb ist es wichtig, im Anforderungsmanagement einen geeigneten Kontrollprozess zu etablieren und die Anforderungen früh auf ihre Realisierbarkeit, Testbarkeit, etc. zu prüfen. Ein möglicher Freigabeprozess ist im Zuge der Planung – im Planning – mit vorzusehen. Ein Beispielprozess ist in der untenstehenden Abbildung dargestellt.
Den Wald vor lauter Bäumen nicht sehen – Vermeiden des Bestätigungsfehlers
Sie haben einen Reviewprozess implementiert, mit dem Sie Ihre Anforderungen prüfen und abstimmen können. Dennoch treten fehlerhafte Anforderungen auch in der fortgeschrittenen Entwicklung auf. Wie kann es dazu kommen? Ein wichtiger Aspekt für die Absicherung der Anforderungsqualität durch Review-Prozesse liegt in der Vermeidung von sogenannten Bestätigungsfehlern. Das mehrfache Prüfen der Anforderungen minimiert Fehler.
Allerdings ist es allgemein bekannt, dass Menschen einer gewissen Selbsttäuschung erliegen können. Informationen, die gegen die eigene Meinung sind, werden dabei ignoriert oder so interpretiert, dass sie zur entsprechenden Ansicht passen. Es handelt sich dabei um ein Element aus der Humanpsychologie, welches sich Bestätigungsfehler nennt. Der Bestätigungsfehler wird im Syllabus der „Certified Tester Foundation Level“ (CTFL) Zertifizierung des „International Software Testing Qualifications Board“ (ISTQB) auch in Bezug auf Anforderungsreviews thematisiert:
„Ein Element der Humanpsychologie namens Bestätigungsfehler kann dabei hinderlich sein, Informationen, die aktuellen Überzeugungen widersprechen, zu akzeptieren. Beispielsweise erwarten Entwickler, dass ihr Code korrekt ist, und die Bestätigungsfehler erschweren es ihnen, zu akzeptieren, dass der Code nicht korrekt ist.“ (ISTQB, CTFL Syllabus, 2018)
Der Blick auf die eigenen Anforderungen kann daher etwas getrübt sein. Deshalb sollte vermieden werden, dass eine Anforderung, die von einer Person verfasst wird, auch von derselben Person erfolgreich geprüft werden kann. Es ist essenziell wichtig, alle Requirements durch mindestens eine zweite Fachkraft kontrollieren zu lassen. Ein effektiver Weg ist es die Anforderung durch eine weitere Fachkraft auf die inhaltliche Korrektheit zu überprüfen.
Bekannt ist diese Methode auch als Peer-Review, welche häufig bei wissenschaftlichen Publikationen angewendet wird, um die Qualität der Veröffentlichung zu bestätigen. Das aus dem englischen stammende Wort Peer bedeutet so viel wie Gleichgesinnter. Im Unternehmen sollte die Anforderung also durch Kolleg*innen überprüft werden, welche im gleichen Fachgebiet arbeiten, um die Auswirkungen, Abhängigkeiten und die Umsetzung der Anforderungen auch aus technischer Sicht korrekt bewerten zu können. Zusätzlich zur inhaltlichen Prüfung sollten die Anforderungen außerdem durch Requirements Engineers auf die formelle Richtigkeit überprüft werden.
Die Anforderungen mit gezielten Methoden und durch einen größeren Personenkreis kontrollieren zu lassen, verringert das Risiko einer Änderung dieser im Nachhinein maßgeblich. Eine einfache Möglichkeit ist hierbei das informelle Review. Es handelt sich dabei um das umgangssprachlich sogenannte „Vier-Augen-Prinzip“. Der*die Verfasser*in einer Anforderung gibt die Anforderung als Arbeitsprodukt an eine Person/Gruppe zur Validierung weiter. Die Überprüfung beim informellen Review folgt dabei keinem definierten Ablauf. Der Entwurf wird allerdings innerhalb einer festgelegten Zeitspanne analysiert und kommentiert. Der*die Autor*in erhält die Anmerkungen zur Anpassung der Anforderung zurück. Nun gilt es zu entscheiden, ob und wie diese eingearbeitet werden.
Weitere anwendbare Methoden sind Inspektionen und Walkthroughs, welche zu den formalen Reviews zählen. Sie sind durch einen vorgeschriebenen Ablauf definiert und werden häufig bei Meilensteinen oder finalen Versionen angewendet. Eine Besonderheit von Inspektionen sind die zugeteilten Rollen. Ein*e unabhängige*r Moderator*in leitet die Rezension. Die Inspektoren, bestehend aus Fachkollegen und Experten, prüfen und bewerten das Arbeitsprodukt anhand von Anforderungen und Zielen. Der*die Verfasser*in versucht die Kritik und deren Auswirkung zu verstehen und erklärt Funktionen nur bei Bedarf.
Bei einem Walkthrough erklärt der*die Autor*in sein Arbeitsprodukt einem ausgewählten Kreis von Reviewern interaktiv. Die Teilnehmer können Fragen stellen und sich austauschen. Der*die Autor*in kann das Arbeitsprodukt weiter erläutern oder direkt Lösungen diskutieren. Diese Form des Reviews wird meist in frühen Projektphasen eingesetzt und wird auch nicht nur im klassischen Anforderungsmanagement angewandt. In der agilen Entwicklung im Zusammenhang mit Scrum wird meist am Ende von Sprints das sogenannte Sprint Review durchgeführt.
Das Sprint Review ist ein Meeting am Ende eines Sprints, bei dem das Scrum Team und alle Stakeholder zusammenkommen, um zu reflektieren, was während des Sprints erreicht wurde und ob die Ziele des Sprints erzielt wurden. Beteiligte Personen können hierbei auch der Product Manager, der Scrum Master, das Entwicklerteam und alle weiteren Personen sein, die im Entwicklungsprozess involviert sind.
Nicht zu verwechseln ist das Sprint Review mit dem Retrospective, obwohl es sich bei beiden Meetings um eine Form des Reviews handelt. Der Unterschied zwischen Review und Retrospective besteht hierbei im Detail.
Das Sprint Retro Meeting findet im Anschluss an das Sprint Review statt. Während bei dem Review darüber diskutiert wird, was entwickelt wurde, wird beim Sprint Retrospective der Fokus daraufgelegt, wie etwas umgesetzt wurde. Dabei wird der Prozess reflektiert. Es werden Fragen beantwortet wie, was läuft gut, was könnte verbessert werden und wie könnte die Produktivität insgesamt gesteigert werden.
Was bedeutet das nun für Ihr Anforderungsmanagement?
Die Gründe wurden erläutert, warum das inhaltliche und formelle Überprüfen der Anforderungen durch einen Reviewprozess im Workflow Ihrer Entwicklung einen sicheren Weg darstellt, die Qualität Ihrer Anforderungen auf ein hohes Niveau zu bringen. Beim Implementieren des Prozesses sollte immer ein gutes Gleichgewicht zwischen Effektivität und Kosten hergestellt werden. Welche Methoden und wie die Validierung erfolgt, ist vor allem abhängig von der Komplexität Ihres Projektes. Bei kleineren Projekten lohnt sich beispielsweise die Form des informellen Reviews. Bei aufwändigeren Projekten, welche eine größere Anzahl an Anforderungen aufweisen oder auch spezielle Sicherheitsvorgaben oder Qualitätsansprüche einhalten müssen, sollte das Review tiefgreifender definiert sein. Hierbei bietet sich auch die Unterstützung durch geeignete Tools und Werkzeuge an.
Unsere langjährige Erfahrung in unterschiedlichsten Branchen und der stetige Wissensausbau zu effektiven Methoden und Tools haben wir in unserem Center of Competence (CoC) Anforderungsmanagement gebündelt. Profitieren Sie von unserer Expertise im Anforderungsmanagement. Kontaktieren Sie uns und wir finden gemeinsam die für Sie optimale Lösung.
LIZENZEN:
- Headerbild: „Business teamwork works with a tablet with internet streaming service“ / ©alphaspirit/ stock.adobe.com