Anforderungsdokumentation

Der Bauplan für erfolgreiche Software

Stell dir vor, du möchtest ein komplexes LEGO-Modell bauen, aber die Anleitung fehlt oder ist voller Fehler. Das Ergebnis wäre wahrscheinlich nicht das, was du dir vorgestellt hast, oder? In der Softwareentwicklung ist die Anforderungsdokumentation genau diese unverzichtbare Anleitung. Sie ist der "Bauplan", der detailliert beschreibt, was die zu entwickelnde Software leisten soll, wie sie sich verhalten soll und welche Ziele sie für die Benutzer:innen und das Unternehmen erfüllen muss. Ohne eine klare und verständliche Anforderungsdokumentation riskierst du, dass

• das entwickelte Produkt nicht den tatsächlichen Bedürfnissen der Kundschaft oder der Anwendenden entspricht,
• wichtige Funktionen vergessen oder falsch umgesetzt werden,
• das Projektbudget und der Zeitplan überschritten werden, weil ständig nachgebessert werden muss,
• Missverständnisse im Team und mit den Stakeholdern (Auftraggebende, Anwendende etc.) entstehen.

Die Anforderungsdokumentation ist also weit mehr als nur ein Stück Papier. Sie ist ein zentrales Kommunikationsmittel, das sicherstellt, dass alle Beteiligten – vom Entwicklungsteam über das Management bis hin zu den Endanwendenden – ein gemeinsames und eindeutiges Verständnis davon haben, was entwickelt werden soll. Sie dient als Vertragsgrundlage zwischen Auftraggebenden und Auftragnehmenden und legt verbindlich fest, welche Leistungen zu erbringen sind. Darüber hinaus bildet sie die Basis für das Design, die Implementierung und vor allem für das Testen der Software. Nur wenn klar ist, was die Software tun soll, kann überprüft werden, ob sie es auch korrekt tut. Schließlich ermöglicht eine gute Dokumentation die Nachvollziehbarkeit von Entscheidungen und dient als wichtiger Wissensspeicher für das Projekt, auch für zukünftige Wartungsarbeiten oder Weiterentwicklungen.

Qualitätskriterien für Anforderungen: Damit der Bauplan stimmt

Eine hochwertige Anforderungsdokumentation ist die Grundlage für ein erfolgreiches Softwareprojekt. Damit Anforderungen ihren Zweck erfüllen, sollten sie bestimmte Qualitätskriterien erfüllen:

• Eindeutigkeit: Jede Anforderung sollte nur auf eine Weise interpretierbar sein. Vage Formulierungen wie "Die Software soll benutzerfreundlich sein" sind problematisch. Besser: "Die Software muss es einer neuen benutzenden Person ermöglichen, Aufgabe X nach einer maximal 10-minütigen Einführung ohne weitere Hilfe durchzuführen."
• Vollständigkeit: Alle für die Entwicklung relevanten Aspekte müssen beschrieben sein. Was passiert, wenn eine Eingabe fehlt? Welche Fehlermeldungen gibt es?
• Konsistenz: Anforderungen dürfen sich nicht widersprechen. Wenn eine Anforderung besagt "Das System soll nur auf Deutsch verfügbar sein" und eine andere "Das System muss Englisch unterstützen", liegt ein Widerspruch vor.
• Korrektheit: Die dokumentierten Anforderungen müssen die tatsächlichen Bedürfnisse der Stakeholder und die fachlichen Gegebenheiten korrekt widerspiegeln.
• Testbarkeit (Überprüfbarkeit): Für jede Anforderung muss es möglich sein, objektiv zu überprüfen, ob sie erfüllt wurde. "Das System soll schnell sein" ist schwer testbar. "Die Suchfunktion soll Ergebnisse für 95% der Anfragen in unter 2 Sekunden liefern" ist testbar.
• Priorisierung: Nicht alle Anforderungen sind gleich wichtig. Eine Priorisierung (z.B. Muss, Soll, Kann, Wird-nicht) hilft, Entscheidungen bei begrenzten Ressourcen zu treffen. Welche Funktion ist für den ersten Release unverzichtbar?
• Nachverfolgbarkeit (Traceability): Es sollte nachvollziehbar sein, woher eine Anforderung stammt (z.B. von welchem Stakeholder, aus welchem Geschäftsprozess), wo sie im Design berücksichtigt und im Code umgesetzt wurde und durch welche Testfälle sie abgedeckt wird. Dies ist wichtig für das Änderungsmanagement und die Auswirkungsanalyse.

