Zwischen einer Beobachtung im Feld und einer Nutzungsanforderung im Anforderungsdokument liegt eine Strecke mit mehreren Stationen. An jeder Station wird das Material verdichtet, und an zwei Stationen wird interpretiert. Der Beitrag zeigt die Stationen von der dokumentierten Beobachtung über das Kontextszenario bis zur Nutzungsanforderung mit Erfolgskriterium an einem durchgehenden Beispiel. Er richtet sich an Requirements Engineering, Product Owner und UX-Verantwortliche, die Anforderungen aus Feldmaterial ableiten oder prüfen.
Ausgangslage
Ich habe viele Anforderungsdokumente gelesen, in denen eine Zeile stand wie „Der Instandhalter muss die Komponente schnell identifizieren können", und im Review konnte niemand mehr sagen, aus welcher Beobachtung sie stammt. Die Person, die das Material gelesen und die Anforderungen geschrieben hatte, saß im nächsten Projekt. Das Dokument war da, die Herkunft war weg.
Das passiert, wenn die Strecke in einem Schritt gegangen wird. Protokolle, Fotos und Aufzeichnungen beschreiben, was einzelne Personen an einem bestimmten Tag getan haben. Ein Anforderungsdokument braucht Aussagen, die für eine Nutzergruppe gelten, keine Lösung vorwegnehmen und in der Evaluation geprüft werden können. ISO 9241-210 verlangt, dass Nutzungsanforderungen aus dem Nutzungskontext abgeleitet werden und dass die Ableitung dokumentiert ist. Wir arbeiten deshalb mit vier Stationen, an denen das Material eine feste Form hat. Das durchgehende Beispiel stammt aus der Instandhaltung einer Produktionsanlage und ist generisch formuliert.
Station 1: Die dokumentierte Beobachtung
Eine Beobachtung beschreibt eine Handlung, ein Arbeitsmittel und eine Bedingung. Sie trägt eine Kennung und eine Fundstelle im Protokoll. Sie enthält keine Bewertung und keine Vermutung über die Ursache.
Beispiel: „B-07, Sitzung 2, 10:41 Uhr. Der Instandhalter öffnet den Wartungsauftrag auf dem Handheld, legt das Gerät auf den Boden, schraubt die Verkleidung der Antriebseinheit ab, liest die Seriennummer der Komponente mit einer Taschenlampe ab und spricht sie sich selbst laut vor. Er schraubt die Verkleidung zu, nimmt das Handheld auf und tippt die Nummer ein. Beim zweiten Auftrag wiederholt er den Vorgang und korrigiert die Nummer einmal."
Station 2: Das Kontextszenario
Ein Kontextszenario beschreibt in Prosa, wie eine Nutzergruppe eine Aufgabe unter den erhobenen Bedingungen heute erledigt. Es fasst mehrere Beobachtungen zu einem typischen Ablauf zusammen, nennt Nutzergruppe, Aufgabe, Arbeitsmittel und Umgebung nach ISO 9241-11 und führt die Kennungen der Beobachtungen, aus denen es entstanden ist.
Beispiel: „Instandhalter bearbeiten Wartungsaufträge an Antriebseinheiten in der Halle. Die Seriennummer der zu prüfenden Komponente steht auf einem Typenschild hinter einer verschraubten Verkleidung. Der Auftrag liegt auf dem Handheld vor. Während die Verkleidung offen ist, werden beide Hände an der Anlage gebraucht, und das Handheld liegt außer Reichweite. Die Nummer wird im Gedächtnis behalten und nach dem Verschließen eingetippt. Grundlage: B-07, B-12, B-19."
Hier findet die erste Interpretation statt. Wer entscheidet, dass B-07, B-12 und B-19 denselben Ablauf zeigen, fasst Einzelfälle zu einem Muster zusammen. Wir kennzeichnen diese Entscheidung mit einem Feld „Interpretation" im Szenario: „Zusammengefasst, weil in allen drei Fällen ein Wert vom Typenschild in das Handheld übertragen wird, während beide Hände an der Anlage gebraucht werden. B-12 zeigt denselben Ablauf an einer anderen Komponente." Ein Review kann das anfechten, etwa weil B-12 einen anderen Auftragstyp betrifft.
Station 3: Die Nutzungsanforderung
Die Nutzungsanforderung nennt, was die Nutzergruppe in der beschriebenen Situation erreichen können muss. Sie nennt keine Lösung und keinen Bedienschritt. Sie führt die Kennung des Szenarios.
Beispiel: „Der Instandhalter muss die Seriennummer der geprüften Komponente in den Wartungsauftrag übernehmen können, ohne sie sich merken zu müssen, auch während beide Hände an der Anlage gebraucht werden. Grundlage: Szenario S-03."
Hier findet die zweite Interpretation statt. Ein erster Entwurf könnte lauten: „Der Instandhalter muss die Nummer fotografieren können." Das ist die beobachtete Umgehung, umgeschrieben in eine Anforderung, und damit schon eine Lösung. Ein zweiter Entwurf geht in die andere Richtung: „Der Instandhalter muss die Komponente identifizieren können." Das ist weiter, als die Beobachtung hergibt; die Identifikation war in keiner Sitzung ein Problem. Die gewählte Fassung liegt dazwischen und benennt das Ziel hinter der Umgehung. Wir halten die Wahl mit einem Satz fest: „Gewählt, weil die Übernahme der Nummer das beobachtete Erfordernis ist; die Identifikation der Komponente wurde in keiner Sitzung als Problem beobachtet."
Die Art der Quelle bleibt an der Anforderung sichtbar: Beobachtung im Feld oder Aussage im Interview; eine Anforderung aus einer Aussage wird im Review als Hypothese behandelt.
Station 4: Das Erfolgskriterium
Das Erfolgskriterium legt fest, woran die Erfüllung der Anforderung in der Evaluation erkannt wird. Es beschreibt eine beobachtbare Bedingung in einer Testaufgabe.
Beispiel: „In der Testaufgabe ‚Wartungsauftrag an der Antriebseinheit abschließen' überträgt die Testperson die Seriennummer in den Auftrag, ohne sie zu notieren, laut vorzusprechen oder nach dem Verschließen der Verkleidung aus dem Gedächtnis einzugeben. Die übernommene Nummer stimmt mit dem Typenschild überein."
Das Kriterium macht die beobachteten Umgehungen zum Ausschlusskriterium und lässt offen, welche Gestaltungslösung das erreicht: ein Scan, eine Spracheingabe, eine Übernahme aus dem Anlagenmodell. Das entscheidet der Entwurf.
Die Kennzeichnung im Dokument
Über die vier Stationen entsteht eine Kette: Beobachtung, Szenario, Anforderung, Kriterium, jeweils mit Kennung und Verweis auf die vorige Station. Die beiden Interpretationen stehen an ihrer Stelle in einem eigenen Feld mit einem Begründungssatz.
Im Review lässt sich damit jede Anforderung in drei Fragen prüfen: Zeigt die Beobachtung, was das Szenario behauptet? Ist das Ziel in der Anforderung das beobachtete Erfordernis oder ein vermutetes? Lässt sich das Kriterium in einer Testaufgabe beobachten?
Grenzen
Die Strecke macht die Ableitung nachvollziehbar. Sie macht sie nicht eindeutig. Ein anderes Team kann an beiden Interpretationsstellen anders entscheiden. Der Einwand, das Verfahren sei Aufwand ohne Ertrag, weil am Ende doch eine Person entscheidet, trifft zur Hälfte: Entschieden wird so oder so. Der Gewinn liegt darin, dass die Entscheidung im Review sichtbar ist, statt im Kopf einer Person zu bleiben, die im nächsten Projekt sitzt.
Ein Szenario aus einer einzigen Beobachtung wird als solches gekennzeichnet und in der Priorisierung anders gewichtet.
Was danach vorliegt
Ein Anforderungsdokument, in dem jede Nutzungsanforderung über ein Kontextszenario auf dokumentierte Beobachtungen zeigt und ein Erfolgskriterium trägt. Ein Review braucht dafür das Dokument und die Protokolle und kommt ohne Erinnerung an die Feldphase aus.