Anforderungsdokumentation (4/5): Dokumentationsumfang eingrenzen bei der Dokumentation agiler Anforderungen

Die Anforderungsdokumentation ist ein wichtiges Werkzeug im Anforderungsmanagement. In Projekten, in denen sich Anforderungen im Verlauf nicht wesentlich ändern, kann eine gute Dokumentation relativ leicht erreicht werden. Bei agilen Projekten hingegen liegt es in der Natur der Sache, dass sich Anforderungen sowie deren Zusammensetzungen stetig ändern. Die daraus entstehende Notwendigkeit, die Dokumentation anzupassen und zu aktualisieren, wird oft als unnötiger Mehraufwand angesehen. Wieso es zu dieser Wahrnehmung kommt und wie der Umgang mit Dokumentation gestaltet werden kann, sodass deren Vorteile im agilen Kontext überwiegen, untersuchen wir in dieser fünfteiligen Reihe von Blog-Artikeln.

Im ersten Teil haben wir untersucht, warum Anforderungen überhaupt dokumentiert werden. Im zweiten Teil dieser Serie haben wir thematisiert, dass es nie darum ging, die Anforderungsdokumentation bei der agilen Entwicklung ganz entfallen zu lassen, sondern dass diese weiterhin ein integraler Bestandteil des Entwicklungsansatzes ist. Damit Requirements Engineering jedoch in agilen Umgebungen funktioniert, müssen bestimmte Herausforderungen bewältigt werden, die wir in Teil 3 beschrieben haben. In diesem vierten Teil gehen wir davon aus, dass Anforderungen dokumentiert werden, aber dass noch ein finales Hindernis überwunden werden muss: Wie lässt sich das Chaos verhindern, dass durch ein Auswuchern der Dokumentation entstehen kann?

Dokumentierte Anforderungen sind notwendig, um die Kommunikation zu fördern, besonders innerhalb des Entwicklungsteams, aber auch mit anderen Stakeholdern. Sie helfen Praktikern, besser zu verstehen, was die Stakeholder brauchen. Außerdem sind sie nützlich, wenn es darum geht, frühzeitiges Feedback in kurzen Feedbackzyklen zu bekommen und sich an veränderte Bedürfnisse der Stakeholder anzupassen. Bei optimaler verbaler Kommunikation, wo der Austausch intensiv und kontinuierlich ist, kann die Anforderungsdokumentation vielleicht weniger formalisiert stattfinden, aber verteilte Teams, Sprachbarrieren und zeitliche Einschränkungen behindern oft die direkte verbale Kommunikation [6]. Folglich sollte nicht einfach von optimaler Kommunikation ausgegangen werden.

Was den agilen Wert betrifft, bei dem es darum geht, dass funktionierende Software über umfassende Dokumentation gestellt wird, so sollte die optimale Menge und der optimale Detaillierungsgrad der dokumentierten Anforderungen für jede einzelne Projektsituation neu überdacht werden. Dabei kann dies aus einer Bottom-Up- oder aus einer Top-Down-Perspektive betrachtet werden.

• Bei der Bottom-Up-Perspektive wird überlegt, was das Minimum an dokumentierten Informationen ist. Die Kommunikation innerhalb des Teams ist ein Schlüsselaspekt bei der Entscheidung darüber, was dokumentiert werden sollte und was nicht. Informationen sollten nur dokumentiert werden, wenn es für sie ein Zielpublikum gibt, in diesem Fall einen konkreten Kunden, für den die Informationen dokumentiert werden [1], und wenn der Einsatz der Dokumentation einen Mehrwert liefert [6]. Die Berücksichtigung und regelmäßige Einbindung eines Kunden in einem Projekt kann bereits viele Probleme hinsichtlich der Notwendigkeit, Verständlichkeit und Mehrdeutigkeit von Anforderungen lösen. Einige Stakeholder außerhalb des Projekts können jedoch auch ein wichtiges Zielpublikum sein, das die Dokumentation einer bestimmten Anforderung rechtfertigt. So können beispielsweise gesetzgebende und normative Gremien verlangen, dass bestimmte Anforderungen für rechtliche Zwecke dokumentiert werden, um Nachverfolgbarkeit zu gewährleisten oder um langfristige Wartbarkeit sicherzustellen.
• Aus der Top-Down-Perspektive werden Heuristiken angestrebt, um den Gesamtumfang der Anforderungsdokumentation einzugrenzen. Dabei geht es darum, wie sich „zu viel“ Dokumentation vermeiden lässt, was wiederum die Frage aufwirft, was als „zu viel“ oder als ein Übermaß an Dokumentation betrachtet wird. Auf diese Frage gibt es keine Universalantwort. Laut dem IREB sind die Größe des Projekts, die Zahl der beteiligten Stakeholder, das Vorhandensein rechtlicher Rahmenbedingungen und die Sicherheitsrelevanz des Projekts alles Faktoren, die bestimmen, welcher Grad an Dokumentation angemessen ist [1]. Dies kann in der Tat zu einer recht umfangreichen Menge an Backlogs führen, in denen die Eingrenzung der Anforderungsdokumentation durch einen PO immer wichtiger wird.

Referenzen:

[1] Adam, S., Doerr, J., Eisenbarth, M., Gross, A. (2009). Using Task-oriented Requirements Engineering in different domains: Experiences with applications in research and industry. In: Proceedings of the 17^th IEEE International Requirements Engineering Conference, pp. 267–272.

[6] Baumann, L., Hruschka, P., Lauenroth, K., Meuten, M., Reis, Rogers, G. et al. (2017). IREB Certified Professional for Requirements Engineering – RE@Agile Primer: Syllabus and Study Guide (Version 1.0.2). Karlsruhe, Germany: International Requirements Engineering Board e.V. Available online: https://www.ireb.org/content/downloads/28-cpre-re-agile-primer-syllabus/ireb_cpre_re%40agileprimersyllabusandstudyguide_en_v1.0.2.pdf (last accessed 11 June 2019).