Im Refinement liegt eine Karte auf dem Tisch: „Ein roter Warnhinweis erscheint, wenn der Druck den Grenzwert überschreitet." Damit ist die Gestaltungsentscheidung gefallen, bevor jemand eine Alternative entworfen hat, und die Evaluation kann später nur noch prüfen, ob der Hinweis gebaut wurde. Diese Anleitung zeigt die Formulierungsmuster, mit denen wir in Anforderungsrunden das Erfordernis herausarbeiten und die Lösung offen lassen.
ISO 9241-210 trennt die Aktivität „Nutzungsanforderungen festlegen" von der Aktivität „Gestaltungslösungen entwerfen". Der Grund ist praktisch: Erst wenn das Erfordernis feststeht, lassen sich mehrere Lösungen dagegen prüfen. Im Projektalltag verschwimmt die Grenze. Anforderungen kommen aus Workshops, in denen schon Skizzen an der Wand hängen, oder aus Tickets, die ein Feature beschreiben. Wir bekommen in fast jeder Anforderungsrunde Sätze vorgelegt, die eine Lösung enthalten, und gehen sie mit dem Team in fünf Schritten durch.
Voraussetzungen
Sie brauchen eine dokumentierte Beobachtung oder Aussage aus dem Nutzungskontext, aus der die Anforderung abgeleitet wird. Sie brauchen außerdem die Angabe, welche Nutzergruppe betroffen ist und in welcher Aufgabe das Erfordernis auftritt. Ohne diese Quelle lässt sich beim Umformulieren nicht prüfen, ob die neue Fassung noch das beschreibt, was beobachtet wurde. Holen Sie die Person an den Tisch, die den ursprünglichen Vorschlag gemacht hat; sie kennt die Situation, aus der er stammt.
Schritt 1: Den Vorgriff erkennen
Was: Lesen Sie jede Anforderung und markieren Sie Wörter, die ein Bedienelement, einen Bildschirm, eine Interaktionsform oder eine Technik nennen. Typische Marker sind Button, Dropdown, Dialog, Tab, Swipe, Push-Benachrichtigung, Sprachsteuerung, Farbe, Position auf dem Bildschirm.
Warum: Diese Wörter legen fest, wie das Erfordernis erfüllt wird. Damit ist eine Alternative ausgeschlossen, bevor jemand sie entworfen hat.
Ergebnis: eine Liste der Anforderungen mit Vorgriff, je Anforderung der markierte Begriff.
Schritt 2: Das Erfordernis hinter der Lösung finden
Was: Fragen Sie je markierter Anforderung, was die Nutzenden erreichen müssen, damit die genannte Lösung überhaupt vorgeschlagen wurde. Gehen Sie zurück zur Beobachtung, aus der die Anforderung stammt.
Warum: Die Lösung im Text ist ein Hinweis auf ein Erfordernis, das jemand im Kopf hatte, aber nicht aufgeschrieben hat. Die Beobachtung zeigt, worum es ging.
Beispiel: Hinter dem roten Warnhinweis steckt eine Beobachtung aus dem Feld. Die Bedienperson stand mit dem Rücken zum Display und bemerkte den Druckanstieg erst, als eine Kollegin rief. Das Erfordernis: Die Bedienperson muss eine Grenzwertüberschreitung wahrnehmen, auch wenn sie das Display nicht im Blick hat.
Ergebnis: je Anforderung ein Satz, der das Erfordernis ohne Lösung beschreibt.
Schritt 3: Nach Muster formulieren
Was: Schreiben Sie die Anforderung nach einem festen Muster: Nutzergruppe, Aufgabe oder Situation, Erfordernis, Bedingung. Wir arbeiten mit dem Muster „[Nutzergruppe] muss in [Situation] [Ziel] erreichen können, [Bedingung]."
Warum: Das Muster zwingt dazu, die Angaben aus dem Nutzungskontext zu nennen, und lässt keinen Platz für ein Bedienelement.
Beispiel: „Die Bedienperson muss während der Arbeit an der Maschine eine Grenzwertüberschreitung wahrnehmen können, auch wenn sie das Display nicht im Blick hat." Ob das über ein akustisches Signal, ein Vibrationsband am Handgelenk oder eine Leuchte über der Maschine geschieht, entscheidet der Entwurf.
Ergebnis: eine Anforderung, gegen die sich mehrere Gestaltungslösungen prüfen lassen.
Schritt 4: Die Gegenprobe
Was: Fragen Sie je neuer Anforderung, ob mindestens zwei unterschiedliche Lösungen denkbar sind, die sie erfüllen. Fragen Sie außerdem, ob die Anforderung noch die Beobachtung abbildet, aus der sie stammt.
Warum: Wenn nur eine Lösung denkbar ist, steckt sie noch im Text. Wenn die Anforderung nicht mehr zur Beobachtung passt, wurde beim Umformulieren etwas hinzuerfunden.
Ergebnis: eine geprüfte Anforderung mit Verweis auf ihre Quelle.
Schritt 5: Das Kriterium anhängen
Was: Ergänzen Sie, woran die Erfüllung in der Evaluation gemessen wird, etwa: „In der Testaufgabe nimmt die Testperson die Überschreitung wahr, ohne dass die Moderation hinweist."
Warum: Eine Anforderung ohne Kriterium bleibt eine Absichtserklärung. Mit Kriterium wird sie zum Abnahmemaßstab für jede Lösung, die dagegen gestellt wird.
Ergebnis: eine Nutzungsanforderung mit Erfolgskriterium, bereit für den Entwurf.
Woran Sie einen Vorgriff sonst noch erkennen
Manche Vorgriffe verstecken sich hinter Verben. „Die Nutzenden müssen den Wert eingeben können" setzt eine Eingabe voraus, obwohl der Wert vielleicht gemessen werden könnte. „Die Nutzenden müssen die Liste durchsuchen können" setzt eine Liste voraus. Fragen Sie bei jedem Verb, ob es eine Handlung am System beschreibt oder ein Ziel der Person.
Der Einwand aus Entwicklungsteams, dass eine Anforderung ohne Bedienelement zu vage sei, um sie zu schätzen, trifft zu. Deshalb trennen wir die Anforderung vom Lösungsvorschlag und heften den Vorschlag als eine mögliche Lösung an. Geschätzt wird die Lösung, geprüft wird die Anforderung.
Typische Fehler
Die Anforderung wird so abstrakt, dass sie nichts mehr ausschließt („Das System muss benutzbar sein"). Die Situation fehlt, und die Anforderung gilt scheinbar für alle Fälle. Die umformulierte Anforderung verliert den Bezug zur Beobachtung und beschreibt ein vermutetes Erfordernis. Einen Fehler haben wir selbst gemacht: Wir haben in einer Runde ohne die Fachabteilung umformuliert, die den ursprünglichen Vorschlag eingebracht hatte, und der Vorschlag kam im nächsten Sprint als Ticket zurück. Seitdem sitzt die vorschlagende Person mit am Tisch.
Was am Ende vorliegt
Ein Satz Nutzungsanforderungen, der Erfordernisse beschreibt und Lösungen offen lässt, je Anforderung mit Quelle und Kriterium. Der Entwurf kann Alternativen gegen dieselbe Anforderung stellen. Die Evaluation prüft, ob das Erfordernis erfüllt ist, statt ob das vorgeschlagene Element gebaut wurde.