L4 - Dokumentation von Anforderungen

Eine Menge dokumentierter Anforderungen, auf deren Grundlage alle weiteren Aktivitäten im Softwareprozess erfolgen.

Um eine zielgruppengerechte Dokumentation sicherzustellen und passende Dokumentationsformen aus verschiedenen Optionen zu wählen.

Typische Elemente können sein: Anforderungsbeschreibungen, Prioritäten, Akzeptanzkriterien, Anforderungsquellen und spezifische Attribute wie Verantwortlichkeiten und Status.

Das Ziel ist die Sicherung des aktuellen Erkenntnisstands, um sicherzustellen, dass das gewonnene Wissen für alle Projektbeteiligten einsehbar und nicht nur in den Köpfen der beteiligten Personen vorhanden ist.

Dokumentierte Anforderungen unterstützen die Kommunikation, da sie eine zentrale Bedeutung im Softwareprojekt haben und von ihnen alle folgenden Aktivitäten direkt oder indirekt abhängen. Zudem haben sie rechtliche Relevanz bei Vertragsabschlüssen und ermöglichen es neuen Projektmitgliedern, sich schnell in das Thema einzuarbeiten.

1. Bestimmung von Zweck und Zielgruppe, 2. Auswahl der Detailebene und Dokumentationsform, 3. Dokumentation der Anforderungen, 4. Prüfung, ob die Dokumentation noch zu Zweck und Zielgruppe passt.

Da sich die Menge der am Projekt arbeitenden Personen über den Lebenszyklus eines Softwaresystems ändert, müssen neue Projektmitglieder schnell und verbindlich in das Thema einarbeiten können. Die Anforderungen gewährleisten eine durchgängige Orientierung.

Es beinhaltet die Festlegung des Zwecks und der Zielgruppe für die Dokumentation, um sicherzustellen, dass die Dokumentation auf den Bedürfnissen und dem Wissen der Zielgruppe basiert und entsprechend angepasst werden kann.

Typische Ziele sind die Unterstützung der Kommunikation zwischen Stakeholdern, das Bereitstellen von Wissensspeichern für Beschlüsse und Definitionen auch nach der Inbetriebnahme sowie die Schaffung von Verbindlichkeit bei Missverständnissen oder Unklarheiten.

Die Bestimmung von Zweck und Zielgruppe ermöglicht eine zielgerichtete Ausrichtung der Dokumentation, sowohl inhaltlich als auch in Bezug auf die Dokumentationsform, entsprechend den tatsächlichen Erfordernissen und den Bedürfnissen der jeweiligen Zielgruppe.

Beispiele sind Diskussionen mit dem Fachbereich über funktionale Anforderungen, die Erstellung von Entscheidungsvorlagen für das Management zur Budgetfreigabe und die Abstimmung von Umsetzungsdauer und -methoden mit Softwarearchitekten und Entwicklern.

Mögliche Risiken sind Unverständnis bei Stakeholdern aufgrund der gewählten Dokumentationsform, das Übersehen wichtiger Anforderungen in umfangreichen Dokumenten und der Verlust von Übersicht und Abhängigkeiten bei ausschließlicher Dokumentation als Sammlung von User Stories.

Es ist wichtig zu entscheiden, ob ein Überblick genügt oder ob eine detaillierte Darstellung benötigt wird, basierend auf den Bedürfnissen der Stakeholder und dem Einsatzzweck der Dokumentation, beispielsweise Kommunikation mit dem Topmanagement oder Aufwandsschätzung.

Typische Formen sind Softwaremodelle, Prototypen, Skizzen, Tabellen und Text, die je nach Bedarf und Verständnis der Zielgruppe ausgewählt werden.

Nach diesen Bestimmungen folgt die eigentliche Dokumentation der Anforderungen in einer geeigneten Form für den definierten Zweck und die Zielgruppe.

Es ist wichtig zu überprüfen, ob die Dokumentation immer noch dem ursprünglichen Zweck und der Zielgruppe angemessen ist, da sich während des Prozesses Änderungen ergeben können oder der Fokus verloren gehen kann.

Änderungen in der Zielgruppe oder im Zweck aufgrund von Entwicklungen im Projekt können dazu führen, dass die Dokumentation an die neuen Bedingungen angepasst werden muss.

