Einordnung

Die Liste ist für Product Owner und Requirements Engineers gedacht, die Nutzungsanforderungen vor der Schätzung prüfen. Eine Nutzungsanforderung nach ISO 9241-210 beschreibt, was eine Nutzergruppe in ihrem Nutzungskontext erreichen muss, also in ihrer Aufgabe, mit ihren Arbeitsmitteln und in ihrer Umgebung. Woran die Erfüllung geprüft wird, liefern die Messgrößen aus ISO 9241-11: Effektivität, Effizienz und Zufriedenstellung. Je Punkt steht ein Fehlermuster, ein Satz zur Begründung und eine überarbeitete Fassung. Gehen Sie die Punkte je Anforderung durch, bevor die Schätzung beginnt. Die Beispiele stammen aus unseren Trainings zum User Requirements Engineering und sind anonymisiert.

Lösungsvorgabe an Stelle des Nutzungsziels

• Prüfen Sie, ob die Anforderung ein Bedienelement nennt („Button", „Dropdown", „Reiter", „Dashboard"). Das Element ist eine Lösung, und der Test fragt dann nur, ob es existiert. Alt: „Das System muss ein Dashboard mit allen offenen Vorgängen haben." Neu: „Die Sachbearbeiterin muss zu Beginn der Schicht erkennen können, welche Vorgänge heute fällig sind."

• Prüfen Sie, ob die Anforderung eine Bedienung beschreibt („klicken", „auswählen", „öffnen", „scrollen") statt einer Wirkung. Alt: „Der Anwender muss den Kunden aus einer Liste auswählen können." Neu: „Die Beraterin muss den Kunden, der gerade anruft, während des Gesprächs aufrufen können."

• Prüfen Sie, ob die Anforderung die Struktur des Altsystems übernimmt („wie bisher im Reiter Stammdaten"). Die Reihenfolge stammt dann aus dem System und nicht aus der Aufgabe; im Review erkennbar daran, dass im Quellenfeld das Altsystem steht und keine Beobachtung. Neu: das Ziel der Aufgabe ohne Verweis auf das Altsystem, mit Quelle aus der Beobachtung.

Unbestimmte Adjektive

• Streichen Sie „schnell", „einfach", „intuitiv", „übersichtlich", wenn kein Maßstab dabeisteht. Jede Person im Test versteht diese Wörter anders. Alt: „Die Suche muss schnell und einfach sein." Neu: „Die Monteurin muss die Ersatzteilnummer für ein Bauteil im ersten Versuch finden können, während sie an der Maschine steht."

• Prüfen Sie, ob „benutzerfreundlich" oder „ergonomisch" als Anforderung steht. Das sind Eigenschaften, die sich nur je Aufgabe messen lassen. Neu: eine Anforderung je Aufgabe mit Maßstab nach ISO 9241-11.

Fehlender Kontextbezug

• Prüfen Sie, ob die Nutzergruppe „der Nutzende" oder „der Anwender" heißt. Für welche Gruppe die Anforderung gilt, bleibt dann offen, und der Test rekrutiert beliebig. Neu: die Gruppe aus der Kontextbeschreibung.

• Prüfen Sie, ob Ort, Arbeitsmittel oder Situation fehlen. Die Anforderung gilt dann am Schreibtisch und wird dort geprüft. Alt: „Der Techniker muss Auftragsdetails einsehen können." Neu: „Der Techniker muss Auftragsdetails an der Maschine mit Handschuhen und bei Tageslicht einsehen können."

• Prüfen Sie, ob die Anforderung eine Aufgabe nennt oder nur eine Eigenschaft. Alt: „Das Portal soll vertrauenswürdig wirken." Neu: „Die Kundin muss nach dem Absenden eines Antrags erkennen können, dass er eingegangen ist und wer ihn bearbeitet."

Fehlender Maßstab

• Prüfen Sie, ob in der Anforderung steht, woran die Erfüllung erkannt wird. Ohne Maßstab lässt sich die Anforderung im Test weder bestätigen noch verwerfen. Neu: Ergänzung um „ohne Rückfrage", „ohne Umgehung", „im ersten Versuch" oder eine Frist aus dem Kontext.

• Prüfen Sie, ob der Maßstab im Akzeptanzkriterium der Story steht und in der Anforderung fehlt. Bei der nächsten Story fehlt er dann wieder. Neu: Der Maßstab gehört zur Anforderung und wird in jede Story übernommen.

• Prüfen Sie, ob mehrere Ziele in einem Satz stehen („anlegen, prüfen und freigeben"). Die Prüfung kann dann nur alle oder keines bestätigen. Neu: eine Anforderung je Ziel.

Herkunft

• Prüfen Sie, ob das Quellenfeld gefüllt ist. Ohne Quelle ist die Anforderung eine Annahme und wird im Konfliktfall nach Hierarchie entschieden. Neu: Kennung der Beobachtung, der Aussage oder des Testbefunds, oder ausdrücklich „Annahme" mit Person und Datum. Im Review erkennen Sie eine erhobene Anforderung daran, dass die Kennung zu einem Protokoll führt.

Was ohne die Korrekturen fehlt

Eine Anforderung mit Lösungsvorgabe wird gebaut und nicht geprüft. Eine Anforderung mit unbestimmten Adjektiven wird im Test von jeder Person anders bewertet. Eine Anforderung ohne Kontext wird am Schreibtisch erfüllt und in der Halle umgangen. Eine Anforderung ohne Maßstab bleibt nach dem Test offen. Und eine Anforderung ohne Quelle verliert im Konflikt gegen die lautere Meinung. Das Prüfraster kostet im Refinement je Anforderung wenig Zeit, sobald das Team die Muster kennt. In unseren ersten Runden dauerte es länger, weil jede Formulierung diskutiert wurde; nach wenigen Refinements ging es in den normalen Ablauf über. Es erspart Stories, die gebaut und nach dem Test in anderer Form neu geschrieben werden.