Formale Anforderungsspezifikationen: Das Detail im Fokus

Formale Anforderungsspezifikationen, wie das Lastenheft (Was wünschen sich die Auftraggebenden?) und das Pflichtenheft (Wie setzen die Auftragnehmenden das um?), sind sehr detaillierte und strukturierte Dokumente. Sie beschreiben umfassend alle funktionalen und nicht-funktionalen Anforderungen an ein System.

• Struktur und Detailtiefe: Oft nach Standards wie IEEE 830 aufgebaut, sehr detailliert, präzise formuliert.
• Anwendungsbereiche: Vor allem in klassischen, plangetriebenen Entwicklungsprojekten (z.B. Wasserfallmodell), bei komplexen Systemen oder in Bereichen mit hohen regulatorischen Anforderungen (z.B. Software für medizinische Geräte, Flugsicherungssysteme).
• Eignung: Gut für Projekte, bei denen Anforderungen zu Beginn relativ stabil sind und eine hohe Nachvollziehbarkeit und Verbindlichkeit gefordert ist.
• Beispiel: Ein Lastenheft für eine neue Buchhaltungssoftware könnte detailliert alle gesetzlichen Anforderungen, Schnittstellen zu anderen Systemen und spezifische Berechnungslogiken für Steuern und Abschreibungen festlegen.

User Stories: Aus der Sicht der Anwendenden

User Stories sind eine schlanke und agile Methode, um Anforderungen aus der Perspektive der Endanwendenden zu erfassen. Sie sind kurz, prägnant und fokussieren auf den Nutzen.

• Struktur und Detailtiefe: Typisches Format: "Als <Rolle> möchte ich <Ziel/Funktion>, um <Nutzen/Mehrwert>." Weniger detailliert als formale Spezifikationen, der Fokus liegt auf dem "Was" und "Warum".
• Anwendungsbereiche: Hauptsächlich in agilen Entwicklungsmethoden wie Scrum oder Kanban.
• Eignung: Sehr gut für Projekte mit sich ändernden Anforderungen, da sie flexibel sind und die Kommunikation im Team fördern. Sie helfen, den Fokus auf den Wert für die Anwendenden zu legen.
• Beispiel: "Als Online-Shop-Kund:in möchte ich Produkte in meinen Warenkorb legen können, um sie später gesammelt zu kaufen." oder "Als administrierende Person möchte ich neue Benutzerkonten anlegen können, um neuen Mitarbeitenden Zugriff zu gewähren."

Use Cases (Anwendungsfälle): Interaktionen im Detail

Use Cases beschreiben, wie eine benutzende Person (oder ein anderes System) mit der zu entwickelnden Software interagiert, um ein bestimmtes, fachliches Ziel zu erreichen. Sie sind detaillierter als User Stories.

• Struktur und Detailtiefe: Beschreiben typischerweise Akteure, Vorbedingungen, einen Standardablauf (Sonnenschein-Szenario) und alternative Abläufe oder Fehlerfälle. Können textuell oder grafisch (z.B. mit UML Use-Case-Diagrammen) dargestellt werden.
• Anwendungsbereiche: Sowohl in klassischen als auch in agilen Projekten einsetzbar, um komplexe Interaktionen und Prozessabläufe zu verstehen und zu dokumentieren.
• Eignung: Gut, um das Verhalten des Systems aus Benutzersicht zu spezifizieren und sicherzustellen, dass alle relevanten Szenarien bedacht werden. Sie helfen, funktionale Anforderungen zu konkretisieren.
• Beispiel: Ein Use Case "Kund:in bestellt Produkt" würde alle Schritte von der Produktauswahl über die Eingabe der Lieferadresse und Zahlungsdaten bis zur Bestellbestätigung beschreiben, inklusive möglicher Fehlerfälle wie "Zahlung fehlgeschlagen" oder "Produkt nicht mehr auf Lager".