Story-Requirements – ein Gedankenspiel

Spätestens seit sich die agile Softwareentwicklung als alltagstaugliche und in einigen Entwicklungsbereichen auch als alternative Vorgehensweise durchgesetzt hat, sind die User Stories fester Bestandteil der Entwicklung. Die Requirements sind aber als Entwicklungsartefakt nicht ausgestorben. So existieren in vielen Unternehmen beide Artefakte – User Story und Requirement – nebeneinander, quasi stellvertretend für die agile und die klassische Welt. Lassen Sie sich mit dem nun folgenden Gedankenspiel auf eine mögliche Verschmelzung dieser Artefakte ein.

Vorwort

User Stories sind gerade in der agilen Entwicklung ein adäquates Mittel in der Kommunikation von Product Owner und Entwicklungsteam. Sie sind eine Aufforderung zur Konversation, haben eine einfache Struktur und können, wegen ihrer knappen Formulierung auf Karten geschrieben werden. Sie dienen als Planungsobjekte für Sprints und enthalten die essentiellen Akzeptanzkriterien, die die Stakeholder fordern.

Requirements beschreiben ein gewünschtes Systemverhalten und werden vor allem für die Repräsentation in Spezifikationen verwendet (IEEE Std 610.12). Ob nach dem V-Modell oder der RUP-Pyramide, Requirements werden meist über mehrere Abstraktionsebene abgeleitet, bis eine Implementierung erfolgen kann. Die hier beschriebene Verwendung ist sicher aus den klassischen Vorgehensmodellen bekannt.

Vorbemerkung: Ich verwende für das zu entwickelnde Produkt, also auch für Softwareprodukte, den Begriff System. Für die Rolle Auftraggeber oder Product Owner verwende ich den Begriff Stakeholder.

Nun das Gedankenspiel

Wir verschmelzen die Vorteile beider Artefakte. Zum einen beschreiben wir die Rolle und das Ziel, das ein Stakeholder mit dem zu entwickelnden System erreichen will. Dabei geht es nicht um eine exakte Beschreibung des Systemverhaltens. Es wird eine User Story formuliert, welche Grundlage für die Kommunikation – oder besser Konversation – zwischen Stakeholder und Entwicklung ist. Der Nutzen, der dem Stakholder dabei entsteht, wird – anders als bei der reinen User Story – in eigenständigen Requirements formuliert. Dadurch entsteht im Allgemeinen eine abstraktere Beschreibung, weil sich der Nutzen Lösungsneutraler erfassen lässt. Dieser Nutzen, oder auch Value, kann sukzessive beschrieben werden. Das heißt, im Prozess der Konversation werden bei Bedarf weitere Nutzenaspekte der Story erhoben.

Einer Konkretisierung der “Value” Requirements ist nur dann zwingend, wenn die Story aufgeteilt werden muss. Beim Schneiden der User Story ist es essentiell, dass für den Stakeholder weiter ein Nutzen durch die Implementierung entsteht. Wenn die Values in eigenständigen Requirements formuliert sind, kann das Ziel der Story entlang der Requirements neu verfeinert werden. Es entstehen also “kleinere” Storys mit Nutzen für den Stakeholder.

Ein weiterer Aspekt in diesem Gedankenspiel sind die Akzeptanzkriterien. Diese werden für jede User Story definiert. Das Neue ist die explizite Referenzierung der Akzeptanzkriterien zu den eigenständigen „Value“ Requirements. Diese „testet durch“ Beziehung dokumentiert, wie der Nutzen des Stakeholder durch das entwickelte System nachgewiesen werden kann. Im Fokus steht also nicht das Vorhandensein irgendeiner Systemfunktion, sondern der Kontext, in dem eine solche Funktion Nutzen erzeugt.

Oft fällt es den Stakeholdern leichter über Akzeptanzkriterien nachzudenken und diese zu benennen, vor allem, wenn die Systemfunktionen schon aus Vorgängersystemen bekannt sind. Schwieriger ist es in diesen Fällen den Nutzen zu beschreiben. An dieser Stelle hilft der Kontext, den die User Story mit ihren Akzeptanzkriterien aufspannt. So können die Requirements leichter nach folgendem Schema identifiziert werden:

• Welche Tests muss ein System bestehen?
• Welche Eigenschaften und Funktionen müssen folglich in dem System implementiert sein?
• Was für ein Nutzen entsteht dem z.B. Anwender durch die Eigenschaften und Funktionen des Systems?

Gerade die letzte Frage ist entscheidend, wirklich das Notwendige zu realisieren. Die Requirements zum Nutzen ermöglichen es dem Stakeholder eine Aussage zur Bedeutung der Story zu machen, also ein Ranking abzugeben.

Das Model einer StoReq – der Story Requirements

Die oben beschriebenen Eigenschaften einer Verschmelzung von User Story und Requirements zu einer StoryRequirements ist in folgendem Diagramm dargestellt. Role und Aim sind vorwiegend Konversationskontext. Acceptance und Requirements beschreiben Systemnutzen und Systemverhalten, auch im Sinne einer Spezifikation. Hier wird die Konformität des Systems aus Sicht der Stakeholder wiedergespiegelt.

Aufbau einer StoryRequirements

Die folgende Abbildung zeigt die „Value“ Requirements als abstraktere Beschreibung der User Story, die den Kontext und damit die Nachvollziehbarkeit der Requirements darstellt.

„Value“ Requirements als abstraktere Beschreibung der User Story

Inspiration

Ein Gedankenspiel bleibt ein Gedankenspiel. Sicher sind auch noch andere Ansätze möglich – denkbar. Etwa die Aims mit expliziten Requirements zu beschreiben. Über was lässt sich besser diskutieren, über Ziele oder Werte? Sicher auch eine Frage, die im Kontext Ihrer Stakeholder beantwortet werden muss. Ich bin in jedem Fall überzeugt, dass es sowohl User Stories als auch Requirements bedarf. So wie es die Konversation und die Spezifikation braucht, um nachhaltig und erfolgreich Produkte zu entwickeln.

Wenn ich Sie mit dem Gedankenspiel zum Nach- und Querdenken inspiriert habe, dann sind meine Ziele erreicht. Vielleicht gerät so der eine oder andere Stein ins Rollen. In diesem Sinne möchte ich Ihnen noch ein Zitat von Friedrich Dürrenmatt mit auf den Weg geben:

„Was einmal gedacht wurde, kann nicht mehr zurückgenommen werden.“ aus „Die Physiker“.