{"id":4331,"date":"2020-01-30T09:59:14","date_gmt":"2020-01-30T07:59:14","guid":{"rendered":"https:\/\/blog.iese.fraunhofer.de\/?p=4331"},"modified":"2024-05-27T13:39:46","modified_gmt":"2024-05-27T11:39:46","slug":"anforderungsdokumentation-4-dokumentationsumfang-eingrenzen","status":"publish","type":"post","link":"https:\/\/www.iese.fraunhofer.de\/blog\/anforderungsdokumentation-4-dokumentationsumfang-eingrenzen\/","title":{"rendered":"Anforderungsdokumentation (4\/5): Dokumentationsumfang eingrenzen bei der Dokumentation agiler Anforderungen"},"content":{"rendered":"

Die Anforderungsdokumentation ist ein wichtiges Werkzeug im Anforderungsmanagement. In Projekten, in denen sich Anforderungen im Verlauf nicht wesentlich \u00e4ndern, 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 \u00e4ndern. Die daraus entstehende Notwendigkeit, die Dokumentation anzupassen und zu aktualisieren, wird oft als unn\u00f6tiger Mehraufwand angesehen. Wieso es zu dieser Wahrnehmung kommt und wie der Umgang mit Dokumentation gestaltet werden kann, sodass deren Vorteile im agilen Kontext \u00fcberwiegen, untersuchen wir in dieser f\u00fcnfteiligen Reihe von Blog-Artikeln.<\/p>\n

\n

Dieser Blog-Post ist der erste Teil einer f\u00fcnfteiligen Serie von Artikeln zum Thema Anforderungsdokumentation.<\/p>\n

 <\/p>\n

\u2460 Warum eine Anforderungsdokumentation erstellen?<\/a>
\nTeil\u00a01 untersucht, warum Anforderungen \u00fcberhaupt dokumentiert werden.<\/p>\n

\u2461 Der Mythos \u201eKeine Dokumentation\u201c f\u00fcr agile Anforderungen<\/a>
\nTeil 2 untersucht, wie die Anforderungsdokumentation agil bleiben kann, ohne Chaos zu verursachen.<\/p>\n

\u2462 Typische Herausforderungen bei der Dokumentation agiler Anforderungen<\/a><\/p>\n

Teil 3 untersucht wie Dokumentation eine konstruktive Rolle in einer agilen Umgebung spielen kann.<\/p>\n

\u2463 Dokumentationsumfang eingrenzen bei der Dokumentation agiler Anforderungen<\/a><\/p>\n

Teil 4 untersucht, wie das Chaos verhindert wird, dass durch ein Auswuchern der Dokumentation entstehen kann.<\/p>\n

\u2464 Welche Art von Werkzeugen ben\u00f6tige ich f\u00fcr die Anforderungsdokumentation?<\/a><\/p>\n

Teil 5 untersucht, welche Werkzeuge f\u00fcr die Anforderungsdokumenationen verwendet werden, um in agilen Kontexten eine Bereicherung darzustellen.<\/p>\n<\/div>\n

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

Dokumentierte Anforderungen sind notwendig, um die Kommunikation zu f\u00f6rdern, besonders innerhalb des Entwicklungsteams, aber auch mit anderen Stakeholdern. Sie helfen Praktikern, besser zu verstehen, was die Stakeholder brauchen. Au\u00dferdem sind sie n\u00fctzlich, wenn es darum geht, fr\u00fchzeitiges Feedback in kurzen Feedbackzyklen zu bekommen und sich an ver\u00e4nderte Bed\u00fcrfnisse 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\u00e4nkungen behindern oft die direkte verbale Kommunikation [6]. Folglich sollte nicht einfach von optimaler Kommunikation ausgegangen werden.<\/p>\n

Was den agilen Wert betrifft, bei dem es darum geht, dass funktionierende Software \u00fcber umfassende Dokumentation gestellt wird, so sollte die optimale Menge und der optimale Detaillierungsgrad der dokumentierten Anforderungen f\u00fcr jede einzelne Projektsituation neu \u00fcberdacht werden. Dabei kann dies aus einer Bottom-Up- oder aus einer Top-Down-Perspektive betrachtet werden.<\/p>\n