Eine Feldnotiz beschreibt, was eine Person an ihrem Arbeitsplatz getan hat. Eine Nutzungsanforderung beschreibt, was Nutzende mit einem System erreichen müssen. Zwischen beiden liegen vier Schritte, und an zwei davon setzt eine Interpretation ein, die dokumentiert werden muss.
Ausgangslage
Nach einer Feldphase liegen Notizen, Fotos, Transkripte und Aufzeichnungen vor. Das Material ist konkret: Eine Person hat an einem bestimmten Tag eine bestimmte Aufgabe erledigt, mit bestimmten Arbeitsmitteln, unter bestimmten Bedingungen. Ein Anforderungsdokument braucht dagegen Aussagen, die für eine Nutzergruppe gelten und die ein Entwicklungsteam umsetzen kann.
Der Weg von der einen Form zur anderen wird in vielen Projekten in einem Schritt gegangen: Jemand liest das Material und schreibt Anforderungen auf. Das Ergebnis ist im Review schwer zu prüfen, weil niemand mehr sagen kann, aus welcher Beobachtung eine Zeile stammt und welche Verdichtung dazwischen stattgefunden hat. ISO 9241-210 verlangt, dass Nutzungsanforderungen aus dem Nutzungskontext abgeleitet werden. Wir machen diese Ableitung in vier Schritten sichtbar.
Schritt 1: Die Beobachtung festhalten
Jede Beobachtung erhält eine Kennung und eine Fundstelle: Sitzung, Zeitstempel oder Seite im Protokoll. Der Text der Beobachtung bleibt beschreibend. Er nennt, was die Person getan hat, welches Arbeitsmittel sie benutzt hat und was dabei passiert ist. Bewertungen und Ursachenvermutungen stehen getrennt davon in einem eigenen Feld.
Ein Beispiel aus einer anonymisierten Feldstudie bei einem Landmaschinenhersteller: „B-14: Der Fahrer stoppt die Maschine am Feldrand, holt ein Smartphone aus der Jackentasche, fotografiert das Terminal und schickt das Foto an den Betriebsleiter." Die Beobachtung sagt noch nichts über eine Anforderung. Sie ist das Rohmaterial.
Schritt 2: Aufgabenmuster bilden
Im zweiten Schritt werden Beobachtungen aus mehreren Sitzungen nebeneinandergelegt. Wiederkehrende Abläufe bilden ein Aufgabenmuster. Das Muster beschreibt das Ziel der Aufgabe, die Teilschritte, die beteiligten Personen und die Arbeitsmittel. Jedes Muster führt die Kennungen der Beobachtungen, aus denen es entstanden ist.
An dieser Stelle setzt die erste Interpretation ein. Wer entscheidet, dass B-14 und B-27 zum selben Muster gehören, trifft eine Entscheidung. Wir dokumentieren sie mit einem Satz: „Zusammengefasst, weil in beiden Fällen ein Wert aus dem Terminal an eine zweite Person übergeben wird." Der Satz lässt sich im Review lesen und anfechten.
Schritt 3: Den Nutzungskontext beschreiben
Der dritte Schritt ordnet die Aufgabenmuster in den Nutzungskontext ein. Nach ISO 9241-210 besteht er aus Nutzenden, Aufgaben, Arbeitsmitteln sowie physischer und sozialer Umgebung. Für jedes Muster wird festgehalten, welche Nutzergruppe es ausführt, unter welchen Umgebungsbedingungen und mit welchen Arbeitsmitteln. Aus dem Beispiel wird: Der Fahrer arbeitet im Freien, bei wechselndem Licht, mit Handschuhen, und der Betriebsleiter sitzt im Büro. Die Übergabe des Werts findet zwischen zwei Orten statt.
Die Kontextbeschreibung ist der Maßstab, an dem sich später messen lässt, ob eine Anforderung erfüllt ist. Ohne sie steht eine Anforderung ohne Bezug im Dokument, und jede Person im Team ergänzt den Kontext aus ihrer eigenen Vorstellung.
Schritt 4: Die Nutzungsanforderung formulieren
Die Nutzungsanforderung nennt, was Nutzende in diesem Kontext erreichen müssen. Sie nennt keine Lösung. Aus dem Beispiel: „Der Fahrer muss den aktuellen Wert des Terminals an den Betriebsleiter übermitteln können, ohne die Maschine zu verlassen." Die Formulierung führt die Kennung des Aufgabenmusters und die Kennungen der Beobachtungen. Wer im Review fragt, warum diese Anforderung so lautet, findet in wenigen Minuten die Stelle im Material.
Die Interpretation im vierten Schritt liegt in der Wahl des Verbs und der Bedingung. „Übermitteln können" ist weiter gefasst als „fotografieren können". Wir halten die Begründung fest: Das Foto ist die beobachtete Umgehung, die Übermittlung das Ziel dahinter.
Grenzen
Vier Schritte machen die Ableitung nachvollziehbar. Sie machen sie nicht objektiv. Die Entscheidungen in Schritt 2 und Schritt 4 bleiben Entscheidungen, und ein anderes Team könnte sie anders treffen. Der Gewinn liegt darin, dass die Entscheidung sichtbar ist und diskutiert werden kann. Das Verfahren setzt außerdem voraus, dass die Feldphase Beobachtungen geliefert hat. Eine Aussage im Interview („Ich würde das gern per App schicken") ist eine Selbstauskunft, wird als solche gekennzeichnet und im Review anders gewichtet.
Die Anzahl der Beobachtungen, die ein Muster stützen, sagt etwas über die Stärke der Evidenz. Ein Muster aus einer einzigen Sitzung wird als solches markiert und im Review anders behandelt als eines aus mehreren.
Was danach vorliegt
Am Ende der vier Schritte liegt ein Anforderungsdokument vor, in dem jede Nutzungsanforderung über ein Aufgabenmuster auf eine oder mehrere Beobachtungen zeigt. Die Kontextbeschreibung steht im selben Dokument. Die Interpretationen sind an den beiden Stellen, an denen sie stattfinden, mit einem Satz begründet. Ein Product Owner kann mit diesem Dokument priorisieren, ein Entwicklungsteam kann daraus Akzeptanzkriterien ableiten, und im Usability-Test lässt sich prüfen, ob die Anforderung erfüllt ist.