Fotolia_121961271_M

User Stories – Die besseren Requirements?

Veröffentlicht am Veröffentlicht in Deutsche Blogs, Requirements Engineering

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.

Gerne unterstütze ich Sie bei individuellen Fragen zu der Thematik. Die Requirementsanalyse zum Festpreis im Rahmen des „HEICON Starter“ (siehe www.heicon-ulm.de àProdukte) bietet Ihnen eine schnelle, günstige und unabhängige Beurteilung Ihrer Requirements inklusive Verbesserungsvorschlägen.

Senden Sie eine Mail an: info[at]heicon-ulm.de!

Ein Gedanke zu „User Stories – Die besseren Requirements?

  1. Hallo MArtin,

    offensichtlich sind wir wieder in Sync.

    Ich schlage mich mit USer Stories herum und frage wo denn die Requirements bleiben.
    Die Jungs testen zwar laufend, aber immer was anderes.
    Wie du so schön aufführts gibt es wenige gute Requirements, das liegt aber häufig auch an den
    zu spezifizierenden Systemen , welche meist nicht ganz einfach sind. (man kannn da nicht immer nur auf dem einzelnen Requirement rumreiten).

    Ich gebe dir auch recht, dass die Reuirements flexibler über die Projektlaufzeit sein müssen.
    Es gibt einige Ansätze dies über die (project developement) Tracability insgesamt herzustellen (siehe die IEEE requiremetns engineering proceedings 2016) was meinem Verständniss nach den Link zur agilen ENtwicklung darstellt. Auch hier muss es möglich sein die Deltas in einer Entwicklung zu tracken.
    Wenn ich mehrer Releases (schnell) hintereienander baue, müssen die Unterschied auf allen Ebenen (automatisch) identifizierbar sein.
    Wenn jede Phase der Entwicklung toolgestützt arbeite sollte es auch möglich sein die Abhängigkeiten
    über links zu tracen (natürlich in einer vernünftigen Granularität).

    feel free to comment

    Klaus Bäuerle

    mfg
    Klaus

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.