Neben den (eigentlich) selbstverständlichen Grundregeln der Kommunikation, die wir alle beherrschen sollten, wie freundliche Umgangsformen und ein wertschätzendes Feedback, benötigen wir für Reviews noch ein paar weitere Regeln. Formulieren Sie die Ziele, die Sie mit einem Review verfolgen oder als Reviewergebnis erwarten, klar und eindeutig. Setzten Sie immer einen Termin, bis wann Sie eine Rückmeldung erwarten und halten Sie im Gegenzug auch Termine und Zusagen ein.

Zusätzlich sollten Sie folgende Prinzipien der Prüfung kennen und entsprechend einsetzen:

Beteiligung der Stakeholder
Anforderungen können intern und extern geprüft werden. Interne Prüfungen sind einfach zu koordinieren, können aber zu Konflikten zwischen Prüfern und Erstellern führen. Externe Prüfungen erfordern u.a. durch die Einarbeitung in den Kontext mehr Aufwand, eignen sich aber besonders für einen hohen Qualitätsgrad der Anforderungen. Grundsätzlich sollte der Prüfer immer unabhängig sein.

Trennung der Fehlersuche von der -korrektur
Durch dieses bewährte Prinzip der Qualitätssicherung  von Software werden deutlich bessere Ergebnisse bei der Überprüfung von Anforderungen erzielt, da eine frühzeitige Korrektur von Fehlern häufig zusätzliche Fehler erzeugt, oder durch Struktur- und Kontextänderungen fallen Teile weg, deren Prüfung somit sinnlos gewesen wäre.

Prüfung unterschiedlicher Sichten
Bei der perspektivenbasierten Prüfung nehmen Sie unterschiedliche Sichten auf Ihre Anforderungen ein. So prüfen Sie z.B. aus der Sicht des Kunden/Nutzers, ob die Anforderungen die gewünschte Funktionalität und Qualität beschreiben. In der Perspektive des Testers prüfen Sie, ob die Anforderungen die notwendigen Informationen enthalten, um Testfälle daraus abzuleiten. Es können auch andere Sichten wie z.B. Inhalt, Abgestimmtheit oder Dokumentation angenommen werden.

Wechsel der Dokumentationsform
Wenn Sie ihre Anforderungen in eine andere Dokumentationsform überführen, können Sie die Stärken der einen Dokumentationsform nutzen, um die Schwächen einer anderen auszugleichen. Somit werden Fehler auch leichter identifiziert. Überführen Sie z.B. natürlichsprachliche Anforderungen in ein Aktivitätsdiagramm, werden Ihnen bestimmt noch ein paar Alternativabläufe oder Sonderfälle auffallen, die noch nicht textuell beschrieben wurden.

Konstruktion von Entwicklungsartefakten
Bei der beispielhaften Überführung der Anforderungen in nachgelagerte Entwicklungsartefakte, z.B. Test oder Entwurf, werden Fehler durch die Prüfung der Eignung für das Artefakt aufgedeckt. Dieses Vorgehen ist zwar sehr ressourcenaufwändig, aber auf diese Weise werden Fehler entdeckt, die anders nur sehr schwer zu finden wären.

Wiederholte Prüfung
Denken Sie immer daran, dass die Prüfung nur eine Momentaufnahme ist! Die Anforderungen und der Wissensstand der Prüfer und Stakeholder ändern sich mit dem Projektverlauf. Folgende Punkte sind Indizien dafür, dass eine wiederholte Prüfung erfolgen sollte: hoher Innovationsanteil in dem System, hoher Wissenszugewinn während des Requirements Engineerings, längerfristige Projekte, sehr frühe Prüfung von  Anforderungen, wenn Sie sich in einer unbekannten Domäne bewegen, oder Anforderungen wiederverwenden.

Sollte es in Ihrem Projekt zu einem Konflikt kommen, egal ob es sich um einen
Sach-, Interessens-, Werte-, Beziehungs-, Strukturkonflikt oder vermischte Konflikte handelt: versuchen Sie ihn als Ausgangsbasis für neue Ideen zu sehen. Konflikte sind per sé nichts schlechtes, häufig auch eine Chance auf bessere Zusammenarbeit. Aber trotzdem ein Risiko für das Projekt. Deswegen müssen Konflikte so schnell wie möglich entdeckt, analysiert, aufgelöst und dokumentiert werden. Interessieren Sie sich für Konfliktlösungstechniken? Dann werfen Sie doch mal einen Blick in unser Buch Requirements-Engineering und –Management.

Und im nächsten und letzten Teil dieser Blogserie erwartet Sie ein Experteninterview von Rolf Götz zu Extreme Inspections, Projekterfahrung und Zahlen, Daten, Fakten. Seien Sie gespannt!

Bildquellen:

Titel: Stack of letters
Quelle: iStockphoto
Autor: cogal

Reviews – Teil 1 – Wieso? Weshalb? Warum?
Reviews – Teil 2: Reviewtechniken
Reviews – Teil 3: Unterstützende Techniken