Nichtfunktionale Anforderungen als User Stories
Im Product Backlog werden die Anforderungen an ein Produkt festgehalten. Möchte man diese aus Sicht des Nutzers formulieren, wird häufig das Format der User Story verwendet. Ganz klar und spezifisch werden hier die funktionalen Anforderungen für das Produkt aufgenommen. Doch was ist mit den nichtfunktionalen Anforderungen? Auch diese sollten in ein Product Backlog aufgenommen werden. Hier erfährst du, warum nichtfunktionale Anforderungen wichtig sind und wie diese am besten in das Product Backlog integriert werden können z.B. anhand des User Story Templates.
Die Unterschiede zwischen funktionalen und nichtfunktionalen Anforderungen
Schon lange wird im Produktmanagement zwischen funktionalen und nichtfunktionalen Anforderungen unterschieden. Auch beim agilen Anforderungsmanagement werden die beiden Begriffe voneinander abgegrenzt. Hier stellen wir kurz die Unterschiede vor.
Funktionale Anforderungen
Diese Anforderungen beschreiben konkrete Funktionen und Spezifikationen des Produkts. Als User Story werden die Anforderungen möglichst präzise und vollständig aufgelistet, die wichtig für den Nutzer sind. Es handelt sich um produktspezifische Anforderungen, die in der Regel nicht auf jedes weitere beliebige Produkt übertragen werden können. Diese Beispiele sind typische funktionale Anforderungen:
Ich möchte als Nutzer eines Textverarbeitungsprogramms eine Tabelle einfügen können.
Das Programm muss auf Grundlage einer Formel den Kaloriengehalt des Menüs berechnen können.
Nichtfunktionale Anforderungen
Die nichtfunktionalen Anforderungen sind weniger spezifisch. Sie beschreiben zum Beispiel eine Qualität, eine Bedingung oder eine Eigenschaft des Produkts. Diese Anforderungen sind nicht unbedingt produktspezifisch. Sie können allgemeingültig für mehrere Produkte oder sogar für das komplette Design oder die Architektur einer Software gelten:
Benutzerfreundliche Oberfläche
Schnelle Reaktionszeiten
Aufgrund ihres unspezifischen Charakters besteht die Gefahr, dass diese Anforderungen bei der Erstellung des Product Backlogs stiefmütterlich behandelt werden. Allerdings sollten diese Anforderungen darin enthalten sein, da sie für den Nutzer von großem Interesse sind. Wenn Qualität, Zuverlässigkeit oder Schnelligkeit nicht auf die Bedürfnisse der Kunden ausgerichtet werden, dann wird das Produkt mit hoher Wahrscheinlichkeit nicht genutzt, denn die Funktionalität allein genügt nicht, um die Nutzer zufriedenzustellen. Deshalb steht die Überlegung im Raum, wie die nichtfunktionalen Anforderungen in die Produktentwicklung eingebunden werden können. Sie als User Story zu formulieren ist hilfreich, um diese Art der Anforderungen zu priorisieren.
So kannst du nicht funktionale Anforderungen in Scrum als User Stories beschreiben
- Nichtfunktionale Anforderungen sollten messbar beschrieben werden
- Nichtfunktionale Anforderungen aus Sicht des Kunden betrachten
- Ist die nichtfunktionale Anforderung vielleicht besser in der „Definition of Done“ aufgehoben?
Nichtfunktionale Anforderungen sollten messbar beschrieben werden
Die Aussage, dass deine Seite eine möglichst schnelle Reaktionszeit haben soll, ist für das Entwicklerteam zu ungenau. Hier werden keine messbaren Anforderungen beschrieben. „Schnell“ ist in diesem Fall eine ungenaue Aussage, die quasi jeder Entwickler unterschiedlich definiert.
Für das Team ist es in diesem Beispiel hilfreich, wenn es genaue Angaben bekommt. Diese können gemeinsam erarbeitet werden. Ein Mittel kann eine Einschränkung sein, die bezüglich der Anforderung gemacht wird. Dadurch werden Eigenschaften greifbarer und können problemlos umgesetzt werden. Hier kann die Anforderung zum Beispiel lauten:
Die Seite sollte in unter x Sekunden laden.
Der Kalorienverbrauch soll nach dem Klick in weniger als 8 Sekunden angezeigt werden.
Nichtfunktionale Anforderungen aus Sicht des Kunden betrachten
Beim Erstellen der User Stories sollten sich die Beteiligten in die Perspektive des Kunden versetzen. Für die Erstellung der User Story kann es nützlich sein, sich mit Hilfe eines Format das Produkt konkret vorzustellen:
„Als <Nutzer> möchte ich <Ziel>, damit <Grund>”
Dieses simple Format kann dir und deinem Team helfen, nach dem Grund für die Anforderung zu fragen. Warum kann es wichtig für einen Nutzer sein, wenn der Kalorienverbrauch des Menüs in weniger als 8 Sekunden angezeigt wird? Weil der Nutzer somit zügig einen Vergleichswert hat, mit dem er selbst das Menü in seiner eigenen Zeitplanung fertigstellen kann.Allerdings solltest du hier das Ergebnis hinterfragen und die Formel nur als „Denkwerkzeug“ betrachten. Wenn die Antwort nach dem „Warum?“ zu kompliziert oder verwirrend ausfällt, dann solltest du das direkte Gespräch mit dem Kunden oder Anwender suchen. Frage die Personen, warum diese eine Eigenschaft für sie persönlich wichtig ist. Manchmal stellt sich heraus, dass eine nichtfunktionale Anforderung gar nicht so unspezifisch ist, sondern nur ungenau formuliert ist.
Ist die nichtfunktionale Anforderung vielleicht besser in der „Definition of Done“ aufgehoben?
Geht es um übergreifende Punkte wie zum Beispiel die Reaktionszeiten eines Programms? Dann kann es Sinn machen, diese in die „Definition of Done“ aufzunehmen. Gemeinsam mit deinem Team und eventuell den Stakeholdern könnt ihr überlegen, ob eine schnelle Reaktionszeit nicht grundsätzlich ein Kriterium für das ganze System sein sollte.
Die Einbindung einer nichtfunktionalen Anforderungen in die Definition of Done hat zur Folge, dass jedes Item diese erfüllen muss. Das ist vorteilhaft, wenn es zum Beispiel um ein Design und deren Konformität mit der Corporate Identity o.ä. geht.
Nichtfunktionale Anforderungen in funktionale Anforderungen umwandeln
Nichtfunktionale Anforderungen können wie funktionale Anforderungen als User Story formuliert werden. Das sollten sie auch, damit sie nicht übersehen oder vernachlässigt werden. Wichtig ist, dass diese messbar formuliert und in irgendeiner Weise eingeschränkt werden. Wenn du selbst keine Einschränkung vornehmen kannst, hilft dir die oben vorgestellte Formel. Sie fragt nach dem „Warum?“ und kann dir somit eine Denkhilfe sein. Ansonsten hilft dir das direkte Gespräch mit deinem Team, den Nutzern oder Stakeholdern.
Erste Informationen zum Thema Scrum und User Stories findest du auf unserer Webseite. Möchtest du tiefgehendes Wissen zu Scrum erlernen? Dann melde dich am besten zu einer Scrum Schulung an und lerne die Grundlagen des agilen Arbeitens!