Ausgangslage

Ein Anforderungsdokument ohne Kontextbeschreibung funktioniert, solange alle Beteiligten denselben Kontext im Kopf haben. Das ist zu Beginn eines Projekts selten der Fall und wird mit jedem Personalwechsel seltener. Die Anforderung „Der Nutzende muss den Status des Auftrags erkennen können" bedeutet an einem Schreibtisch etwas anderes als in einer Werkhalle mit Handschuhen und wechselndem Licht. Steht der Kontext im Research-Bericht, wird er beim Schreiben der Anforderung noch mitgedacht, bei der Umsetzung seltener und bei der Abnahme gar nicht.

ISO 9241-210 nennt das Verstehen des Nutzungskontexts als erste Aktivität der menschzentrierten Gestaltung und als Grundlage der Nutzungsanforderungen. ISO 9241-11 definiert Gebrauchstauglichkeit ausdrücklich für einen bestimmten Nutzungskontext. Ohne ihn lassen sich Effektivität, Effizienz und Zufriedenstellung nicht messen, weil unklar bleibt, unter welchen Bedingungen gemessen wird.

Die vier Bestandteile im Dokument

Wir legen die Kontextbeschreibung als eigenen Abschnitt am Anfang des Anforderungsdokuments an, vor der ersten Anforderung. Der Abschnitt hat vier Teile.

Die Nutzergruppen: je Gruppe eine kurze Beschreibung mit Aufgabenbezug, Erfahrungsgrad, Häufigkeit der Nutzung und relevanten Einschränkungen. Demografische Angaben stehen nur, wenn sie eine Anforderung verändern.

Die Aufgaben: je Nutzergruppe die Aufgaben mit Ziel, Auslöser, Teilschritten, Häufigkeit und Folgen eines Fehlers. Aufgaben, die mehrere Gruppen gemeinsam ausführen, werden als solche markiert.

Die Arbeitsmittel: Geräte, Software, Formulare und andere Hilfsmittel, mit denen die Aufgabe heute erledigt wird. Dazu gehören die Umgehungen, die wir im Feld gesehen haben, etwa die Tabelle neben dem System.

Die Umgebung: physische Bedingungen wie Licht, Lärm, Platz und Bewegung, sowie soziale und organisatorische Bedingungen wie Zeitdruck, Unterbrechungen, Zuständigkeiten und Vorschriften.

Herkunft je Angabe

Jede Angabe im Kontextabschnitt bekommt eine Quelle: Beobachtung, Interviewaussage, Dokumentenanalyse oder Annahme. Das ist die Stelle, an der ein Review erkennt, ob die Beschreibung erhoben oder geschätzt wurde. Eine Kontextbeschreibung aus lauter Annahmen ist zulässig, wenn sie als solche gekennzeichnet ist. Sie ist dann ein Arbeitsstand, der in der nächsten Feldphase geprüft wird.

Der Bezug von der Anforderung zum Kontext

Jede Nutzungsanforderung verweist auf die Nutzergruppe und die Aufgabe, für die sie gilt. Aus „Der Nutzende muss den Status des Auftrags erkennen können" wird: „Die Monteurin (Nutzergruppe 2) muss bei der Aufgabe Auftragsannahme (A-4) den Status des Auftrags erkennen können, während sie steht und mit Handschuhen arbeitet." Der Nebensatz stammt aus der Umgebungsbeschreibung. Er verändert, was „erkennen können" bei der Abnahme heißt.

Der Verweis kann als Kennung in einer Spalte stehen. Wichtig ist, dass er in beide Richtungen funktioniert: von der Anforderung zum Kontext und vom Kontext zu allen Anforderungen, die für eine Gruppe oder eine Aufgabe gelten. Damit wird sichtbar, für welche Aufgabe noch keine Anforderung vorliegt.

Pflege im Projektverlauf

Der Nutzungskontext ändert sich, wenn ein Feld ausgeweitet wird, wenn eine neue Nutzergruppe hinzukommt oder wenn eine Beobachtung eine Annahme widerlegt. Der Abschnitt im Anforderungsdokument wird dann fortgeschrieben, mit Datum und Quelle der Änderung. Anforderungen, die auf dem geänderten Teil beruhen, werden markiert und im nächsten Refinement geprüft.

Wir empfehlen, den Kontextabschnitt in dem Werkzeug zu führen, in dem auch die Anforderungen stehen. Ein separates Dokument an anderer Stelle wird selten gepflegt und selten gelesen. Im Ticketsystem kann der Abschnitt als Wiki-Seite liegen, auf die Stories verweisen; in einem Anforderungsdokument des klassischen Vorgehens ist er ein eigenes Kapitel vor den Anforderungen, mit derselben Nummerierung, die auch die Anforderungen benutzen.

Grenzen

Eine Kontextbeschreibung ist eine Verdichtung. Sie nennt Bedingungen, die für die Nutzergruppe gelten, und lässt Einzelfälle weg. Welche Einzelfälle wegfallen, ist eine Entscheidung, die dokumentiert wird. Außerdem beschreibt sie den Kontext zum Zeitpunkt der Erhebung. Ein System, das eingeführt wird, verändert den Kontext, und die Beschreibung ist danach in Teilen überholt. Die Evaluation nach der Einführung prüft, welche Teile das sind.

Was danach vorliegt

Ein Anforderungsdokument mit Kontextabschnitt liefert dem Produktteam den Bezugsrahmen für Umsetzung und Abnahme. Für jede Anforderung ist klar, für wen sie gilt, bei welcher Aufgabe und unter welchen Bedingungen. Ein Usability-Test kann diese Bedingungen nachstellen. Eine Abnahme kann sich auf sie beziehen. Und ein neues Teammitglied findet im selben Dokument den Kontext, den die anderen im Kopf haben.