Typische Elemente sind die Produkt- bzw. Projektvision, die Überblicksebene, detaillierte Anforderungen und ein Glossar, die je nach Einsatz variieren können, aber bei der Strukturierung von Anforderungsdokumenten berücksichtigt werden sollten.

Die Struktur hängt von der Art des Systems, der Organisation des Softwareprojekts und den unternehmensspezifischen Vorgaben ab, wodurch es keine universelle Vorlage für Anforderungsdokumentationen gibt.

Eine vorgegebene Struktur erleichtert die Vergleichbarkeit von Anforderungen über verschiedene Projekte hinweg, unterstützt die Einarbeitung in die Dokumentation und dient als Checkliste, um sicherzustellen, dass alle erforderlichen Inhalte berücksichtigt werden.

Vorgegebene Templates werden manchmal nicht genutzt, da sie oft nicht flexibel genug sind und zu sehr auf Vollständigkeit statt auf eine praktische Anwendung im Projekt ausgerichtet sind. Daher sollten Strukturanforderungen kontinuierlich an den tatsächlichen Bedarf angepasst werden.

Die Projektvision beschreibt kurz (ca. 1.600 Zeichen) das Ziel und den Zweck des Projekts, die Motivation dahinter und legt die Ebene der in diesem Dokument beschriebenen Anforderungen fest.

Die Projektvision fungiert als Anker und Orientierungspunkt für Workshops und Besprechungen mit den Stakeholdern, um ein gemeinsames Verständnis und eine klare Ausrichtung zu ermöglichen.

Die Projektvision dient nicht nur als Einführung und Überleitung zu den Dokumentinhalten, sondern auch als Maßstab für die Prüfung der Übereinstimmung von Inhalten und Form mit Zweck und Zielgruppe des Dokuments.

Im ersten Workshop des Projekts sollte die Projektvision als Text mit etwa einer halben DIN-A4-Seite (ca. 1.600 Zeichen) formuliert und mit allen Beteiligten abgestimmt werden.

Die Überblicksebene bietet eine technische und fachliche Einordnung der Anwendung(en) und umfasst eine Beschreibung der fachlichen Prozesslandschaft, der Einbettung in die IT-Landschaft der Organisation, der wichtigsten Systemfunktionen, technischen Schnittstellen zu anderen Systemen und der beteiligten Rollen.

Die Einordnung in die IT-Landschaft ermöglicht einen Vergleich zu anderen Systemen, während die Beschreibung der Systemfunktionen den Lesern einen Überblick über die Funktionalitäten verschafft.

Typischerweise werden die fachliche Prozesslandschaft, die IT-Landschaft der Organisation, Hauptfunktionen der Systeme, technische Schnittstellen zu anderen Systemen und die Rollen, die mit den Systemen arbeiten, dokumentiert.

Es ist wichtig, systemübergreifende Anforderungen zu dokumentieren, wenn mehrere Systeme verändert werden, um technische Abhängigkeiten rechtzeitig zu kennen und Integrationsschritte frühzeitig zu planen.

Der Bereich der detaillierten Anforderungen beinhaltet die ausführliche Dokumentation jeder zuvor kurz beschriebenen Systemfunktion, einschließlich aller Teilfunktionen, funktionalen Anforderungen, Qualitätsanforderungen und Randbedingungen, die für die Implementierung relevant sind.

Die Teilfunktionen werden innerhalb des Abschnitts der Systemfunktion detailliert beschrieben, inklusive aller relevanten Informationen für das Entwicklungsteam, wie funktionalen Anforderungen, Qualitätsanforderungen und Randbedingungen.

Anforderungen können in Form von Texten, Aufzählungen, Tabellen, fachlichen Modellen, Referenzen auf externe Dokumente und Screenshots von Prototypen dokumentiert werden, um eine umfassende Beschreibung zu gewährleisten.

Ein übergreifendes fachliches Objektmodell, oft mit UML-Klassendiagrammen dargestellt, ermöglicht die Beschreibung und Dokumentation der fachlichen Zusammenhänge und Eigenschaften von Geschäftsobjekten, ergänzend zur Dokumentation einzelner Systemfunktionen.

