5 Gründe, warum jede Anforderung ihre User Story haben sollte

Die Formulierung einer Anforderung in der Softwareentwicklung als User Story optimiert die Verständlichkeit der Anforderung für alle Beteiligten.

Eine neue Software soll viele Probleme lösen, sie soll Verwaltungsabläufe verbessern. Oder Abläufe für Bürger/-innen einfacher und transparenter gestalten. Sie soll Prozesse standardisieren und vieles mehr. Außerdem muss sie in die Softwareumgebung der Verwaltung passen, skalierbar und anpassbar sein. Die Akzeptanz der geplanten Softwarelösung hängt davon ab.

Zu Recht wird deswegen in den Konzeptionsprozess viel Energie investiert und Ablaufmodelle konzipiert und wieder verworfen. Am Ende steht dann ein Design, das alle Bedürfnisse optimal abbildet.

Verständliche Anwendungsszenarien und klare Akzeptanzkriterien, die Sie als Auftraggeber in der Öffentlichen Verwaltung vorab definiert haben, führen zum besseren Verständnis für Ihre Wünsche an ein Software-Vorhaben. Eine Software soll schließlich Ihr alltägliches Arbeiten erleichtern und die Handhabung sollte Ihren Anforderungen entsprechen. Sie als Auftraggeber können am besten beurteilen, was Sie Sie für einen Mehrwert erwarten.

Eine User Story in der Softwareentwicklung kann dabei helfen, den Entstehungsprozess einer Software effizienter und stressfreier zu gestalten. Und weil User Stories so gut funktionieren, sind sie mittlerweile Standard. Dennoch sind sie in der Verwaltung weitestgehend unbekannt.

1. Über die User Story lassen sich die Anforderungen an die Software verständlicher darstellen.

User Stories haben ihren Ursprung in der agilen Softwareentwicklung, die sich zum Ziel setzt, in einem iterativen Verfahren immer wieder die gefundenen Wege zu hinterfragen und mit den Anforderungen und Bedürfnissen der späteren Anwender abzugleichen.

Laut Wikipedia übersetzt eine User Story einen komplizierten Anwendungsablauf in Alltagssprache.

In der modernen und agilen Softwareentwicklung ist die User Story (auf Deutsch in etwa “Anwendererzählung”) ein bewährtes Werkzeug, um Anforderungen von Anwendern an eine Software zu dokumentieren.

2. Eine User Story macht Anforderungen an eine Software besser nachvollziehbar bei der Umsetzung durch die Softwareentwickler/-innen.

Die Formulierung in einfacher Alltagssprache stellt sicher, dass alle Beteiligten — Konzepter/-innen, Entwickler/-innen und Anwender/-innen — dasselbe Verständnis eines Szenarios entwickeln und so schneller zu besseren und akzeptierteren Ergebnissen kommen.

Eine User Story sollte drei wesentliche Fragen beantworten und im Satzbau dabei wie folgt strukturiert sein:

• Wer hat die Anforderung? Die Definition des Users bzw. der Rolle.
• as soll erreicht werden? Das Ziel bzw. der Wunsch hinter der Anforderung.
• Wieso ist das relevant? Die Begründung für die Anforderung.

3. Eine User Story vermeidet Missverständnisse.

Klassischerweise formulieren Auftraggeber ihre Anforderungen an eine neue Software in ihrer Fachsprache und dem Duktus, der allgemein z.B. in der Verwaltung üblich ist. Dies erhöht das Verständnis innerhalb der Verwaltung, macht es jedoch Außenstehenden schwerer, genau zu verstehen, was gemeint ist.

Eine User Story formuliert eine Anforderung in einfacher Alltagssprache und kann so ansonsten unvermeidliche Missverständnisse vermeiden.

4. Die Anzahl der Abstimmungs- und Korrekturschleifen lassen sich drastisch reduzieren.

Während der Entwicklung, beim ersten Schulterblick, bei offiziellen und inoffiziellen Gesprächen zum Thema entstehen oftmals auch während des Entwicklungsprozesses weitere Anforderungen. Oft genug kommt dann sogar die Frage auf, ob nicht ein völlig neuer Ansatz erforderlich ist. Gleichzeitig betrachten und bewerten aber auch die Entwickler/-innen, die das Vorhaben umsetzen, Vorgehensmodelle, machen Vorschläge und Verbesserungen. Und stellen unter Umständen das Konzept ebenfalls in Frage.

Setzt man aber darauf, jede Anforderung mit einer User Story plastisch darzustellen, kann die Entwicklung einer Software glatter und störungsfreier ablaufen und das Ergebnis bei allen Beteiligten Akzeptanz finden.

5. Eine User Story macht alle Anforderungen explizit

In einem Pflichtenheft stehen Anforderungen an eine Software quasi atomisiert, das heißt jede einzelne Funktion ist als einzelner Punkt definiert. Diese Atomisierung ist wichtig, damit die zu entwickelnde Software genau das erfüllt, was Sie sich in der Verwaltung wünschen bzw. was Sie brauchen. Bei der Konzentration darauf, auch wirklich alle Schritte explizit darzustellen, bleibt allerdings oft aus, Anforderungen, die sich aus den Eigenschaften der jeweiligen Anwender ergeben, angemessen zu berücksichtigen.

In einer User Story sind deswegen neben den in einfacher Alltagssprache formulierten Anforderungen an die Funktionen auch die Eigenschaften der Personen, die die Software nutzen sollen, in Personas beschrieben. Die Personas machen in der Entwicklung nachvollziehbar, warum bestimmte Funktionen so und nicht anders aussehen sollten. Eine IT-affine Person legt eben Wert auf andere Dinge als etwa jemand, die/der kaum mit Computern umgeht.

Originally published at www.publicplan.de.