Das Buch „User Stories“ von Mike Cohn (ISBN 978-3-8266-5898-3) hat mich inspiriert, einmal mehr über den Bezug zwischen User Stories und Requirements nachzudenken. In der Software Entwicklung werden agile Methoden in den letzten Jahren oft bevorzugt eingesetzt. Die klassischen Vorgehensweisen, insbesondere das Wasserfallmodell und auch das V-Modell, scheinen etwas aus der „Mode“ zu kommen.
Konsequenter Weise werden damit User Stories gegenüber den „klassischen“ Requirements auch bevorzugt eingesetzt. Helfen die User Stories aber wirklich, bessere Software Qualität abzuliefern? Gibt es nicht auch viele Aspekte, bei denen es gar keine Unterschiede gibt?

User Stories:

Was ist eine User Story? Mike Cohn schreibt dazu folgendes:
Eine User Story beschreibt eine Funktionalität, die entweder für den User oder den Käufer eines Systems oder einer Software von Wert ist. User Stories setzen sich aus drei Bestandteilen zusammen:

• einer schriftlichen Beschreibung der Story, die zur Planung und als Erinnerung verwendet wird
• Gesprächen über die Story, um die Details der Story herauszuarbeiten
• Tests, die Details vermitteln als auch dokumentieren und mit denen festgelegt wird, wann eine Story vollständig umgesetzt ist

Ron Jeffries bezeichnet diese drei Aspekte auch als „Card“, „Conversation“ und „Confirmation“.
Des Weiteren definiert Mike Cohn folgende 6 Eigenschaften von guten User Stories: unabhängig, verhandelbar, werthaltig, schätzbar, klein, testbar

Requirements:

Eine Definition des Begriffes Requirement finden Sie im Blog Beitrag IEC 61508: Spezifikation – Architektur – Requirements. Gibt’s da Unterschiede?

Aus meiner Sicht besteht die große und ganz wichtige Gemeinsamkeit zwischen User Stories und Requirements im Kern in der Fokussierung auf die Beschreibung der Funktionalität. Einerseits steht damit, fast automatisch, das Kundeninteresse im Mittelpunkt (wichtiger Aspekt bei der agilen Entwicklung) und andererseits sind solche User Stories oder Requirements in der Regel leicht nachweisbar, weil sie testbar sind.
Die weiteren User Story Eigenschaften „unabhängig, werthaltig, schätzbar und klein“ treffen auch uneingeschränkt auf gute Requirements zu. Bitte machen Sie jetzt nicht den Fehler und vergleichen Sie vor Ihrem geistigen Auge gute User Stories mit schlechten Requirements. Ich denke dazu neigt man im ersten Moment recht schnell, weil es eben so viele schlechte Requirements gibt. Auch wenn sich viel getan hat, im Projektalltag existieren leider immer noch viel zu wenig gute Requirements. Es gibt leider immer noch keinen wirklich breiten Konsens was gute Requirements sind, auch wenn viele verschiedene Anstrengungen in diese Richtung unternommen wurden.

Die User Story Eigenschaft „verhandelbar“ trifft in der Regel auf Requirements nicht zu. Dazu passt, dass für Requirements auch nicht gilt, dass man Details in Gesprächen herausarbeitet. Beim Requirement besteht der Anspruch darin, dass es „eindeutig“ ist. Hier treten die Unterschiede zwischen dem „agilen“ Ansatz und den „klassischen“ Ansätzen zu Tage.

Schlussfolgerungen:

Die User Story als auch das Requirement konzentrieren sich auf die Beschreibung der Funktionalität in Form eines unabhängigen, werthaltigen, schätzbaren, testbaren und kleinen Textes. Dies zeigt die große Gemeinsamkeit zwischen beiden Darstellungsformen auf.

Die aufgezeigten Differenzen bieten aus meiner Sicht großes Potential, um das Requirements Engineering weiter zu entwickeln. Dass ein Requirement auch nach Vertragsabschluss „verhandelbar“ sein muss, zeigen viele, viele Projekte aus den letzten Jahrzehnten.

Auch wie hoch der Detailgrad eines Requirement sein soll/muss ist eines der großen Probleme des klassischen Requirements Engineerings. Der agile Ansatz, dass letztlich kein noch so guter Text gute Gespräche ersetzen kann ist mir sehr sympathisch, weil er auch meiner Lebenserfahrung generell entspricht. Es ist zu wünschen, dass das klassische Requirements Engineering die agilen Ansätze als Möglichkeit zur Weiterentwicklung versteht.

Andererseits tut man sich auf dem Gebiet der sicherheits-relevanten Entwicklung sehr schwer, mit dem Ansatz, dass nicht alles lückenlos dokumentiert sein muss. Hier steht schließlich im Raum, dass man ggf. das entsprechende Vorgehen vor einem Gericht verteidigen muss. In solch einem Fall ist es dann erfahrungsgemäß eine große Schwäche, wenn man Dinge nicht dokumentiert hat.
Schlussendlich bleibt festzuhalten, dass weiterhin die Notwendigkeit besteht die Vorgehensweisen zur Dokumentation, von Anforderungen an ein Software System, weiterzuentwickeln. Weder User Stories noch Requirements lösen die Fragestellungen in befriedigender Form.

Ihre individuellen Fragen zum Requirements Engineering beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).