User Stories werden im Rahmen der agilen Softwareentwicklung zur Spezifikation von Anforderungen eingesetzt. Sie umfassen in der Regel nicht mehr als zwei Sätze und können entweder formlos angelegt werden oder unter Verwendung einer Vorlage. User Stories sind Dreizeiler in dieser Form:
Als Buchliebhaber
|
will ich einfach und sicher Bücher kaufen,
|
damit mir nie der Lesestoff ausgeht.
|
User Stories beschreiben aus Sicht einer Stakeholdergruppe, welche Bedürfnisse das IT-System erfüllen soll. Somit sind sie Anforderungen.Aber: Können User Stories auch gute Anforderungen sein? Laut International Requirements Engineering Board (IREB) muss eine gute Anforderung folgende Kriterien [1] erfüllen:
-
-
-
-
-
-
-
- verständlich
- abgestimmt
- notwendig
- verfolgbar
- konsistent
- realisierbar
- eindeutig
- prüfbar
- vollständig
-
-
-
-
-
-
Kinder-, Laien- und Vorstands-tauglich
User Stories werden als Anforderungsform gewählt wegen ihrer guten Verständlichkeit auch für Endbenutzer. Man könnte auch von KLV-Tauglichkeit [2] sprechen. Kinder, Laien und Vorstände sollten die Formulierung also auch problemlos verstehen können. Das ist hier sicherlich der Fall.
Ob obige User Story abgestimmt oder notwendig ist, können wir ohne weiteres Hintergrundwissen nicht beurteilen.
Verfolgbarkeit ließe sich in einem Werkzeug oder auf der Story Card dokumentieren, indem man ihre Quelle angibt und eine Verlinkung zum Code herstellt, z.B. durch Angabe der Story-Nummer im Versionsverwaltungssystem des Codes.
Interessanterweise kann es gelingen, in einem knappen Dreizeiler Inkonsistenzen und Realisierungsprobleme einzubauen. „Einfach und sicher“ leidet an der inhärenten Widersprüchlichkeit von Einfachheit und Sicherheit. Sichere Bestellungen sind umständlich und einfache Bestellungen eher unsicherer. Dass dem Buchliebhaber wirklich nie der Lesestoff ausgeht, kann auch der schnellste Lieferant nicht sicherstellen. Diese beiden Qualitätsprobleme lassen sich durch eine schwammigere Umformulierung beheben:
Als Buchliebhaber
|
will ich mit der allgemein üblichen Einfachheit und Sicherheit Bücher kaufen,
|
damit ich Lesestoff nachbestellen kann, sobald er mir ausgeht.
|
Statt sich also zwischen Einfachheit und Sicherheit zu entscheiden, wählt man hier den Stand der Technik. Das Unwort „nie“, das in Anforderungen ohnehin nichts zu suchen hat, ist nun auch fort.
Bleibt noch zu fragen: Ist diese User Story eindeutig, prüfbar und vollständig?
Behaviour-Driven Development
„Einfach und sicher“ war schon weder eindeutig noch prüfbar, aber die Formulierung „mit der allgemein üblichen Einfachheit und Sicherheit“ macht es nicht besser. Prüfbar ist eine Anforderung, wenn sie die Informationen eines Testfalls enthält. Laut Behaviour-Driven Development BDD sind das diese drei Elemente: Voraussetzung, Trigger und Ergebnis.
Also etwa so:
Unter der Voraussetzung, dass der Buchliebhaber einen aktiven Account hat
und eingeloggt ist,
|
Wenn der Buchliebhaber ein Buch ausgewählt hat
und auf „in Warenkorb übernehmen“ klickt,
|
Ist das Buch anschließend im Warenkorb enthalten.
|
Das wäre zwar ein ordentlicher Testfall, prüft aber nicht den gesamten Kauf des Buchs ab. Man bräuchte noch eine Suche, eine Bestellung, die Bezahlung, also eine ganze Liste von Testfällen. Genau genommen hat unsere User Story einen gesamten Geschäftsprozess umfasst, dessen komplette Modellierung als Aktivitätsdiagramm die Länge einer Din-A4-Seite überschreiten würde.
Um wirklich eindeutig, prüfbar und vollständig zu sein, sollte nicht nur der gesamte Kaufprozess ausmodelliert werden, sondern auch dessen Ausnahme- und Fehlerfälle. Man kann ein einzelnes Buch kaufen oder mehrere. Was soll geschehen, wenn ein Kunde den Kaufprozess abbricht? Kann er Bücher aus dem Warenkorb entnehmen? Welche Zahlungsarten sollen unterstützt werden? Um die Ware versenden zu können, benötigen wir eine Versandadresse. Wie und wann stellen wir sicher, dass wir eine haben? Schon beim Anlegen eines Accounts oder beim Kauf?
Diese Informationen bzw. Anforderungen können in weiteren User Stories stehen und müssen sie auch, denn eine Story soll ja nicht zu umfangreich werden, sondern innerhalb einer Iteration umsetzbar sein. Allerdings soll sie laut den INVEST-Kriterien [3] von Bill Wake (Independent, Negotiable, Valuable, Estimable, Small, Testable = unabhängig, verhandelbar, nützlich, quantifizierbar, klein, prüfbar) eben auch unabhängig von anderen User Stories sein.
Fazit
Es ist grundsätzlich schwierig, gute Anforderungen zu schreiben. User Stories von ausgezeichneter Qualität im klassischen Sinne kann es jedoch kaum geben. Dafür sind sie zu kurz (drei Textzeilen), zu klein (eine Iteration Umfang) und zu schlicht (nur der Idealfall dargestellt).
[1] siehe IREB Foundation Level Lehrplan, Kap. 4.6 https://www.ireb.org/content/downloads/2-syllabus-foundation-level/ireb_cpre_syllabus_fl_de_v221.pdf
[2] http://www.werner-gleissner.de/site/publikationen/WernerGleissner_offiziell-Nr-1011-Fuer-Kinder-Laien-und-Vorstaende.pdf (Link veraltet)
[3] http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/