Anforderungsaufnahme und deren Dokumentation

Anforderungen, die vom Anforderungssteller formuliert werden, können von unterschiedlicher Art sein. Die Aufgabe des Product Owners ist es, alle Arten von Anforderungen zu formulieren. Anforderungen können unterschiedliche Arten haben. Bei der Entwicklung von Systemen erweitert sich dies jedoch noch um eine weitere Dimension. Grundsätzlich können Anforderungsarten unterschieden werden, wie zum Beispiel funktionale und nicht funktionale Anforderungen, oder qualitative Anforderungen und auch Anforderungen durch Rahmenbedingungen.

Weiterhin sind aber auch die Anforderungen unterschiedlicher Stakeholdergruppen zu beachten. Beispielsweise würde der klassische Product Owner, der Interesse an Funktionen eines Systems hat, sich ggf. ausschließlich auf die Realisierung von Funktionen konzentrieren. Hier würden dann die Aspekte eines z. B. Betriebsteams, welches das System im Anschluss an das Projekt betreut, ggf. vernachlässigt. Somit ergeben sich auch in agilen Methoden einige Anforderungen an die Anforderungen, um sicher zu stellen, dass alle Arten von Anforderungen von allen Anforderungssteller-Gruppen berücksichtigt werden.

Scrum definiert nicht die inhaltlichen Kriterien an Anforderungen, sondern sagt lediglich aus, dass allein der Product Owner für die Stellung der Anforderungen verantwortlich ist.

Somit hat der Product Owner darauf zu achten, dass alle relevanten Anforderungen in die Liste der Anforderungen, das Product Backlog, einfließen. In der Realität ergeben sich hieraus einige Herausforderungen, da häufig der Product Owner ein leitender Manager einer Fachabteilung ist und die technischen Aspekte häufig nur sehr schwer einschätzen kann.

Die Empfehlung dieses Konzeptes ist es, durch eine initial durchgeführte Stakeholder-Analyse die relevanten Anforderungssteller herauszufinden und nicht einen einzelnen Product Owner zu ernennen, sondern ein Product Owner Team aufzustellen. Dieses Team ernennt einen »Chief Product Owner«, der die vollständige Verantwortung trägt und bei Uneinigkeit Entscheidungen trifft.

Abbildung 1: Balance zwischen verschiedenen Anforderungsarten

Die hier dargestellte Abbildung zeigt auf, welche zusätzlichen Informationen durch den Anforderungssteller, den Product Owner, formuliert sein müssen, um Systeme ganzheitlich zu formulieren und auch nach initialem Entwicklungs-abschluss in eine Betriebsphase zu überführen.

Im Product Owner Team sollten sich dann die folgenden Rollen wiederfinden:

• fachlicher Anforderungssteller
• Verantwortlicher für den Betrieb des Systems
• Unternehmensarchitekt
• Prozessverantwortlicher
• professioneller Anforderungsanalyst

Der Anforderungsanalyst hilft mit professionellen Methoden dem Product Owner Team Anforderungen zu finden und diese zu formulieren. Eine wichtige Fähigkeit ist das initiale Finden von Anforderungen. Hier eignen sich besonders Interviewtechniken und auch moderierte Anforderungsworkshops.

Weiterhin hilft der Analyst dem Team, die Anforderungen in der Art festzuhalten, dass diese bestimmte inhaltliche Kriterien erfüllen, damit zumindest durch das Formulieren und schriftliche Festhalten der Anforderungen keine Informationen zwischen Anforderungssteller und dem Team verloren gehen.

Abbildung 2: Anforderungsaufnahme

Abbildung 2 zeigt auf, wie der Analyst vorgeht, um an Anforderungen zu gelangen: In Requirements-Engineering Workshops werden die Anforderungen aufgestellt; diese werden in Listen festgehalten; jede Anforderung bekommt eine eindeutige Nummer; Entscheidungen werden anhand von Protokollen festgehalten; diese Gesamtdaten ergeben die Menge der Anforderungen.

Sinnvolle und hilfreiche Kriterien an Inhalte von Anforderungen können zum Beispiel die durch den Standard IEEE 830 definierten Qualitätskriterien, die Kriterien der Sophist Group oder auch die INVEST-Kriterien nach Cohn sein (Siehe hierzu Abschnitt Standards).

Zu Beginn eines Projektes wird durch die Auswahl der Kriterien durch die Stakeholder festgehalten, welche Anforderungen an Anforderungen für das Projekt gelten.

