Seite 3: Anforderungen

Inhaltsverzeichnis

Anforderungen finden und weitergeben

Welche Technik man für die Anforderungsermittlung einsetzt, hängt stark von den Rahmenbedingungen eines Projekts ab. Wie leicht sind Kunden zur Mitarbeit zu motivieren, und wie gut können die Stakeholder ihre Wünsche zum Ausdruck bringen? Will man neue, innovative Ideen entwickeln oder die Funktionen eines bestehenden Systems vollständig umsetzen, um es abzulösen? Allen agilen Ansätzen im Requirements Engineering ist gemein, dass sie den Kunden mit seinen Bedürfnissen in den Mittelpunkt stellen und eine gemeinsame Sprache für das Gesamtteam fordern. Genau die Prinzipien sind der Grund für den derzeitigen Erfolg agiler Vorgehen und führen zu maßgeblich besseren Spezifikationen und Produkten: In einer Internet-Umfrage hielten rund die Hälfte der befragten Projektmitarbeiter den unmittelbaren persönlichen Austausch mit dem Kunden für eine wichtige Errungenschaft agiler Vorgehen. Ganz ohne Spezifikationen geht es nur in seltenen Fällen, und zwar in meist kleinen und gut überschaubaren Projekten. Wo mehr als eine Handvoll Personen beteiligt sind, ist ohne angemessene Dokumentation Chaos zu erwarten. Verfälschungen und Missverständnisse schleichen sich leicht ein, ganz nach dem Prinzip der "Stillen Post", die jeder als Kind gespielt hat. Zudem ist die Gefahr hoch, von einem einzigen Wissensträger abhängig zu sein, wenn zum Beispiel die Anforderungen an das System nur eine Sache zwischen Systemanalytiker und Stakeholder sind.

Besonders fatal kann eine solche Abhängigkeit bei einer späteren Wartung oder Erweiterung des Systems sein, wenn der einzige Wissensträger des Altsystems vielleicht nicht mehr für die Firma arbeitet und keine schriftliche Dokumentation vorhanden ist. Zudem ist der Interpretationsspielraum bei zu wenig detaillierter und präziser schriftlicher Dokumentation oft relativ hoch. Einige agile Ansätze beugen dem vor, indem sie als mehr oder weniger einzige Dokumentation strukturierte objektorientierte Modelle erstellen, die, wenn denn alle Beteiligten das Modell verstehen können, den Interpretationsspielraum erheblich einschränken.

Dokumentation muss sinnvoll und gerechtfertigt sein. Projekte sollen nur dokumentieren, wenn sie einen triftigen Grund haben. Die Dokumentation muss ihnen einen konkreten Mehrwert verschaffen, andernfalls hat sie keine Berechtigung. Man sollte zielgerichtet unter folgenden Fragestellungen dokumentieren:

• Welchen Zweck soll die Dokumentation erfüllen?
• Dient sie dem Ordnen kreativer Gedanken?
• Dient sie als Kommunikationsmedium im Team beziehungsweise zwischen Team und Auftraggeber?
• Soll sie die spätere Benutzung und/oder Wartung des Systems vereinfachen?

Je nachdem für welchen Zweck und für welche Zielgruppe die Dokumentation bestimmt ist, lässt sie sich unterschiedlich gestalten.

Anforderungen "domptieren"

Dass in einem agilen Projekt keine Papierberge an schnell veraltender Dokumentation entstehen sollten, dürfte jedem klar sein. Doch für welchen Zeitraum erstellt man Dokumentation, und wie ist sie zu verwalten? Die Antwort ist, Dokumentation nur so lange aufzuheben, wie sie einen Zweck erfüllt. Ein während eines Stakeholder-Gesprächs zur Veranschaulichung schnell gezeichnetes Aktivitätsdiagramm braucht nicht in einer Datenbank zu verschmachten. Wenn es seinen Zweck erfüllt hat, kann man sich getrost davon trennen. Sicherlich gibt es Dokumentation, die erhalten bleiben soll, etwa die Zielsetzung des Projekts oder Informationen, die für die Pflege und Weiterentwicklung des Systems wichtig sind. Die Entscheidung, ob ein Dokument oder Modell ein langfristiger Teil der Projektdokumentation sein soll oder nicht, lässt sich laut Ambler vereinfachen, indem man auf folgende drei Merkmale achtet:

• Es gibt einen eindeutigen und wertschöpfenden Grund dafür, warum etwas zum permanenten Teil der Projektdokumentation wird.
• Es gibt ein Publikum, für das das Modell (oder das Dokument) wertvoll ist.
• Die Stakeholder sind bereit, in die Dokumentation zu investieren.

Wichtig ist, jegliche Dokumentation zu einem Projekt nur an einer einzigen Stelle zu lagern (single-source principle). Das hilft, schlecht verwaltbare Redundanzen zu vermeiden. Will man ein Dokument langfristig behalten, ist dafür Sorge zu tragen, dass es stets aktuell bleibt. Projekte müssen diesen Pflegeaufwand im Auge behalten, wenn sie Strukturen für ihre Projektdokumentation anlegen.