Nichtfunktionale Anforderungen – was soll das sein?

Es gibt keine nichtfunktionalen Anforderungen, sagte (big) Dave Thomas einst bei einer Keynote auf der Agile-Konferenz.

Und doch taucht in Backlogs, Foren oder Diskussionen immer wieder die Frage nach dem Umgang mit nichtfunktionalen Anforderungen beziehungsweise Stories auf. Meine spontane Antwort dazu ist immer besagtes Zitat von Dave Thomas: "non-functional requirements don't exist". Dave spielte damit vor allem darauf an, dass alles irgendeine Funktionalität bietet (andernfalls braucht es niemand). Das halte ich schon einmal für einen guten Ansatz. In Projekten ist unsere Richtlinie dann meist etwas abgeschwächter und lautet:

Bei einer nichtfunktionalen Story gehen wir zunächst von einem Fehler aus.

Und zwar einem Fehler insofern, dass wir, bevor wir tatsächlich überlegen, diese Anforderung als Story zu akzeptieren, Folgendes hinsichtlich der geforderten Nichtfunktionalität überprüfen:

• Sollte diese Nichtfunktionalität nicht besser in die "Definition of Done" aufgenommen werden? Erfordert diese Anforderung zum Beispiel ein bestimmtes Antwortzeitverhalten, dann sollten wir vielleicht unser System grundsätzlich auf die Einhaltung dieses Antwortzeitverhaltens überprüfen.
  

• Gehört diese Nichtfunktionalität nicht in Wirklichkeit zu einigen wenigen Stories? Damit handelt es sich nicht um eine eigene Anforderung, sondern um ein Akzeptanzkriterium dieser Stories. Ist beispielsweise gefordert, dass der Geschäftsprozess A mit einer Last von 100.000 Benutzern umgehen kann, so sollte dies bei der entsprechenden Story als Akzeptanzkriterium aufgenommen werden und nicht als separate Story.
  

• Kann diese Nichtfunktionalität nicht doch als Funktionalität ausgedrückt werden? Dazu muss zunächst analysiert werden, wer von der Nichtfunktionalität profitiert, das heißt, wer möchte diese haben (Anmerkung: Dabei muss es sich nicht notgedrungen um einen Endbenutzer handeln, sondern es kann auch ein Admin oder Betreiber des Systems sein). Und danach muss definiert werden, wie dieser Nutzen gemessen werden kann. Damit wird daraus eine ganz normale Story mit Nutzer, Ziel und Akzeptanzkriterien.
  

Üblicherweise eliminieren wir dadurch bereits über 95, manchmal sogar 100 Prozent der nichtfunktionalen Anforderungen. Falls wir tatsächlich für eine nichtfunktionale Anforderung keine der obigen Fragen beantworten können, gilt es, diese so zu formulieren, dass allen (einschließlich der Fachseite beziehungsweise dem Product Owner) der Nutzen der Story klar ist und sie somit auch "normal" priorisiert werden kann. Normal habe ich deshalb in Anführungszeichen geschrieben, weil ich zu oft erlebt habe, dass der Nutzen vor allem der Fachseite nicht klar war (klar gemacht wurde) und somit diese Story immer übergangen wurde beziehungsweise immer niedrig priorisiert wurde. Das heißt, auch wenn Nachfolgendes eine ganz grundsätzliche Regel sein sollte, so ist sie in diesem Fall umso wichtiger:

Auch über Technologie muss so gesprochen werden, dass die anwesenden Nichttechnologen der Begründung folgen können. Andernfalls darf sich keiner beschweren, wenn Wichtiges ignoriert wird. ()