Nicht-funktionale Anforderungen in User Stories (mit Beispielen!)

Während die funktionale Anforderungen sehr bekannt und verständlich sind, haben nicht-funktionale Anforderungen in User Stories immer ein gewisses Schattendasein. Das ist problematisch, denn auch in diesen nicht-funktionalen Anforderungen stecken wichtige "Wünsche" und Anforderungen, die nicht vergessen werden dürfen. Doch wie halten wir diese in User Stories genau fest?

Übersicht worum geht es?

Während wir in Scrum in einer User Story festhalten, was eine Person aus Anforderungssicht gerne haben möchte (funktionale Anforderung), müssen wir uns zusätzlich auch um sogenannte nicht-funktionale Anforderungen kümmern. Diese haben nämlich ebenso einen sehr entscheidenen Einfluss auf das System. Bei dem einen oder anderen gehen diese gerne mal unter, weswegen ich dafür einen extra Beitrag spendiere.

Begriffsklärung

Was ist eine funktionale Anforderung?

Die funktionale Anforderung legt fest, was ich von einem Produkt erwarte. Ich beschreibe in einer bestimmten Art und Weise (z.B. einer User Story), was das Produkt können soll (Funktion). Zudem können solche funktionalen Anforderungen begrenzt werden. In User Stories können wir dieses zum Beispiel mit Akzeptanzkriterien tun.

Nicht-funktionale Anforderungen

Bei einer nicht-funktionalen Anforderung scheiden sich oft etwas die Geister über die genaue Beschreibung, allerdings sind diese oft über das ganzes System hin gültig und beschreiben, wie gut sich etwas verhalten soll. Sie gehen damit auch über die funktionalen Anforderungen hinaus. Dabei gibt es einen starken Bezug zur Qualität. Ebenso enden diese nicht-funktionalen Anforderungen häufig mit -heit/keit (Wartbarkeit, Sicherheit, Robustheit, ...)

Anzumerken ist auch noch, dass nicht-funktionale Anforderungen in unterschiedlichen Reifegraden vorliegen können. In einer ersten Version ist der Webserver noch lokal auf einer kleinen Maschine eingerichtet, was einen langsamen Seitenaufbau mit sich zieht. Später unter realen Bedingungen müssen dann z.B. Erreichbarkeit und Wartbarkeit anderen Maßstäben gerecht werden. Sie verändert sich also.

Welche Möglichkeiten gibt es, nicht-funktionale Anforderungen zu definieren?

Bleiben wir in einem Scrum Umfeld und gehen zudem davon aus, dass wir auch die User Stories als Format nutzen, um unsere Anforderungen auszudrücken. Dann stellt sich die Frage, wie nicht-funktionale Anforderungen in User Stories gehandhabt werden sollten und was man tatsächlich in der Realität so vorfindet. Dazu zeige ich dir hier einige Möglichkeiten - mit Vor- und Nachteilen.

Nicht-funktionale Anforderungen als User Story

Eine erste und schnelle Idee könnte somit sein, dass wir sagen - "hey cool, schreiben wir doch eine User Story für die nicht-funktionale Anforderung selbst!" Das könnte dann wie folgt lauten:

Wenn wir uns das etwas genauer ansehen, dann stellt uns das aber vor einige andere Probleme. Eine nicht-funktionale Anforderung hat in der Regel Auswirkungen auf mehrere Anforderungen bzw. das ganze System. Diese "nicht-funktionale Anforderung User Story" kann nicht einfach so abgenommen werden. Es ist schwer zu sagen, wann diese fertig ist, denn kannst du so etwas gleich in einem Sprint erledigen? Kann diese User Story alleine betrachtet werden? Es wird auf jeden Fall mal schwierig... 

Nicht-funktionale Anforderungen als Akzeptanzkriterien in jeder betroffenen User Story

Nehmen wir uns im Folgenden mal drei verschiedene Möglichkeiten vor. Diese User Stories sind an sich keine leuchtenden Beispiele einer guten User Story, sie dienen viel mehr dem Verständnis der nicht-funktionalen Anforderungen in den Akzeptanzkriterien.

Du siehst, wodrauf ich hinaus möchte: in jeder User Story die nicht-funktionalen Anforderungen aufzunehmen, ist es mühsam und fehleranfällig. Was du vielleicht noch als Akzeptanzkriterium aufschreibst, wird in der nächsten heißen Phase von jemand anderem vergessen.

Wir müssen also mehrfach die gleichen Dinge tun und sich richtig wertvoll ist das dann auch nicht.

Nicht-funktionale Anforderungen in der Definition of Done

Die Definition of Done legt fest, wann etwas fertig ist, was wir alles getan haben müssen, damit unsere Arbeit als fertig gilt.

Wenn wir uns dann einmal die nicht-funktionalen Anforderungen ansehen, stellen wir fest, dass diese für jegliche Arbeit gilt. Wir wollen schließlich nicht nur eine User Story auf "Wartbarkeit" ansehen, sondern das System / Produkt / das Inkrement, also die erledigte Arbeit.

Fazit