Im Requirements Engineering (RE) spielt die Dokumentation von Anforderungen und verwandten Artefakten eine zentrale Rolle, zum Beispiel als Unterstützung für das Anforderungsmanagement. Jedoch sehen sich Anwender in der Praxis häufig mit Herausforderungen konfrontiert, was diese spezielle RE-Aktivität angeht.
Dieser Blog-Post ist der erste Teil einer fünfteiligen Serie von Artikeln zum Thema Anforderungsdokumentation.
① Warum eine Anforderungsdokumentation erstellen?
Teil 1 untersucht, warum Anforderungen überhaupt dokumentiert werden.
② Der Mythos „Keine Dokumentation“ für agile Anforderungen
Teil 2 untersucht, wie die Anforderungsdokumentation agil bleiben kann, ohne Chaos zu verursachen.
③ Typische Herausforderungen bei der Dokumentation agiler Anforderungen
Teil 3 untersucht wie Dokumentation eine konstruktive Rolle in einer agilen Umgebung spielen kann.
④ Dokumentationsumfang eingrenzen bei der Dokumentation agiler Anforderungen
Teil 4 untersucht, wie das Chaos verhindert wird, dass durch ein Auswuchern der Dokumentation entstehen kann.
⑤ Welche Art von Werkzeugen benötige ich für die Anforderungsdokumentation?
Teil 5 untersucht, welche Werkzeuge für die Anforderungsdokumenationen verwendet werden, um in agilen Kontexten eine Bereicherung darzustellen.
Die Rolle der Dokumentation im Requirements Engineering
Die Definition von RE seitens des IREB [1] zeigt, wie stark die Dokumentation / Spezifikation im Mittelpunkt des RE steht:
Ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:
- Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen;
- die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentieren sowie
- die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.
Die Kernaktivitäten des RE werden typischerweise in die unten abgebildeten vier Aktivitäten unterteilt, wobei einige Quellen die „Anforderungsanalyse“ noch als fünfte Aktivität betrachten, getrennt von der Phase der Validierung und Verhandlung.
Diese Abbildung verrät viel über die Aspekte und den Beitrag der Dokumentation im Rahmen von RE aus verfahrenstechnischer Sicht:
- Die Dokumentation ist logischerweise der Schritt, in dem die erhobenen Anforderungen in einer bestimmten Form vorgehalten werden. Ohne Anforderungsdokumentation können Anforderungen verloren gehen oder grob fehlinterpretiert werden.
- Die Dokumentation bietet eine solide Basis für die Validierung von Anforderungen und eine Quelle, in der Konflikte sichtbar werden, die durch Anforderungsverhandlungen gelöst werden müssen. Die Validierung erfordert klar dokumentierte Anforderungen, um als Diskussionsgrundlage dienen zu können.
- Die Dokumentation ist eine Quelle für die Erhebung von Anforderungen. Statt lediglich umfragebasierte Techniken (wie Interviews, Fokusgruppen und Fragebögen) oder Beobachtungstechniken einzusetzen, lassen sich viele (gute) Anforderungen an ein System aus den Anforderungsspezifikationen vorangegangener Versionen und Vorgängersysteme oder durch die Wiederverwendung von Anforderungen aus anderen Projekten ermitteln.
- Die Dokumentation unterstützt das Anforderungsmanagement, das sich auf die Handhabung von Anforderungen über die Zeit konzentriert, und zwar in wichtigen Aspekten wie Planung, Priorisierung, Überwachung und Änderungsmanagement. Ohne Dokumentation können viele Aspekte des Anforderungsmanagement nicht richtig durchgeführt werden.
Rolle der Anforderungsdokumentation im Systemlebenszyklus
Zusätzlich zu der zentralen Rolle, die die Anforderungsdokumentation im RE selbst spielt, ist die RE-Phase kein Selbstzweck, sondern der Fokus liegt auf dem, was darüber hinausgeht, denn sie bildet eine Basis für alle nachfolgenden Aktivitäten im Systemlebenszyklus (s. [1]), insbesondere:
- Dokumentierte Anforderungen, die mit dem richtigen Grad an Detaillierung ausgearbeitet sind, ermöglichen genauere Schätzungen für die Planung von Ressourcen.
- Die Anforderungsdokumentation spezifiziert viele der Rahmenbedingungen und Schlüsselaspekte, die den Architekturentwurf des Systems bestimmen.
- Die Anforderungsdokumentation enthält die Systemeigenschaften, die implementiert werden müssen, und die Qualität, die diese Eigenschaften erfüllen müssen.
- Basierend auf den dokumentierten Anforderungen lassen sich Testfälle ableiten oder sogar (automatisch) generieren, und das korrekte Systemverhalten kann spezifiziert werden.
- Bei korrekter Nachverfolgbarkeit innerhalb der Anforderungsdokumentation lässt sich mithilfe von Änderungsmanagement feststellen, ob eine angeforderte Änderung zulässig ist und was die Auswirkungen und Kosten einer Änderung sein werden.
- Die Anforderungsdokumentation ist eine wichtige Informationsquelle bei der Systemnutzung und Systemwartung und kann eine Basis für Benutzerhandbücher und Entwicklerdokumentation bilden.
- Die Anforderungsdokumentation unterstützt die Vertragsverwaltung in den frühen Phasen eines Projekts, im Laufe des Projekts, wenn Änderungen auftreten, und bei Nachverhandlungen.
Schlüsselbeiträge der Anforderungsdokumentation
Umgang mit Komplexität: Das Dokumentieren von Anforderungen spielt eine Rolle beim effizienten Umgang mit Inhalten. Es ist wichtig zu verstehen, dass ein Anforderungsdokument nicht nur eine Sammlung von Anforderungen ist, sondern dass dazu auch alle verwandten Artefakte gehören. Jede Anforderung kann viele verschiedene Arten von Artefakten haben, einschließlich solcher, die die Grundlage für seine Existenz bilden (z.B. Interviewprotokolle), Produkte der Arbeit mit der Anforderung (z.B. Abstimmungsprotokolle, Änderungsanfragen) und auf Basis der Anforderung erstellte Materialien (z.B. Validierungsberichte, Code Snippets). Zusammen können diese enorme Mengen an Informationen bilden. Außerdem beziehen sich die meisten Artefakte auf mehrere Anforderungen, weshalb diese referenziert werden müssen, statt zusammen mit einer einzelnen Anforderung gespeichert zu werden. Wenn die Anforderungen, die Beziehungen zwischen ihnen und die zugehörigen Artefakte richtig strukturiert sind, ermöglicht die Dokumentation es, diese Komplexität zu bewältigen.
Erlangung von Rechtskonformität: Die Anforderungsdokumentation kann auf zwei verschiedene Arten rechtliche Auswirkungen haben. Erstens kann ein Anforderungsdokument im deskriptiven Sinn festlegen, welche Gesetze, Vorschriften oder Normen einzuhalten sind, und Anforderungen beinhalten, die die Konsequenzen dieser rechtlichen Aspekte operationalisieren. Dies stellt sicher, dass das System als solches rechtskonform ist, und die Dokumentation gilt als Nachweis, der den Prozess der Akkreditierung oder Überprüfung erleichtert. Zweitens kann ein Anforderungsdokument im präskriptiven Sinn Teil eines rechtlich verbindlichen Vertrags zwischen einem Kunden, der die Anforderungen spezifiziert, und der Partei, die die Entwicklung des Systems übernimmt, sein. In diesem Fall dienen die Anforderungen als Kriterien, anhand derer festgestellt wird, ob das System gemäß Spezifikation erstellt wurde.
Sicherstellung von Wissensmanagement: Über ausgedehnte Zeiträume hinweg dient die Anforderungsdokumentation zum Rückgriff auf den ursprünglichen Zweck des Systems, als Erinnerung an beabsichtigte oder geplante Use Cases und als eine Historie der Entscheidungen im Laufe der Entwicklung [2]. Die Dokumentation kann bei einem (langfristigen) Projekt zu Rate gezogen werden und ebenso im Nachgang zu einem abgeschlossenen Projekt.
Unterstützung der Stakeholder-Kommunikation: Die Anforderungsdokumentation erleichtert die Kommunikation zwischen den Stakeholdern in mehrfacher Hinsicht. Sie stellt eine starke Ausgangsbasis für Diskussionen dar und ermöglicht Abstimmungen selbst im Falle verteilter Teams. Beispielsweise definiert sie die Rolle des Product Owners gegenüber dem Entwicklungsteam viel klarer. Dokumentierte Anforderungen unterstützen außerdem ein gemeinsames Verständnis, besonders wenn sie Modelle enthalten oder klar formuliert sind. Die Stakeholder können die Informationen auch zu einem späteren Zeitpunkt noch einmal lesen, um ihr Gedächtnis aufzufrischen. Das ist besonders dann wichtig, wenn die Informationen komplex sind.
Förderung des iterativen Denkens: Das Dokumentieren von Gedanken und Ideen hilft demjenigen, der sie aufschreibt, in seinem kreativen Prozess. Durch das Aufschreiben wird man in einen bestimmten Geisteszustand versetzt, der einem hilft, Lücken zu entdecken. Diese Notizen kann man sich auch noch einmal ansehen, um sie weiter zu verbessern, wenn neue Ideen auftauchen. In diesem Fall dient die Dokumentation bereits einem Zweck, bevor entschieden wird, ob sie Teil der Anforderungsdokumentation werden soll: nämlich dem, dass der Autor in die Lage versetzt wurde, sein Wissen über das System und seine Ideen dafür zu erforschen.
Einführung und Umsetzung eines Prozesses, um Anforderungen zu dokumentieren
Nur eine Struktur für die Anforderungsspezifikation zu haben reicht nicht aus. Die Teammitglieder müssen auch die Motivation haben, Anforderungen systematisch zu dokumentieren, indem sie einem Prozess folgen, der Richtlinien und Regeln beinhaltet. Ohne das Vorhandensein eines solchen Prozesses wird die Spezifikation wahrscheinlich viele Qualitätsmängel aufweisen. Ein Anforderungsdokumentationsprozess muss zur Struktur und Kultur eines Unternehmens passen, sollte aber zumindest folgende Aspekte berücksichtigen:
Einbindung der Stakeholder: Funktionale Anforderungen und Qualitätsanforderungen werden strukturiert durch Interaktionen mit den Stakeholdern ermittelt, d.h. allen wichtigen Personen, die Anforderungen liefern können, einschließlich Endnutzern, Teammitgliedern und anderen Beteiligten. Die dokumentierten Anforderungen und alle diesbezüglichen Fragen werden wiederum mit dem bzw. den Stakeholder(n) diskutiert, von dem/denen die Anforderung gestellt wurde, um Missverständnisse aufzudecken und auszuräumen [3].
Einsatz von Vorlagen für Anforderungen: Wenn es um die Qualität von Anforderungen geht, sind damit Aspekte wie Eindeutigkeit, Konsistenz, Klarheit der Struktur und Vollständigkeit gemeint. Im Vorfeld der Validierung ist die Anforderungsdokumentation die Phase, wo diese Qualitätseigenschaften entweder erreicht werden oder wo mangelhafte Qualität produziert wird. Die Einhaltung einer standardisierten Struktur oder die Verwendung einer Satzschablone für alle Arten von textbasierten Anforderungen kann viel zu gut formulierten Anforderungen beitragen.
Dokumentation von Artefakten: Anforderungen können als eine Basis dienen, zu der zusätzliche Informationen und Artefakte konstruktiv und pragmatisch hinzugefügt werden. Ein empfohlener Ansatz besteht darin, alle während des Prozesses entstandenen Artefakte zu sammeln und sie an die Anforderungen anzuhängen, um den Wissensaustausch zu erleichtern und feingranularere Informationen zur Verfügung zu haben, die als Diskussionsgrundlage dienen können. Dadurch wird die Anforderungsspezifikation zu einer noch besseren Quelle von Informationen über Entwurfsentscheidungen und die Nachverfolgbarkeit wird ebenfalls erhöht.
Ausarbeitung und Planung von Anforderungen: Ein effizienter Ansatz für die Anforderungsdokumentation besteht darin, Anforderungen systematisch zu verfeinern. Dadurch werden zwei Schlüsselaspekte von Anforderungen adressiert: die Tatsache, dass sie sich auf verschiedenen Granularitätsebenen befinden, und die Vorstellung, dass Anforderungen Änderungen unterliegen. In jeder Phase werden Anforderungen am besten nur bis zum jeweils erforderlichen Abstraktionsgrad ausgearbeitet, und zwar durch Kommunikation – vom Projektleiter, der gewährleistet, dass die Ziele vom Vorstand genehmigt sind, bis hinunter zum Teamleiter, der dem Team die Aufgaben vorlegt und Fragen mit den Entwicklern individuell bespricht.
Sperrung von Anforderungen für die Implementierung: Um einen präzisen Ansatz zu gewährleisten, sollte klar unterschieden werden zwischen Anforderungen, die sich noch im Fluss befinden, und solchen, die für eine bestimmte Iteration fest sind. Anforderungen sollten erst nach Abschluss der Konzeptualisierung für die Implementierung vorgesehen werden, und danach sollte die Implementierung durch einen eindeutigen und sorgfältig befolgten Änderungsmanagementprozess geregelt werden. Dies schützt das Entwicklungsteam auch vor Überlastung mit unqualifizierten Anforderungen [2].
Erstellung eines Glossars: Im Rahmen eines Entwicklungsprojekts ist ein Glossar ein wichtiges Instrument, um ein gemeinsames Verständnis sicherzustellen. Es ist eine Sammlung von Begriffsdefinitionen, die Aspekte einschließen kann wie z.B. kontextspezifische technische Begriffe, wirtschaftliche Begriffe und Jargon, Abkürzungen und Akronyme, Alltagsbegriffe, die in einem bestimmten Kontext eine spezifische Bedeutung haben, Synonyme (verschiedene Begriffe mit der gleichen Bedeutung, von denen nur einer verwendet werden sollte) und Homonyme (ähnliche Begriffe mit unterschiedlicher Bedeutung) [1].
Durchführung von Qualitätssicherung: Die Qualität sollte abgesichert werden. Dazu gehört die Validierung von Anforderungen vor der Implementierung und die nachträgliche Verifizierung besagter Implementierung. Die Validierung stellt sicher, dass die Anforderungen an der richtigen Stelle platziert sind, die notwendigen Attribute enthalten, versioniert sind, konsistent formuliert sind, die Qualitätskriterien an gut formulierte Anforderungen erfüllen und getestet werden können.
Das Fraunhofer IESE kann helfen
Wenn Sie Unterstützung bei Ihrem Anforderungsmanagement benötigen, dann können Ihnen unsere Experten für Requirements Engineering am Fraunhofer IESE helfen. Wir stützen uns unter anderem auf unsere mehr als zwanzigjährige Erfahrung mit RE, unsere bewährten RE Frameworks wie ReqMan und TORE sowie unsere umfangreichen Forschungsarbeiten zu RE, um Ihnen in folgenden Bereichen Hilfestellung zu bieten:
- Bewertung des Verbesserungspotenzials in Ihrer existierenden RE-Landschaft
- Auswahl und Einführung geeigneter Werkzeugunterstützung
- Überprüfung Ihrer Anforderungsspezifikationen und Beratung zur besseren Formulierung
- Entwurf und Einführung eines Prozesses zur Anforderungsdokumentation
Setzen Sie sich mit uns in Verbindung, um noch mehr darüber zu erfahren, was wir vom Fraunhofer IESE für Sie tun können!
Referenzen:
[1] Rupp, C. & Pohl, K. (2015). Requirements Engineering fundamentals: A study guide for the Certified Professional for Requirements Engineering exam – Foundation Level – IREB compliant (2nd Ed.). San Rafael, CA: Rocky Nook.
[2] 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).
[3] Schmitt, H., Rost, D., & Weitzel., B. (2015). PQ4Agile AP 2.2 Best Practices: Kundenanforderungen dokumentieren. Sulzbach, Germany: HK Business Solutions GmbH. Projekt „PQ4Agile — Produktqualität für Agile Softwareentwicklung“, BMBF-Förderkennzeichen 01IS13032. Available online: http://www.pqwiki.de/index.php/Kundenanforderungen_dokumentieren (last accessed 11 June 2019).