Anforderungen ändern sich – das gilt für alle Projekte. Es ist also die Aufgabe eines Vorgehensmodells, dies zu berücksichtigen. In Scrum können sich Anforderungen verändern, jedoch nicht während eines Sprints. Je konkreter die Anforderungen formuliert sind, desto besser sind diese vom Team zu schätzen. Die Aufgabe von Scrum besteht darin, planbare Sprints zu formulieren. Die Agilität und das kontinuierliche Reagieren auf Ereignisse findet in Scrum nur außerhalb von Sprints statt. Die Projektjustierung kann zu jeder Zeit durch den Product Owner stattfinden, jedoch darf diese keine Auswirkung auf laufende Sprints haben. Sollten sich gravierende Auswirkungen auf einen Sprint ereignen, hat der ScrumMaster die Möglichkeit einer »Abnormal Sprint Termination«; er kann also unter besonderen Bedingungen den Sprint abbrechen.

Sinnvolle Artefakte für das Team können für die Formulierung von funktionalen Anforderungen UseCaseModelDocuments sein, in denen die Anforderungen in Form von Anwendungs-Fällen formuliert sind (Siehe hierzu Abschnitt Die Stufe 2 des Product Backlogs). Items könnten anhand einer WorkBreakdownStucture (Vorgehensweise aus PMI – Project Management Institute) aufgebrochen und detailliert werden. Hier könnte auch die Schätzung stattfinden. Anforderungen an das User-Interface könnten über grafische Vorgaben, den Screendesigns, festgehalten werden.

Durch Scrum ist formuliert, dass das Schätzen der Aufgaben im Planning Meeting stattfindet. In manchen Projekten ist dies nicht immer möglich, da einige Items so umfangreich sind, dass diese vorab ausführlich organisiert werden müssen. Somit können auch Schätzaufgaben für komplexe Anforderungen  Sprinttasks sein (Siehe hierzu Abschnitt Die Stufe 2 des Product Backlogs). Diese Items werden in einem Sprint geschätzt und erst in weiteren Sprints realisiert. In einem Sprint finden nicht die Schätzung und die Umsetzung statt.

Abbildung 3: Dokumentationsform von Anforderungen

Abbildung 3 zeigt einen Vorschlag, welche Artefakte pro Anforderung vorhanden sein sollten, so dass das Team diese Anforderungen optimal schätzen und umsetzen kann. Das Ziel ist es, Sprints planbar und verlässlich zu gestalten. Damit ist die Planbarkeit durch das Team gemeint, nicht ein Einwirken durch den ScrumMaster oder den Product Owner.

Jede funktionale Anforderung im PBL sollte detailliert sein durch UseCaseModelDocuments (UCMD) in dem die funktionalen Anforderungen anhand von Anwendungsfällen beschrieben werden (siehe hierzu Abschnitt Die Stufe 2 des Product Backlogs). Diese Anforderungen werden um Screendesigns zur Visualisierung der Anforderung erweitert. Alle Items werden um Tasks erweitert, bei großen Tasks werden diese nach dem Work Breakdown Structure Prinzip aufgebrochen und in den WBS Dokumenten im Detail geschätzt. Die Art der Dokumentation ist von der Anforderung abhängig. Eine Anforderung an Performance lässt sich selbstverständlich nicht über ein Screendesign dokumentieren, jedoch textuell und in Form einer WBS.

Anforderungen werden im Laufe des Projektes weiter verfeinert. Über das Product Backlog werden dann weitere Ausdetaillierungen verlinkt, die dem Team zur Verfügung gestellt werden. Ist Traceability eine Anforderung an die Dokumentation, muss dies hier beachtet werden.

Vor dem ersten Sprint eines Projektes ist zu entscheiden, mit welcher Vorgehensweise der Product Owner das initiale Product Backlog zusammenstellt.

Es kann empfehlenswert sein, selbst diese Aufgaben als Sprints zu organisieren oder aber auch eine Initialphase von einigen Tagen/Wochen einzulegen, die Scrum losgelöst ist und das initiale Product Backlog organisiert. Sollten sich die ersten Anforderungen mit geringem Zeitaufwand beschreiben lassen, kann auch zunächst mit einem sehr kleinen Team gestartet werden und dieses abhängig von den weiteren Anforderungen, die noch formuliert werden, aufgestockt werden. Dies ist vom Product Owner zu entscheiden.