Klassisch vs. Agil: Anforderungsdokumentation

Anforderungsdokumentation ist ein wesentlicher Bestandteil des Projektmanagements und bildet die Grundlage für die Planung und Umsetzung eines Projekts. In diesem Artikel vergleichen wir klassische Methoden in der Anforderungsdokumentation mit dem agilen Pendant der Dokumentation von User Stories anhand eines Beispiels.

Die Wahl der passenden Methode für das jeweilige Projekt hängt von verschiedenen Faktoren ab, einschließlich der Art des Projekts und der Unternehmenskultur. Als Projektmanager:in oder Produktverantwortliche solltest Du idealerweise beide Ansätze kennen und verstehen, um die bestmögliche Entscheidung treffen zu können.

Klassische Anforderungsdokumentation

Im klassischen Projektmanagement wird eine Anforderungsdokumentation oft sehr detailliert und umfangreich erstellt. Ein typisches Anforderungsdokument (häufig etwa Lastenheft genannt) enthält alle wesentlichen Informationen über das Projekt, einschließlich funktionaler und nicht-funktionaler Anforderungen, Geschäftsregeln, Systemanforderungen und oft auch technische Spezifikationen.

Das Lastenheft wird vom Auftraggeber formuliert und dient im ersten Schritt bereits zur Einholung von Angeboten. Auch die Bezeichnung Leistungsverzeichnis ist im Deutschen geläufig. 

Der Auftragnehmer erstellt wiederum nach Erhalt des Lastenhefts ein Pflichtenheft. Dieses setzt die gewünschten Ergebnisse (Lasten) in Aufgaben (Pflichten) um. Wie ausführlich dieses Pflichtenheft ist, hängt vom jeweiligen Projekt ab. Es kann lediglich den Liefertermin und den Preis enthalten – oder bereits eine vollständige Projektplanung. 

Beide Dokumente werden bei Zustandekommen einer Zusammenarbeit Bestandteil des Vertrages. 

Merkmale der klassischen Anforderungsdokumentation

• Vollständigkeit und Detailtiefe: Das Dokument strebt danach, alle Anforderungen bis ins Detail zu erfassen, um Missverständnisse und Änderungen während des Projekts zu minimieren.
• Formaler Prozess: Die Erstellung des Anforderungsdokuments folgt einem formalen Prozess, der oft mehrere Iterationen von Überprüfung und Genehmigung durchläuft.
• Feste Basis: Einmal abgeschlossen, dient das Dokument als feste Grundlage für die weitere Planung und Umsetzung des Projekts.

Beispiel: Entwicklung einer neuen Funktion für eine mobile App

Angenommen, wir entwickeln eine neue Funktion für eine mobile App, die eine Benutzerregistrierung, das Erstellen eines Benutzerprofils und die Integration einer Push-Benachrichtigung umfasst. Ein klassisches Anforderungsdokument könnte folgendermaßen aussehen:

• Zielsetzung: Die neue Funktion soll die Benutzerregistrierung, das Erstellen von Benutzerprofilen und die Integration von Push-Benachrichtigungen ermöglichen, um die Benutzerinteraktion und -bindung zu verbessern.
• Funktionale Anforderungen:
  1. Benutzerregistrierung: Benutzer müssen sich registrieren können, um Zugang zur App zu erhalten. Die Registrierung erfordert die Eingabe von E-Mail, Passwort und Bestätigung.
  2. Benutzerprofil: Benutzer müssen ein Profil erstellen und verwalten können, einschließlich der Eingabe von Namen, Geburtsdatum und Profilbild.
  3. Push-Benachrichtigungen: Die App muss in der Lage sein, Push-Benachrichtigungen an Benutzer zu senden, um sie über wichtige Ereignisse zu informieren.
• Nicht-funktionale Anforderungen:
  1. Sicherheit: Die Registrierung und Profilerstellung müssen sicher und DSGVO-konform sein.
  2. Performance: Die App soll in der Lage sein, Benachrichtigungen innerhalb von 2 Sekunden nach dem Ereignis zu senden.
  3. Benutzerfreundlichkeit: Die Benutzeroberfläche muss intuitiv und leicht zu bedienen sein.
• Technische Anforderungen:
  1. Kompatibilität: Die Funktion muss auf iOS und Android laufen.
  2. Wartbarkeit: Der Code muss leicht wartbar und erweiterbar sein.

Vorteile der klassischen Anforderungsdokumentation

