Direkt zum Inhalt

Brauche ich ein Pflichtenheft? Anforderungen in agilen Projekten richtig formulieren.

Brauche ich ein Pflichtenheft? Anforderungen in agilen Projekten richtig formulieren.
04.04.2018 - 15:00 von Manuel Pistner

"Zeig mir deine Projektanforderungen und ich sage dir, ob dein Projekt erfolgreich sein wird."

Tatsächlich bilden die Anforderungen sowohl in klassischen Wasserfallprojekten als auch in agilen Projekten die Grundlage für planbaren Projekterfolg. Anforderungen haben in Web- und Mobile-Projekten 3 wesentliche Aufgaben:

  • Sie steuern die Erwartungshaltung der Stakeholder.
  • Sie machen Fortschritt messbar.
  • Sie vermitteln dem Entwicklerteam das, was umgesetzt werden muss, damit das Projekt erfolgreich wird.

Sie geben also Sicherheit über das Ergebnis und die aufzuwendenden Ressourcen, um das gewünschte Ergebnis herzustellen. Im Folgenden möchte ich die wesentlichen Formate für Anforderungen kurz mit ihren Vor- und Nachteilen darstellen.

 

Lastenheft und Pflichtenheft

Das Lastenheft schreibt in der Regel der Kunde, es bildet das ab, was er sich "wünscht". Das Pflichtenheft erstellt der Entwicklungspartner oder das Team, das für die Architektur verantwortlich ist. Es beschreibt das, was aus den "Wünschen" entstehen soll: Die finale Software.

Das klassische Pflichtenheft hat die Aufgabe, in Wasserfallprojekten die Anforderungen an die Software aus der sehr technischen Sicht der Softwarearchitektur zu definieren. Es bietet Technikern Sicherheit darüber, wie die Software beschaffen sein muss und ist hauptsächlich in der IT-Welt, vorrangig unter Informatikern, verständlich.

 

Die Erwartungshaltung ist mit einem Pflichtenheft nur schwer auf einen gemeinsamen Nenner zu bringen.

Werden jedoch digitale Projekte zunehmend aus dem Marketingbereich ins Leben gerufen und umgesetzt, so ist das Pflichtenheft sicher wenig geeignet. Warum? Es besteht aus Text und Text enthält meist viele Lücken zur Interpretation – oder es besteht aus hunderten von Seiten und erlaubt es nicht, das Projektergebnis in seiner Gesamtheit zu erfassen und zu validieren. Die Erwartungshaltung wird mit einem Pflichtenheft nur schwer auf einen gemeinsamen Nenner zu bringen sein. 

 

Mockups und Designs

Mockups sorgen früh für ein gemeinsames Verständnis in agilen Projekten.   Bei designlastigen Projekten bilden Designs die beste Basis für ein gemeinsames Verständnis.

Visuelle Elemente eigenen sich am besten zur Abstimmung und zum Evaluieren von verschiedenen Meinungen und Vorstellungen. Text hingegen weniger.

Bei Cooperate Websites oder besonders designlastigen Projektergebnissen sowie in frühen Projektphasen, wenn es um die Abstimmung der User Interfaces geht, eignen sich Mockups, Designs und klickbare Prototypen sehr gut. Sie sind schnell verständlich und eignen sich für schnelle Iterationen im Projekt mit vielen Feedbackschleifen. Die Ideenfindung und die Ideenverfeinerung wird somit beschleunigt und man hat "etwas zum Anfassen" als Ergebnis.

Klickbare Prototypen erlauben schnelle Iterationen in agilen Projekten.

 

Funktionale Beschreibungen sorgen für Klarheit

Dennoch fehlt die Definition der User-System-Interaktion. Bei komplexen Systemen mit Integrationen, Workflows, Moderationsabläufen, Microservice-Architekturen über verschiedene Systeme hinweg und viel Logik müssen Designs und Mockups unbedingt um funktionale Beschreibungen ergänzt werden. Geschieht dies nicht, sieht die Webanwendung oder die Mobile-App am Ende zwar schick aus, funktioniert jedoch nicht wie sie soll. Hier kann man mit Annotationen in den Designs oder Mockups arbeiten, wenn der Umfang überschaubar ist.