Das Glossar sammelt und erläutert Fachbegriffe sowohl aus dem Fachbereich als auch aus der IT, insbesondere fach- und organisationsspezifische sowie technische Abkürzungen und projektspezifische Begriffe, um ein einheitliches Verständnis sicherzustellen.

Das Glossar sollte Fachbegriffe von Fach- und IT-Seite sowie projektspezifische Begriffe oder solche mit abweichender Bedeutung von ihrer allgemein bekannten Definition enthalten.

Das Glossar hilft, Missverständnisse durch uneinheitliches Verständnis von Begriffen zu vermeiden und schafft eine klare Kommunikationsgrundlage, indem es eine einheitliche Definition und Erklärung der Begriffe bietet.

Typische Dokumentationsformen sind Modelle, Prototypen, Skizzen, Tabellen und Text, die die Kommunikation und das Verständnis zwischen den beteiligten Stakeholdern erleichtern.

Text und Tabellen sind einfach anzuwenden, erfordern keinen zusätzlichen Lernaufwand und können vielseitig für die Beschreibung verschiedener Anforderungen genutzt werden.

Bei der ausschließlichen Verwendung von Text besteht ein hoher Interpretationsspielraum und es können Ungenauigkeiten in der Formulierung auftreten, wie die Vernachlässigung von Alternativszenarien oder negativen Fällen.

Andere Dokumentationsformen haben sich etabliert, da die ausschließliche Verwendung von Text in der Praxis Nachteile wie hohe Interpretationsspielräume und Ungenauigkeiten mit sich bringt.

Skizzen und einfache Grafiken dienen dazu, Anforderungen präziser und anschaulicher als mit reinem Text zu dokumentieren, insbesondere in frühen Phasen der Anforderungsermittlung, um fachliche Zusammenhänge darzustellen.

Der Vorteil liegt in der einfachen und schnellen Erstellung, auch direkt in Workshops mit Stakeholdern, um fachliche Zusammenhänge visuell zu veranschaulichen.

Ein Nachteil liegt im großen Interpretationsspielraum, da Symbole, Formen und Farben oft nur den direkt Beteiligten bekannt sind. Daher sollten sie durch Legenden oder ausführliche Beschreibungen ergänzt werden.

Skizzen sind in frühen Phasen nützlich, da sie fachliche Zusammenhänge herausstellen können, bevor technische Details festgelegt sind.

Grafische Modelle sind Grafiken mit spezifischen Notationselementen wie BPMN oder UML, die Anforderungen zu Struktur und Verhalten von Systemen darstellen, wodurch der Interpretationsspielraum reduziert wird.

Modelle haben einen geringeren Interpretationsspielraum, da die Notationselemente eine klare Bedeutung haben, und ermöglichen eine kompaktere Darstellung von Informationen, die vom Leser schneller erfasst werden können.

Neben grafischen Modellen gibt es strukturierte Textmodelle wie XML, die beispielsweise Datenstrukturen an technischen Systemschnittstellen dokumentieren können.

Ein Nachteil von Modellen ist der erforderliche Schulungsaufwand, da das Wissen über die Notationselemente und deren Verwendung benötigt wird. Zudem sind Modelle nicht universell einsetzbar und konzentrieren sich oft auf spezifische Aspekte eines Systems, wodurch verschiedene Diagrammtypen für unterschiedliche Gesichtspunkte erforderlich sind.

GUI-Prototypen ermöglichen die präzise Festlegung von Größe, Position, Farbe, Beschriftung von Elementen der Nutzeroberfläche und dokumentieren Erscheinung sowie Inhalt von Fehlermeldungen und Dialogmasken in Abhängigkeit von der Nutzerinteraktion.

Sie können von einfachen Skizzen über Wireframes bis hin zu vollständigen Mock-ups verwendet werden, um Benutzerschnittstellen darzustellen und Anforderungen zu dokumentieren.

Eine Kombination aus Modellen, ausformuliertem Text und GUI-Prototypen gleicht die individuellen Nachteile der einzelnen Dokumentationsformen aus und unterstützt das Verständnis sowie die Einordnung der dokumentierten Anforderungen.

Bei der Kombination von Text, Modellen und GUI-Prototypen ist darauf zu achten, dass alle Dokumentationsformen den gleichen Erkenntnisstand wiedergeben und keine Inkonsistenzen in der Dokumentation auftreten.