Software-Anforderungen richtig dokumentieren

Wenn Abteilungen eines Unternehmens zusammenarbeiten, die normalerweise wenig miteinander zu tun haben, kann es schnell zur Herausforderung werden, alle Beteiligten auf dem gleichen Stand zu halten. Dokumente zur Spezifikation von Softwareanforderungen helfen Projektmanagern, Produktmanagern und Geschäftsanalysten dabei, übergeordnete Konzepte in konkrete Aktionspunkte aufzuteilen, an denen sich jedes Teammitglied während des Entwicklungsprozesses orientieren kann.

Eine Spezifikation von Softwareanforderungen (englisch: Software Requirements Specification, kurz SRS) fasst alle Anforderungen, Erwartungen, Designvorgaben und Standards für ein geplantes Softwareprojekt zusammen. Es enthält:

die übergeordneten Geschäftsanforderungen, die das Projektziel definieren,
die Anforderungen und Bedürfnisse der Endnutzer sowie
die technische Funktionalität des Produkts.

Kurz gesagt beschreibt ein SRS-Dokument detailliert, wie ein Softwareprodukt funktionieren soll und wie das Entwicklungsteam es umsetzen soll. Es zeigt außerdem auf, welche Anforderungen priorisiert werden sollten, damit die Entwicklung möglichst effizient und pragmatisch verläuft.

Beispiel: Wer eine neue App entwickeln möchte, hat oft eine klare Vorstellung davon, wie sie aussehen und funktionieren soll – kann diese Vision aber nicht einfach mündlich an das Entwicklungsteam übergeben und erwarten, dass alle Erwartungen sofort verstanden und umgesetzt werden. Genau hier setzt das SRS-Dokument an.

Ohne klare Anweisungen an das Entwicklungsteam besteht die Gefahr, dass die Umsetzung eines neuen Produkts deutlich mehr Zeit und Kosten verursacht als geplant. Ein SRS-Dokument hilft dabei, die Projektvision schriftlich festzuhalten und die Anforderungen präzise zu formulieren. Es dient als zentrale Informationsquelle für alle beteiligten Teams – vom Marketing bis zur Wartung.

Da sich Softwareanforderungen im Laufe eines Projekts häufig weiterentwickeln, funktioniert ein SRS-Dokument als lebendes Dokument: Alle Änderungen werden darin erfasst, sodass sämtliche Beteiligten jederzeit den aktuellen Stand einsehen und mögliche Unklarheiten bezüglich der Produktanforderungen vermieden werden können.

Ein grundlegendes SRS-Dokument gliedert sich in vier Hauptbereiche:

Die Einleitung bietet einen Gesamtüberblick über das Projekt aus der Vogelperspektive. Sie beschreibt Zweck, Zielgruppe und geplante Nutzung des Produkts. Folgende Elemente sollten enthalten sein:

Produktumfang: Bezug zu den allgemeinen Geschäftszielen; Nutzen, Zielsetzungen und angestrebte Ziele des Produkts.
Produktwert: Warum ist das Produkt wichtig? Welches Problem löst es für die Zielgruppe?
Zielgruppe: Beschreibung der idealen Nutzerinnen und Nutzer, die das Erscheinungsbild und die Vermarktung des Produkts bestimmt.
Verwendungszweck: Auflistung aller verfügbaren Funktionen sowie möglicher Anwendungsszenarien je nach Aufgabenbereich.
Definitionen und Abkürzungen: Erklärung der im Dokument verwendeten Fachbegriffe und Abkürzungen, damit alle Beteiligten dasselbe Verständnis haben.
Inhaltsverzeichnis: Für umfangreiche SRS-Dokumente unverzichtbar, damit Lesende schnell die gesuchten Abschnitte finden.

Die funktionalen Anforderungen beschreiben, welche Systemeigenschaften und -funktionen notwendig sind, damit das System wie vorgesehen arbeitet. Häufige funktionale Anforderungen umfassen unter anderem:

Wenn/Dann-Verhalten
Datenverarbeitungslogik
Systemabläufe
Transaktionsabwicklung
Administrative Funktionen
Regulierungs- und Compliance-Anforderungen
Leistungsanforderungen
Ausführbare Aktionen pro Bildschirm

