Einordnung

Die Liste ist für Teams gedacht, die noch keine Kontextbeschreibung im Sinne der Norm haben, aber Material aus früheren Projekten. Legen Sie alle Dokumente zusammen, die etwas über Nutzende, Aufgaben, Arbeitsmittel oder Umgebung sagen. Gehen Sie die Fragen durch und markieren Sie je Frage, ob sich die Antwort aus den Dokumenten ablesen lässt: beantwortet, teilweise beantwortet, offen. Wir machen das in einer Sitzung mit zwei Personen, die die Dokumente kennen. Wer allein liest, ergänzt aus dem Gedächtnis, was im Dokument fehlt, und merkt es nicht.

Hier geht es um die Frage, ob eine Angabe vorhanden ist. Woher sie stammt und ob sie erhoben oder geschätzt wurde, prüfen Sie in einem zweiten Schritt mit der Checkliste zur Datengrundlage im Anforderungsdokument. Zu jeder Frage steht, woran Sie in den Dokumenten erkennen, dass die Angabe fehlt.

Nutzende

• Sind alle Gruppen benannt, die das System bedienen, einrichten, warten oder mit seinen Ergebnissen weiterarbeiten? Dokumente aus früheren Projekten nennen meist die Hauptgruppe; Administration, Service und nachgelagerte Rollen fehlen. Fragen Sie je Gruppe, wer ihre Ergebnisse weiterverarbeitet.

• Ist je Gruppe beschrieben, welches Vorwissen im Fachgebiet und welche Erfahrung mit vergleichbaren Systemen vorliegt? Eine Persona mit Namen, Alter und Zitat beantwortet die Frage in der Regel nicht.

• Ist je Gruppe die Häufigkeit der Nutzung genannt: täglich, wöchentlich, einmal im Jahr? Die Angabe entscheidet über Anforderungen an Erlernbarkeit und Wiedererkennung und fehlt in Rollenbeschreibungen in der Regel.

• Sind körperliche und sprachliche Voraussetzungen genannt, die die Nutzung beeinflussen, einschließlich assistiver Technologien? Fehlt die Angabe, ist die Gruppe in den Dokumenten meist als Durchschnitt beschrieben.

Aufgaben

• Ist je Gruppe benannt, welche Ziele sie mit dem System erreichen will, in ihren eigenen Worten? Ein Ziel wie „Auftrag anlegen" ist eine Systemfunktion; das Ziel dahinter lautet etwa „die Maschine bis Schichtende wieder in Betrieb haben".

• Ist je Aufgabe beschrieben, was sie auslöst, welche Schritte sie enthält und woran die Person erkennt, dass sie erledigt ist? Prozessdiagramme zeigen den Soll-Ablauf. Ob der Ist-Ablauf dokumentiert ist, erkennen Sie an Schritten, die außerhalb des Systems liegen.

• Sind Häufigkeit, Dauer und Zeitdruck je Aufgabe genannt? Ohne diese Angaben lässt sich später nicht entscheiden, ob eine Aufgabe vor allem schnell oder vor allem fehlerarm sein muss.

• Ist beschrieben, was passiert, wenn die Aufgabe misslingt: für die Person, für andere, für den Betrieb? Die Fehlerfolge fehlt in Backlogs, weil sie keine Funktion beschreibt.

• Sind Aufgaben erfasst, die vor und nach der Nutzung des Systems liegen und zur selben Tätigkeit gehören? Der Anruf vor der Eingabe und der Ausdruck danach stehen in keinem Funktionsdokument.

Arbeitsmittel

• Sind alle Geräte genannt, auf denen das System läuft oder laufen soll, mit Bildschirmgröße, Eingabeart und Bedienhaltung? „Desktop und Mobile" beantwortet die Frage nicht.

• Sind die anderen Systeme genannt, die für dieselbe Aufgabe parallel benutzt werden, und der Wechsel zwischen ihnen? Systemarchitekturen zeigen Schnittstellen, aber nicht, was die Person zwischen zwei Fenstern tut.

• Sind Hilfsmittel erfasst, die die Nutzenden selbst geschaffen haben: Tabellen, Zettel, Fotos, Gruppenchats? Wenn kein Dokument davon berichtet, ist in der Regel niemand am Arbeitsplatz gewesen.

• Sind Dokumente, Formulare und Vorschriften genannt, die während der Aufgabe herangezogen werden? Sie bestimmen, was die Person neben dem Bildschirm liegen hat.

Umgebung

• Ist der Ort der Nutzung beschrieben, und sind es mehrere Orte für dieselbe Aufgabe? Eine Beschreibung ohne Ortsangabe stammt in der Regel aus dem Büro und beschreibt das Büro.

• Sind physische Bedingungen genannt, die die Bedienung beeinflussen: Licht, Lärm, Vibration, Temperatur, Handschuhe, freie Hände, Netzabdeckung? Fehlt der Bestandteil ganz, ist das ein Hinweis darauf, dass die Erhebung im Meetingraum stattfand.

• Sind soziale Bedingungen genannt: wer anwesend ist, wer unterbricht, wer zuschaut, wer mitentscheidet? Diese Angaben stehen in keiner Systembeschreibung.

• Sind organisatorische Bedingungen genannt: Schichtbetrieb, Freigaberegeln, Dokumentationspflichten, Haftung? Sie stehen in Arbeitsanweisungen und Betriebsvereinbarungen, die selten zu den Projektdokumenten gehören.

Das Ergebnis der Prüfung

Nach der Sitzung liegt je Frage eine Markierung vor. Die offenen und teilweise beantworteten Fragen bilden die Lückenliste. Sie ist der Erhebungsplan für die nächste Feldphase: je Lücke der Bestandteil, die Nutzergruppe und die Methode, mit der sich die Angabe erheben lässt. Meist ist das eine Beobachtung am Arbeitsplatz oder ein Kontextinterview, also ein Gespräch am Arbeitsplatz, während die Person arbeitet. Die beantworteten Fragen gehen mit dem Verweis auf das Quelldokument in die erste Fassung der Kontextbeschreibung. Ob diese Angaben erhoben oder geschätzt sind, prüfen Sie im zweiten Schritt.

Was ohne diese Prüfung fehlt

Wer Nutzungsanforderungen aus Dokumenten ableitet, die auf Vollständigkeit nicht geprüft wurden, übernimmt deren Lücken. Eine fehlende Nutzergruppe erzeugt keine Anforderungen, und das System ist für sie nicht gemacht. Eine fehlende Fehlerfolge lässt die Priorisierung ohne Grundlage. Ein fehlender Ort lässt eine Anforderung gelten, die am Einsatzort etwas anderes bedeutet. In unseren Projekten werden solche Lücken sonst in der Evaluation sichtbar, als Befunde, die niemand zuordnen kann, oder nach dem Release, als Umgehungen der Nutzenden. Die Prüfliste verschiebt diese Entdeckung an den Anfang, wo die Erhebung noch möglich ist und die Anforderungen noch nicht geschrieben sind.