xylus.de | Das IT und Projektmanagement Blog

Response Time als Anforderung

| Keine Kommentare

Als Endanwender möchte ich das die Software schnell reagiert!
Als Kunde möchte ich eine angemessene Antwortszeit wenn ich <Funktion X> ausführe!

Wer kennt sie nicht solche oder ähnlich formulierte, nicht funktionale Anforderungen zum Thema Software Response Time (Antwortszeit). Im obigen Beispiel als nicht ganz ‘saubere’ User Stories dokumentiert finden sich diese Art Anforderungen sehr häufig vor. Auch in Lastenheften ließt man schon mal solche Formulierungen. Das Problem an nicht funktionalen Anforderungen ist wie so oft die Relativität. Liegt es doch im Auge des Betrachters, was schnell, zeitnah, zügig, angemessen, o.ä. heißt. Anforderungen und User Stories sind möglichst ohne diese ‘schwachen’ Wörter zu formulieren. Ein gemeinsames Verständnis und vor allem die Nachweissbarkeit muss gegeben sein.

Response Time als Anforderung

gehört ebenso wie die Gestaltung und die Struktur einer Anwendung zu den Usabillity Merkmalen guter Software. Zu oft wird sie  jedoch vernachlässigt. Der Ärger kommt erst hinterher, wenn der Kunde mit inakzeptableren Antwortszeiten zu kämpfen hat und das Produkt an Akzeptanz verliert.

Wie also definiere ich die Response Time moderner Anwendung, sei es im Web oder Mobil. Basierend auf ‘harten’ Fakten, nachweisbar und auf Grundlage von Akzeptanzkriterien auch abnehmbar.

Vorweg eine Enttäuschung. Es gibt hierfür keine Vorgabe, keine Industrie Norm, kein ISO, kein DIN, auch nichts vom W3C. Aber es gibt ein paar best-practices und Usabillity Maßstäbe, welche man aufgreifen kann.

Der Weg des Usabillity Gurus

Bereist 1993 beschrieb der Software Usabillity Evangelist ‘Jakob Nielsen’  in seinem Buch ‘Usability Engineering’ [1] drei auf der menschlichen Wahrnehmung basierende, relevante Kennzahlen:

  1. Eine Response Time von < 0,1 Sekunde vermittelt dem Anwender das Gefühl, das die Software augenblicklich und ohne Rückkopplung reagiert.
  2. Eine Response Time von < 1 Sekunde registriert der Anwender zwar, stört Ihn aber nicht weiter in seinem ‘Flow’. Bis zu dieser Zeit ist keine weiterführende Rückmeldung an den Anwender, wie z.B. eine Fortschrittsanzeige, notwendig.
  3. Eine Response Time von 10 Sekunden ist die Grenze bis wohin die Aufmerksamkeit des Anwenders auf dem aktuellen Dialog bleibt. Fortschrittsanzeigen sind in diesem Bereich unabdingbar.
  4. Darüberhinaus (>10s) verliert der Anwender die Geduld und widmet sich anderen Themen und gilt nur als akzeptabel während ‘natürlicher Pausen’.

Der Weg des Gnome(s)

Das Gnome Desktop Projekt hat in seinen Human Interface Guidelines [2] eine ähnliche Einteilung vorgenommen und hat diese noch weiter verfeinert.

  1. Verify that your application provides feedback within 100 milliseconds (0.1 second) after each key press, movement of the mouse, or other physical input from the user.
  2. Verify that your application provides feedback within 100 milliseconds (0.1 second) after each change in the state of controls that react to input from the user— for example, displaying menus or indicating drop targets.
  3. Verify that your application takes no longer than 1 second to display each progress indicator, complete each ordinary user command, or complete each background task.
  4. Verify that your application takes no longer than 10 seconds to accept and process all user input to any task—including user input to each step of a multistep task, such as a wizard.

Der Walldorf Weg

SAP kürzt das Thema stark ab [3] und definiert eine optimale Response Time Ihrer System für Online Transaktionen als nicht länger als 1 Sekunde.

Sonstige Wege und Fazit

Die obigen Beispiele lassen sich größtenteils auch auf moderne Web-Anwendungen anwenden. 10 Sekunden Wartezeit sind m.E. jedoch die äußerste Schmerzgrenze und nicht mehr ganz zeitgemäß. Die Anwendung sollte dem Anwender durch Fortschrittsanzeigen frühzeitiges Feedback melden.

Als gängiger quasi Standard für Webanwendungen ist eine Response Time von 200 bis 500 ms für ‘einfache’ Interaktionen, sowie 5 Sekunden für ‘ausführlichere’ Interaktionen mit dem System inzwischen weit verbreitet.

Aha, also doch wieder diese Aufweichung und Formulierung in schwachen Wörtern wie ‘einfach’ und ‘ausführlich’.
Nun ja, nicht ganz. Bei der Anforderungsaufnahme gilt es nun die Abnahmekriterien zu klassifizieren. Funktionen wie Navigation, Tabellen Sortierung, etc. sollten im unteren Sekunden Bereich liegen. Ausführliche Berechnungen, das laden komplexer Daten, etc. darf auch mal 5-10 Sekunden dauern. Wichtig ist nur, das der Anwender ab spätestens 1 Sekunde ein Fortschritts-Feedback erhält

Als äußerst ‘Responsive’ gelten i.ü. allseits die Google Apps wie Mail und Co. Leider veröffentlicht Google hierzu keine offiziellen Zahlen, zumindest sind mir keine bekannt. Allerdings lassen sich diese Anwendungen  wunderbar als Benchmark für die eigenen Anforderungen und Empfehlungen verwenden. Einfach mal nachmessen, wie lange die durchschnittliche Response Time von Google Mail so ist. Dabei helfen Tools wie Google PageSpeed, Insight, YSlow oder Firebug. Aber das ist nicht mehr Thema dieses Artikels.

Quellen:

[1] Buch  ‘Usability Engineering’ http://www.amazon.com/exec/obidos/ASIN/0125184069/ref=nosim/useitcomusablein

[2] Gnome Desktop http://developer.gnome.org/hig-book/3.5/feedback-response-times.html.en

[3] SAP http://help.sap.com/saphelp_nw70ehp1/helpdata/en/37/d2e93a2876a81ae10000000a11402f/content.htm

[4] http://stackoverflow.com/questions/164175/what-is-considered-a-good-response-time-for-a-dynamic-personalized-web-applicat#164237

Autor: Christof Zahn

Christof Zahn auf Google+

Hinterlasse eine Antwort

Pflichtfelder sind mit * markiert.