Anforderungsdokumentation ist nicht generell sinnvoll!

Vor etwa zwei Jahren habe ich mit einem Kunden die Fragestellung erörtert, inwieweit sich User Stories in einer Entwicklung im regulierten Umfeld einsetzen lassen. Es herrschte die Meinung, User Stories seien gänzlich ungeeignet um im regulierten Umfeld eingesetzt zu werden, da sie nicht detailliert genug seien, um als geforderte Anforderungsdokumentation zu dienen.

Zur Charakteristik von User Stories führt Ron Jeffries in seinem Artikel »Essential XP: Card, Conversation, Confirmation« drei Aspekte ins Feld, die nahelegen, dass eine User Story weniger zur Dokumentation von Anforderungen als eher zur Kommunikation selbiger nützlich ist:

…
The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is. The card is a token representing the requirement.
…
The requirement itself is communicated from customer to programmers through conversation: an exchange of thoughts, opinions, and feelings.
…
Ron Jeffries

Offensichtlich können User Stories tatsächlich nicht die in einem regulierten Umfeld geforderte Anforderungsdokumentation darstellen. Man könnte stattdessen synchron zu jeder User Story die geforderte Anforderungsdokumentation erstellen. Dabei müsste man sich allerdings die Frage stellen, ob man nicht gleich, wie gewohnt, eine klassische Anforderungsspezifikation erstellen könnte, die wiederum die User Stories obsolet werden ließe.

Um diese Problemstellung zu klären, muss man sich vor Augen führen, zu welchem Zeitpunkt dokumentierte Anforderungen überhaupt nützlich sind.

Zu einem Zeitpunkt t₀ zu dem einem Entwicklungsteam eine Anforderungsinformation bekannt wird, hat es keinen Wert, sie in dokumentierter Form zu haben. Schließlich ist die Anforderung bekannt und es wird gerade darüber geredet.

Das andere Extrem stellt der Zeitraum dar, in dem eine Anforderung gänzlich in Vergessenheit geraten ist. In diesem Zeitraum hat die existierende Anforderungsdokumentation ihren größten Wert, da sie jederzeit weiterverarbeitet werden kann, sei es zur Weiterentwicklung, zur Findung von Fehlerursachen oder zu anderen Zwecken.

Zwischen den beiden genannten Extremen existiert ein Übergang. Nach dem Bekanntwerden einer Anforderung, beschäftigen wir uns mit ihren Details. Wenn wir die Anforderung durch eine User Story repräsentieren, unterhalten wir uns über deren Details und halten diese mindestens stichwortartig fest, damit wir sie nicht vergessen. Wenn wir die Anforderung zeitnah implementieren, was im agilen Umfeld durchaus üblich ist, genügen an dieser Stelle Stichworte, um uns schnell wieder an die Details zu erinnern. Würden wir statt der Verwendung von Stichworten und Skizzen alles vollständig ausdokumentieren, müssten wir wahrscheinlich einen enormen Aufwand betreiben, sich ändernde Details nachzudokumentieren.

Sobald eine Anforderung implementiert ist, ändert sich die Situation. Die implementierte Anforderung existiert nun als Eigenschaft unseres Produktes. Ab diesem Zeitpunkt beschäftigen wir uns nicht mehr zum Zwecke der Implementierung mit der Anforderung und propagieren die Anforderung nicht mehr in dem Maße, wie wir es zuvor getan haben. Spätestens jetzt setzt ein rapider Prozess des Vergessens ein, der den Wert einer detaillierteren Dokumentation treibt.

Nehmen wir an, wir wüssten, welcher Detailgrad an dokumentierten Anforderdungen uns in Zukunft nützt. Wann wäre dann der optimale Zeitpunkt, Anforderungen entsprechend detailliert zu dokumentieren?

Meiner Meinung nach sollte man das adäquate Dokumentieren der Anforderungen als integralen Bestandteil des Implementierens sehen. Zu keinem Zeitpunkt außer zum Zeitpunkt des Implementierens sind uns mehr Details einer Anforderung bewusst. Wenn wir mit User Stories arbeiten, dann können wir diese dazu nutzen, um über noch nicht implementierte Details zu kommunizieren und diese stichwortartig festzuhalten. Sobald wir eine User Story umsetzen, können wir die zukünftig wertvollen Details in einer Systemdokumentation festhalten. Jene Systemdokumentation ist dann auch wiederum geeignet, um eventuellen regulatorischen Vorschriften von Anforderungsdokumentation gerecht zu werden.

Unsere Überlegung hat mir mal wieder vor Augen geführt, wie vielschichtig das Thema Anforderungen uns in der täglichen Entwicklungsarbeit und darüber hinaus begegnet. Es existiert nicht das eine Patentrezept im Umgang mit Anforderungen. Stattdessen muss uns klar sein, welche Zwecke erfüllt werden müssen, bevor wir in die Trickkiste greifen und User Stories, Modellierungstechniken, Dokumentationstechniken etc. hervorziehen.

Falls Sie nun Ihre Trickkiste rund um das hier aufgegriffene Thema auffüllen möchten, könnten die folgenden beiden Kurse von HOOD für Sie besonders interessant sein:

• Textuelle Anforderungen gut und effizient formulieren
• Certified Agile Requirements Specialist (CARS)

Philip Stolz

Kontaktieren Sie Philip Stolz

Herr Philip Stolz ist als Senior Consultant im Bereich Requirements Engineering (RE) tätig. Seine Schwerpunkte liegen in der Einführung und Prozessverbesserung von Requirements Engineering (RE). Herr Stolz verfügt über eine fundierte Ausbildung im Bereich Software Engineering (Dipl.-Inf., Softwaretechnik). Durch Erfahrung aus unterschiedlichen Entwicklungsprojekten in verschiedenen industriellen Branchen sind ihm typische Projektsituationen sowie das Vorgehen bei der Einführung methodischer Verfahren innerhalb von Projektteams bekannt.