• Klarheit und Präzision: Durch die detaillierte Dokumentation werden Anforderungen klar definiert und Missverständnisse reduziert.
• Stabile Grundlage: Bietet eine stabile Grundlage für die Planung und Umsetzung, wodurch das Projekt weniger anfällig für Änderungen wird.
• Nachvollziehbarkeit: Jede Anforderung ist dokumentiert und kann bei Bedarf nachverfolgt werden.

Herausforderungen der klassischen Anforderungsdokumentation

• Zeitaufwändig: Die Erstellung eines umfassenden Anforderungsdokuments kann sehr zeitaufwändig sein.
• Rigidität: Änderungen sind oft schwierig und teuer, da sie den gesamten Plan beeinflussen können.
• Überkomplexität: Bei großen Projekten kann die Menge an Details überwältigend sein und die Übersichtlichkeit beeinträchtigen.

Agile Ansätze: User Storys

Bei den agilen Methoden werden Anforderungen oft in Form von sogenannten User Storys dokumentiert. Ursprünglich eine Idee aus dem agilen Framework “Extreme Programming” (XP), haben auch nach Scrum oder anderen agilen Ansätzen arbeitende Teams das Konzept von User Storys heute in ihren Alltag meist fest integriert. Doch was genau sind User Storys? Es handelt sich dabei zunächst einmal um kurze, einfache und eingängige Beschreibungen einer Funktionalität aus der Sicht des Endbenutzers oder Kunden, die in das Product Backlog des Teams aufgenommen werden können.

Merkmale von User Storys

• Einfach und prägnant: Jede User Story beschreibt eine Funktionalität in einer klaren und einfachen Sprache – meist tatsächlich wie eine Art sehr kurze Geschichte, in nur einem Satz zusammengefasst, s. Beispiele unten.
• Fokussierung auf Nutzer:innen: User Storys sollten den Mehrwert für Endnutzer:innen in den Vordergrund stellen.
• Flexible und iterative Entwicklung: Storys können in der agilen Arbeit mit einem Backlog jederzeit hinzugefügt, geändert oder entfernt werden, um sich ändernden Bedürfnissen, Erkenntnissen oder Gegebenheiten gerecht zu werden.

Beispiel: Entwicklung einer neuen Funktion für eine mobile App

Nehmen wir das gleiche Beispiel wie oben, um den Vergleich zu verdeutlichen. User Storys könnten dann so aussehen:

1. User Story 1: Benutzerregistrierung
   • Beschreibung: Als Benutzer:in möchte ich mich registrieren können, um auf die App zugreifen zu können.
2. User Story 2: Benutzerprofil erstellen
   • Beschreibung: Als Benutzer:in möchte ich ein Profil erstellen können, um meine Informationen zu speichern und zu verwalten.
3. User Story 3: Push-Benachrichtigung integrieren
   • Beschreibung: Als Benutzer:in möchte ich Push-Benachrichtigungen erhalten, um über wichtige Ereignisse informiert zu werden.

Vorteile von User Storys

• Flexibilität: User Storys ermöglichen eine flexible Anpassung von Anforderungen während des Projekts.
• Nutzerorientierung: Der Fokus auf die Perspektive von Endnutzer:innen stellt sicher, dass die entwickelten Funktionen tatsächlich einen Mehrwert bieten.
• Team-Beteiligung: Die Erstellung und Priorisierung von User Storys erfolgt im Team, was die Akzeptanz und das Verständnis fördert.

Herausforderungen der User Stories

• Abstraktheit: User Storys können für Stakeholder schwer verständlich und nachvollziehbar sein, da sie weniger detailliert sind. Sie sollten immer als Ausgangsbasis für weitere Detaildiskussionen gesehen werden, nie als dokumentiertes Ergebnis dieser. Jede:r im Team sollte darüber ein Bewusstsein haben.
• Erfahrung: Die Qualität und Genauigkeit der User Storys hängt stark von der Erfahrung des Teams ab.
• Kontinuierliche Pflege: User Storys müssen kontinuierlich gepflegt und angepasst werden, was zusätzlichen Aufwand erfordert.

Fazit: Wann sollte ich nun welche Methode wählen?

Die Entscheidung zwischen eher klassischer Anforderungsdokumentation und dem Einsatz eines Backlogs mit User Storys (und ggfs. anderen Einträgen) darin hängt unter anderem von der Art eines Vorhabens, der Unternehmenskultur und den spezifischen Anforderungen ab. Klassische Anforderungsdokumentation eignet sich besser für vorherplanbarere Projekte mit klar definierten Zielen und Anforderungen, während User Storys ideal für dynamische, sich schnell ändernde Projekte sind, bei denen Flexibilität und Nutzerorientierung im Vordergrund stehen.