Je mehr Details in die Anforderungsspezifikation einfließen, desto weniger Aufwand entsteht später bei der Fehlersuche.

Externe Schnittstellenanforderungen stellen sicher, dass das System korrekt mit externen Komponenten kommuniziert. Dazu gehören:

Benutzeroberflächen: Darstellung von Inhalten, Navigation und Nutzerunterstützung.
Hardware-Schnittstellen: Unterstützte Gerätetypen und Kommunikationsprotokolle.
Software-Schnittstellen: Verbindungen zu Datenbanken, Bibliotheken und Betriebssystemen.
Kommunikationsschnittstellen: Anforderungen an Kommunikationsfunktionen wie E-Mails oder eingebettete Formulare.

Bei eingebetteten Systemen sollten zudem Bildschirmlayouts, Tastenfunktionen und Abhängigkeiten von anderen Systemen berücksichtigt werden.

Während funktionale Anforderungen beschreiben, was ein System tun soll, legen nicht-funktionale Anforderungen fest, wie das System diese Funktionen umsetzen soll. Typische nicht-funktionale Anforderungen betreffen:

Sicherheit: Schutz sensibler Nutzerdaten.
Kapazität: Aktueller und künftiger Speicherbedarf sowie Skalierungsstrategie.
Kompatibilität: Mindestanforderungen an Hardware, Betriebssysteme und deren Versionen.
Zuverlässigkeit und Verfügbarkeit: Erwartete Nutzungshäufigkeit und tolerierbare Ausfallzeiten.
Skalierbarkeit: Maximale Arbeitslast, bei der das System noch die erwartete Leistung erbringt.
Wartungsfähigkeit: Einsatz von Continuous Integration für schnelle Updates und Fehlerbehebungen.
Benutzerfreundlichkeit: Wie intuitiv das Produkt zu bedienen sein soll.

Weitere gängige nicht-funktionale Anforderungen umfassen Leistungs-, Regulierungs- und Umweltanforderungen.

Diagramme, Schemata und Modelle helfen Teammitgliedern, Prozesse besser zu verstehen – besonders wenn es darum geht, die Hauptfunktionen und die Bedienbarkeit der Software zu veranschaulichen. Eine nützliche Technik ist das Mind Mapping: Damit lassen sich Ideen, Merkmale und Szenarien strukturieren und miteinander in Verbindung bringen, bevor die Details im SRS-Dokument ausgearbeitet werden.

Entwicklungsteams brauchen eindeutige Anweisungen. Folgende Formulierungsfehler sollten vermieden werden:

Vage Begriffe wie „grundsätzlich„ oder „ungefähr“
Schrägstriche (/) bei Begriffen, die als „und„ oder „oder“ interpretiert werden könnten
Komplizierte Grenzwertangaben
Doppelte oder dreifache Verneinungen

Eine formelle Prüfung durch Kolleginnen und Kollegen ist empfehlenswert, um Unklarheiten frühzeitig zu erkennen und zu beseitigen.

Marktforschungsergebnisse und Nutzerinterviews sollten in das SRS-Dokument einfließen, um ein klares Bild der Anforderungen, Erwartungen und Bedürfnisse der Endnutzerinnen und -nutzer zu zeichnen. Alle möglichen Nutzungsszenarien und Sonderfälle sollten berücksichtigt werden – denn das Entwicklungsteam setzt genau das um, was im Dokument steht.

Ein SRS-Dokument ist ein lebendes Dokument: Bei jeder Iteration können neue Funktionen und Änderungen hinzukommen. Anforderungen sollten daher flexibel formuliert werden, und alle Änderungen am Dokument sind sorgfältig zu protokollieren. Beteiligte sollten jede Anforderung bis zu ihrer ursprünglichen Version zurückverfolgen und nachvollziehen können, wer wann welche Änderung aus welchem Grund vorgenommen hat.

Das Verfassen eines Dokuments zur Spezifikation von Softwareanforderungen ist anspruchsvoll – aber weitaus weniger aufwändig als eine langwierige Fehlersuche oder endlose Diskussionen zwischen Teammitgliedern im Nachhinein. Die Arbeit, die in ein umfassendes SRS-Dokument investiert wird, zahlt sich durch ein überzeugendes Endprodukt aus, auf das alle Beteiligten stolz sein können.