.st0{fill:#FFFFFF;}

Scrum Einführung

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

 Februar 27, 2021

von  Sebastian

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

funktionale Anforderungen User Stories
Nicht funktionale Anforderungen User Stories

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:

Als Anwender des Systems möchte ich jede Funktion nach 3 Sekunden bedienen können, um meine Arbeit flüssig zu erledigen.

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... 

Vorteile

  • Das Format kennt das Team
  • Eine User Story kann abgenommen werden
  • Die nicht-funktionale Anforderung kann schnell geschrieben werden

Nachteile

  • Die nicht-funktionale Anforderung betrifft i.d.R. mehr als eine User Story
  • Schwer zu schätzen
  • Erzeugt Abhängigkeiten

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.

Als Administrator des Systems möchte ich jede Funktion nach 3 Sekunden bedienen können, um das System rechtzeitig für alle Benutzer verwalten zu können.

  • Die Funktion steht nach 3 Sekunden zur Verfügung
  • ...

Als Benutzer des Systems möchte ich meine Eingabe spätestens nach 3 Sekunden Wartezeit tätigen, um meine Daten schnell eintragen zu können.

  • Die Funktion steht nach 3 Sekunden zur Verfügung
  • ...

Als <ROLLE> des Systems möchte ich <WUNSCH> ..., um <GRUND>.

  • Die Funktion steht nach 3 Sekunden zur Verfügung
  • ...

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.

Vorteile

  • Sichtbarkeit an jeder User Story gegeben
  • Gute Erinnerung bei der Implementierung
  • Aliqua nulla pariatur elitis

Nachteile

  • Ein und dieselbe nicht-funktionale Anforderungen muss mehrfach aufgenommen werden
  • Fehleranfälligkeit steigt
  • Ggf. mehrfache Diskussion über die eine Anforderung

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.

Vorteile

  • Die DoD gilt für jede User Story
  • Die DoD kann nach und nach verbessert werden
  • Die nicht-funktionalen Anforderungen gehen nicht verloren

Nachteile

  • Die DoD kann ggf. etwas länger / unübersichtlich werden

Fazit

In der Regel fährst du sehr gut damit, wenn du deine nicht-funktionalen Anforderungen nicht in einer User Story fixierst, sondern es in der Definition of Done tust.

Natürlich kann es mal nötig sein, dass du einen besondere Fall anders behandelst. Wenn du aber keinerlei nicht-funktionale Anforderungen in der Definition of Done festhältst, sondern nur in User Stories, ist wahrscheinlich irgendwo der Wurm drin 🙂

Sebastian

Ein paar Worte über den Autor

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

Sebastian Schneider CSP-PO
Sebastian Schneider CSP
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

>