Eine Nutzungsanforderung beschreibt, was Nutzende mit einem System in einer Aufgabe erreichen müssen. ISO 9241-210 beschreibt den Gestaltungszyklus als Abfolge von vier Aktivitäten, die wiederholt werden, bis die Nutzungsanforderungen erfüllt sind. Im Projekt heißt das: Jemand muss nach der Evaluation sagen können, ob eine Anforderung erfüllt ist. Wir legen das Kriterium dafür beim Schreiben der Anforderung fest, weil es dann vor jeder Diskussion über Ergebnisse steht. Diese Anleitung geht die Schritte durch, wie wir sie in der Anforderungsrunde mit Produktteams gehen.

Voraussetzungen

Sie brauchen eine dokumentierte Beobachtung aus dem Nutzungskontext, eine benannte Nutzergruppe und eine Aufgabe, die diese Gruppe mit dem System erledigt. Ohne diese drei Angaben lässt sich kein Kriterium formulieren, weil offen bleibt, wer was unter welchen Bedingungen erreichen soll. Klären Sie außerdem vorab, mit welcher Methode später evaluiert wird, etwa ein moderierter Usability-Test oder eine Inspektion durch Fachleute. Das Kriterium muss mit dieser Methode messbar sein; ein Kriterium für die Zufriedenstellung ist in einer Inspektion ohne Nutzende nicht prüfbar.

Schritt 1: Die Anforderung auf ein Erfordernis zurückführen

Was: Lesen Sie die Anforderung und prüfen Sie, ob sie ein Erfordernis der Nutzenden beschreibt oder bereits eine Lösung vorgibt. „Die Bedienperson muss den Füllstand des Tanks während der Fahrt erkennen können" ist ein Erfordernis. „Ein Balkendiagramm zeigt den Füllstand" ist eine Lösung.

Warum: Ein Kriterium für eine Lösung prüft, ob die Lösung gebaut wurde. Ein Kriterium für ein Erfordernis prüft, ob die Nutzenden ihr Ziel erreichen. Nur das zweite Kriterium sagt etwas über Gebrauchstauglichkeit aus.

Ergebnis: eine Anforderung mit Nutzergruppe, Aufgabe und Nutzungsbedingung, ohne Nennung eines Bedienelements.

Schritt 2: Die Dimension der Gebrauchstauglichkeit wählen

Was: Legen Sie fest, welche der drei Dimensionen aus ISO 9241-11 das Kriterium misst: Effektivität (wird das Ziel erreicht), Effizienz (mit welchem Aufwand) oder Zufriedenstellung (wie beurteilen die Nutzenden die Nutzung).

Warum: Jede Dimension verlangt eine andere Messung. Effektivität erheben wir über den Aufgabenerfolg, Effizienz über Zeit oder Handlungsschritte, Zufriedenstellung über eine Befragung nach der Aufgabe. Eine Anforderung kann Kriterien in mehreren Dimensionen haben. Sie braucht mindestens eines in der Dimension, die für die Aufgabe entscheidend ist. Beim Füllstand während der Fahrt ist das die Effektivität: Die Person muss den Wert erkennen, der Aufwand ist zweitrangig.

Ergebnis: je Anforderung eine benannte Dimension, nach der geprüft wird.

Schritt 3: Schwelle und Bedingung festlegen

Was: Formulieren Sie das Kriterium als Aussage, die nach dem Test mit Ja oder Nein beantwortet werden kann. Dazu gehören die Bedingung (unter welchen Umständen), das beobachtbare Verhalten (was die Person tut oder erreicht) und die Schwelle (ab wann das Kriterium als erfüllt gilt).

Warum: Ohne Schwelle bleibt nach dem Test Interpretationsspielraum. Wenn ein Teil der Testpersonen die Aufgabe löst und ein anderer Teil scheitert, muss vorher feststehen, ob die Anforderung damit erfüllt ist. In einer unserer frühen Testreihen stand das nicht fest, und die Frage wurde in der Ergebnisrunde von der Person entschieden, die den größten Einfluss im Raum hatte. Seitdem legen wir die Schwelle vor dem Test fest und schreiben die Begründung dazu.

Die Schwelle kommt aus dem Nutzungskontext: aus der Häufigkeit der Aufgabe, der Folge eines Fehlers, dem Zeitdruck. Sie ist eine Entscheidung des Teams. Der Einwand, dass sich eine Schwelle vor der ersten Messung kaum seriös setzen lässt, trifft zu. Deshalb führen wir eine geschätzte Schwelle als Schätzung und legen fest, dass sie nach der ersten Messung überprüft wird. Eine allgemein gültige Schwelle gibt es nicht.

Ergebnis: ein Kriterium in der Form „Unter Bedingung X erreichen Nutzende der Gruppe Y das Ziel Z ohne Hilfe der Moderation" mit einer dokumentierten Schwelle.

Schritt 4: Das Kriterium neben die Anforderung schreiben

Was: Legen Sie das Kriterium im selben Dokument ab wie die Anforderung, im selben Datensatz, mit Verweis auf die Beobachtung, aus der die Anforderung stammt.

Warum: Ein Kriterium, das in einem Testplan an anderer Stelle liegt, wird beim nächsten Umbau des Backlogs von der Anforderung getrennt. Nach zwei Iterationen weiß dann niemand mehr, woran die Anforderung gemessen werden sollte.

Ergebnis: ein Anforderungseintrag mit den Feldern Nutzergruppe, Aufgabe, Bedingung, Erfordernis, Kriterium, Schwelle und Quelle.

Schritt 5: Das Kriterium in den Testplan übernehmen

Was: Übersetzen Sie beim Planen der Evaluation jedes Kriterium in eine Testaufgabe. Die Aufgabe stellt die Bedingung her, das Protokoll erfasst das Verhalten, die Auswertung vergleicht mit der Schwelle.

Warum: So entsteht ein Testbericht, der je Anforderung sagt: erfüllt oder nicht erfüllt. Die Entscheidung über die nächste Iteration folgt aus diesem Vergleich und nicht aus der Länge einer Fehlerliste.

Ergebnis: ein Testplan, dessen Aufgaben auf die Kriterien der Anforderungen zurückführbar sind, und ein Bericht mit einem Erfüllungsstatus je Anforderung.

Typische Fehler

Das Kriterium nennt eine Lösung („Der Button ist sichtbar") statt ein Verhalten. Die Schwelle fehlt, und nach dem Test wird diskutiert, ob das Ergebnis reicht. Die Schwelle wird ohne Bezug zum Nutzungskontext gesetzt und ist entweder zu hart oder ohne Aussagekraft. Das Kriterium steht in der Dimension Zufriedenstellung, obwohl die Aufgabe sicherheitsrelevant ist und Effektivität gefragt wäre. Das Kriterium liegt im Testplan, aber nicht bei der Anforderung; diesen Fehler haben wir selbst gemacht, bevor wir das Feld in unsere Anforderungsvorlage aufgenommen haben.

Was am Ende vorliegt

Jede Nutzungsanforderung hat ein Kriterium, das vor der Evaluation feststand. Die Evaluation liefert je Anforderung einen Status. Die Iteration endet, wenn die Kriterien erfüllt sind, oder sie geht mit einem benannten Auftrag in die nächste Schleife.