Abb.1: Die fünf Grundprinzipien des Requirements Engineerings in agilen Projekten
1. Späte Detail-Spezifikation
Die schriftliche Spezifikation zum spätest sinnvollen Zeitpunkt erstellen.
Der spätest mögliche sinnvolle Zeitpunkt ist jener Zeitpunkt, zu dem der Aufwand für das Erstellen und nachträgliche Ändern der Spezifikation möglichst klein ist,
gegenüber dem Aufwand, der mit anderen Kommunikationsformen aufgewendet würde, wenn die Spezifikation nicht schriftlich erstellt wird.
Möglichst viele Details in die Testspezifikation verlagern.
Da sich Anforderungsspezifikation und Testspezifikation zu einer Gesamtspezifikation ergänzen, ist es sinnvoll, die Details nicht in der Anforderungsspezifikation, sondern in einer Testspezifikation festzuhalten. Tests sind hier nichts anderes als eine Requirements-Spezifikation aus einer etwas anderen Sicht. Auch in der Testspezifikation können die grundlegenden Requirements-Spezifikationstechniken angewendet werden.
2. Umsetzungsdetails bleiben draußen!
Nur das spezifizieren, was einen zusätzlichen Informationsgehalt für den Kunden bringt. Das WIE – also Entwicklungs- und Umsetzungsvorgaben, z.B. wie die Datenbank intern aufgebaut sein soll, sollte in der Anforderungsspezifikation des Auftraggebers vermieden werden. Es schränkt die Entwickler nur unnötig ein und verhindert gute alternative Lösungsansätze. Außerdem kann und will der Kunde technische Details meist nicht beurteilen.
3. Risiko und zeitlicher Abstand zur Umsetzung steuern Detailgrad
Den Detaillierungsgrad passend zum Haftungsrisiko und potentiellen Wissensverlust wählen.
Menschen vergessen in kurzer Zeit sehr viel von dem, was besprochen wird. Nach fünf Tagen sind nur mehr ca. 25-50% des Wissens vorhanden (WIKIPEDIA). Daher ist es notwendig, die wichtigen Dinge schriftlich festzuhalten, um nachträglich unnötige Probleme oder Diskussionen, wie das denn nun wirklich vereinbart war, zu vermeiden.
4. Effizienz im Requirements-Management
Die Beziehungen zwischen Artefakten effizient verwalten!
In jedem Projekt sind viele Abhängigkeiten zwischen den Artefakten vorhanden. Wenn man sich dazu entscheidet, Artefakte und deren Beziehungen zu erstellen und zu verwalten,
dann ist es zwingend nötig, bei allen Änderungen auch alle Abhängigkeiten zu aktualisieren.
Im Bereich der Beziehungsverwaltung gilt der Grundsatz, dass alles, was einfach, automatisch und tool-unterstützt verwaltet und gemanagt werden kann, auch einen Mehrnutzen für das Projekt bedeutet. Beziehungen, die manuell gepflegt werden müssen, sind oft inkonsistent und den investierten Aufwand nicht wert.
Alle Artefakte und deren Beziehungen sollten in geeigneten datenbankgestützten Tools verwaltet werden, da dies die Wartung deutlich vereinfacht und eine effiziente Handhabung überhaupt erst möglich macht.
5. Änderungen akzeptieren und konsistent umsetzen
Änderungen an Spezifikationen zulassen!
Im Laufe des Projekts ändern sich Anforderungen und eventuell auch Rahmenbedingungen. Änderungen sind meist mit zusätzlichem Aufwand verbunden. Der Grundsatz soll also lauten: Änderungen sind eine gute Sache, wenn wir professionell und effizient mit ihnen umgehen!
Solange noch nicht mit der Umsetzung begonnen wurde, sind Änderungen an der Spezifikation ja auch vergleichsweise kostengünstig.
Bei Änderungen alle abhängigen Artefakte konsistent halten
Änderungen sind unvermeidlich. Die Konsequenz daraus ist, dass sie möglichst effizient behandelt werden müssen. Wenn zum Zeitpunkt einer Anforderungsänderung noch nichts programmiert wurde, ist es meist einfach, die Konsistenz herzustellen. Problematisch und aufwändig wird es, wenn Änderungen an schon umgesetzten Teilen erfolgen.
Bei Orientierung an diesen Grundregeln kann ein für das agile Umfeld passendes und strukturiertes Requirements-Engineering erreicht werden, das gute Erfahrungen des klassischen Requirements-Engineerings berücksichtigt und eine sinnvolle Ergänzung der agilen Vorgehensweise darstellt.