Annotationen ergänzen Mockups um funktionale Beschreibungen.

 

Wir empfehlen jedoch die Kombination von Mockups oder Designs mit User Stories oder zumindest Epics und Use Cases (siehe weiter unten).

Randnotiz: Häufig werden in CMS-Projekten die Redakteure vernachlässigt. So wird zwar häufig die "Digital Customer Journey" konzipiert und durchdacht, es werden jedoch nur wenige Gedanken in die "Author Journey" investiert. Als Ergebnis hat man eine Webseite oder Webanwendung, die kein Redakteur pflegen kann oder will. Dies kann vermieden werden, wenn man das CMS seiner Wahl gut kennt und ein paar Gedanken in die Backend-Ansicht und dessen Workflows investiert. Ihre Redakteure werden es Ihnen mit Sicherheit danken ;-)

 

Epics und Use Cases

Die Definition von Epics und Use Cases erfolgt aus Nutzersicht. Beide beschreiben Anwendungsfälle wie den Registriervorgang, das Auswählen von Produkten oder den Checkout-Prozess in einem Onlinestore aus der Sicht, aus der sie der Nutzer der Anwendung später erleben soll. Textliche Beschreibungen können dabei durch Mockups oder Designs visuell ergänzt werden.

 

Ein gutes Konzept erleichtert die Abstimmung zwischen Kunde und Projektteam.

Dies trägt zu einem deutlich besseren Verständnis bei und erleichtert die Abstimmung zwischen Stakeholdern und dem Umsetzungsteam. Für das spätere Entwicklerteam bildet ein Konzept aus Epics und Use Cases mit Mockups oder Designs eine gute Basis für einen nahtlosen Entwicklungsworkflow.

 

User Stories

User Stories sind einzelne und sehr feingranulare, testbare Nutzerinteraktionen einer Software. Sie entsprechen der Form:

 "Als anonymer Nutzer möchte ich meinen Benutzernamen und mein Passwort eintragen und auf 'Anmelden' klicken, sodass ich anschließend die Software als eingeloggter Benutzer verwenden kann. Bitte beachte, dass diese Funktion responsive funktionieren muss und als Authentifizierung oAuth verwenden können soll."

Man sieht, dass dabei die Definition sehr feingranular ist. Die Definition von User Stories ist gerade in agilen Projekten das Mittel zum Zweck, um Anforderungen festzuhalten – immer mit dem Ziel, eine Mehrwert für den Nutzer zu schaffen. User Stories werden häufig in Use Cases gruppiert.

User Stories können auch die perfekte Basis sein um automatisierte Tests, z.B. mit Behat, zu erstellen. So wird das Testen mit sich schnell ändernden Anforderungen und schnell fortschreitenden Ergebnissen auch einfacher zu bewältigen sein und schnellere Release-Zyklen unterstützen. 

Gerade agile Projekte mit schnellen Release-Zyklen und komplexer Systemarchitektur über Microservices verteilt, stellen an das Konzept- und UX-Team hohe Anforderungen. Sind Anforderungen schwammig definiert oder lückenhaft, oder ist das Gesamtsystem nicht im Detail durchdacht, wird das Ergebnis trotz aller Agilität nicht den Vorstellungen entsprechen. Die verhindert schnelle Releases und oft den Gesamterfolg des Projekts.

 

Unsere Erfahrung für Ihren Projekterfolg

 

Bright Solutions führt Ihre Projekte als Web & Mobile Agentur planbar zum Erfolg.

Wenn Sie erfahren möchten, wie Sie am sinnvollsten vorgehen, um Budgetsicherheit, Terminsicherheit und Leistungssicherheit in Ihr Projekt zu bekommen, sprechen Sie uns gerne an. Wir unterstützen Sie von der Konzeption über die Planung bis hin zur Umsetzung Ihres Projekts, von Wasserfall bis agil, von Werkvertrag bis Dienstvertrag und gerne auch in Kombination. Nehmen Sie jetzt Kontakt mit uns auf.

 

Registrieren Sie sich jetzt für unseren kostenlosen Newsletter und bleiben Sie immer auf dem Laufenden

Weitere Blogbeiträge