Praxiswissen User Requirements

2Was sind User Requirements?

User Requirements werden im Deutschen sehr zutreffend als Nutzungsanforderungen (Anforderungen an die Nutzung) bezeichnet. Im Englischen wird der Begriff User Requirement eher unspezifisch verwendet im Sinne von »alles, was vom Benutzer gefordert wird« oder »alle Projektdaten, die in Bezug zu den Benutzern des zu entwickelnden interaktiven Systems stehen«. Im User Requirements Engineering geht es also nicht um unspezifische Forderungen, sondern um das Erarbeiten, Dokumentieren und Priorisieren von konkreten Anforderungen an die Nutzung eines interaktiven Systems.

Zunehmend wird in Projekten verstanden, dass derartige Nutzungsanforderungen die Basis für die Entwicklung der Benutzungsschnittstelle1 des interaktiven Systems sind. Nutzungsanforderungen lassen sich genauso präzise spezifizieren wie Systemanforderungen. Sie beschreiben aus der Perspektive des Benutzers, was am System konkret ermöglicht werden muss, ohne eine spezifische Lösung vorzuschreiben.

Grundsätzlich lässt sich unterscheiden zwischen

• qualitativen Nutzungsanforderungen und
• quantitativen Nutzungsanforderungen.

Qualitative Nutzungsanforderungen beschreiben, »was Benutzer während der Durchführung einer Aufgabe mit dem interaktiven System finden, erkennen, verstehen, auswählen oder eingeben müssen«.

Die Definition des Begriffs qualitative Nutzungsanforderung geht auf Wolfgang Dzida [Dzida 2004] zurück, den Begründer der »Grundsätze der Dialoggestaltung«, der die Erkenntnis hatte, dass Menschen, die mit Produkten, Systemen oder Services interagieren, während der Interaktion nur Folgendes tun können:

• Informationen erkennen
• Auswahlen treffen
• Eingaben tätigen
• Erzeugte Arbeitsergebnisse ausgeben/weitergeben

Beispiel:

• Der Benutzer muss am Wecker erkennen können, wie lange er noch bis zum Wecken schlafen kann, während er im Dunkeln im Bett liegt.

Quantitative Nutzungsanforderungen dienen z.B. als Akzeptanzkriterien in Bezug auf Nutzungsqualität bei Evaluierungen mit Benutzern.

Quantitative Nutzungsanforderungen beschreiben ein »benötigtes Maß an Usability, um identifizierten Erfordernissen zu genügen im Sinne der Effektivität, Effizienz und Zufriedenstellung in einem festgelegten Nutzungskontext«.

Beispiel:

• 20 von 25 Benutzern des Weckers müssen das Wecksignal nach einer nächtlichen Schlafphase von 7 Stunden beim Ertönen als positiv wahrnehmen.

Nutzungsanforderungen »fallen nicht vom Himmel«. Die Tatsache, dass in Usability-Tests mit Benutzern häufig bestimmte Nutzungsanforderungen erstmalig erkannt werden, zeigt, dass ein systematischer Prozess zur Erhebung der Nutzungsanforderungen in Projekten der Produkt-, System- oder Serviceentwicklung unerlässlich ist, um Iterationen auf Basis durchgeführter Usability-Tests auf das notwendige Maß zu reduzieren.

Um im Einzelfall beurteilen zu können, ob eine im Entwicklungsprojekt vorliegende Aussage wirklich eine Nutzungsanforderung ist oder die Forderung nach einer konkreten Lösung für eine (nicht benannte) Nutzungsanforderung, muss zunächst der Unterschied zwischen Anforderung und Lösung geklärt werden. Um wiederum bei einer Anforderung zu verstehen, ob dies eine wirkliche Nutzungsanforderung oder eine andere Art Anforderung (z.B. eine Marktanforderung) ist, ist nicht nur die Einordnung von Nutzungsanforderungen innerhalb der Menge möglicher Anforderungen anderer Stakeholder (z.B. der Marketingabteilung) wichtig, sondern darüber hinaus die Unterscheidung von Stakeholder-Anforderungen und Systemanforderungen.

2.1Nutzungsanforderungen als eigene Anforderungskategorie innerhalb der Stakeholder-Anforderungen

2.1.1Wechselseitige Beziehung zwischen Nutzungsanforderungen und anderen Stakeholder-Anforderungen

Nutzungsanforderungen und andere Stakeholder-Anforderungen können sich gegenseitig bedingen. So kann z.B. eine organisatorische Anforderung eine indirekte Quelle für eine Nutzungsanforderung sein und umgekehrt.

Beispiel:

• In der Arztpraxis gibt es folgende organisatorische Anforderung: Die medizinische Fachangestellte muss am Ende eines Quartals alle Patienten identifizieren, die ohne Ankündigung zu vereinbarten Behandlungsterminen nicht erschienen sind.
• Das zugrunde liegende Erfordernis ist: Die medizinische Fachangestellte muss wissen, welche Patienten nicht zu einem vereinbarten Behandlungstermin erschienen sind, um diese als »versäumte Behandlungstermine« bei der Krankenkasse in Rechnung stellen zu können.
• Die hieraus resultierende Nutzungsanforderung lautet: Der Benutzer muss am System überblicken können, welche Behandlungstermine eines Quartals von Patienten versäumt wurden.

Umgekehrt kann eine Nutzungsanforderung eine indirekte Quelle für eine organisatorische Anforderung sein.

Beispiel:

• Eine Nutzungsanforderung an das interaktive System in der Arztpraxis kann lauten: Der Benutzer muss am System bei jedem Patienten erkennen können, welche Vorsorgeuntersuchungen für diesen Patienten von der Kasse bezahlt werden.
• Dass zugrunde liegende Erfordernis ist: Die medizinische Fachangestellte muss wissen, welche Patienten die passenden Merkmale haben, die sie für eine spezifische Vorsorgeuntersuchung qualifizieren, um gezielt Patienten eine solche Vorsorgeuntersuchung vorzuschlagen.
• Die hieraus resultierende organisatorische Anforderung lautet: Die medizinische Fachangestellte muss bei jedem Patienten alle spezifischen Patientenmerkmale erfragen, die den jeweiligen Patienten für eine spezifische Vorsorgeuntersuchung qualifizieren.

IT-Systeme haben in der Erfahrung der Autoren nicht den erwarteten Erfolg in der Nutzung, wenn organisatorische Anforderungen, die sich aus Nutzungsanforderungen ergeben, nicht umgesetzt werden. Dasselbe gilt für nicht umgesetzte Nutzungsanforderungen, die sich aus organisatorischen Anforderungen ergeben. Im Rahmen der Priorisierung von Nutzungsanforderungen (siehe Abschnitt 7.2) ist dies im Projektteam zu betrachten. Selbst wenn später im Lösungsraum nur ein Detail an der Benutzungsschnittstelle fehlt, kann die Zufriedenstellung der Nutzung des interaktiven Systems massiv reduziert sein. So führt das Nicht-Vorhandensein der Information »Boarding noch nicht begonnen« auf einer elektronischen Bordkarte zu Stress bei Fluggästen, die noch nicht die Sicherheitskontrolle am Flughafen passiert haben, nachdem die planmäßige Boardingzeit bereits begonnen hat.

2.1.2Quellen für qualitative Nutzungsanforderungen

Qualitative Nutzungsanforderungen haben

• direkte Quellen und
• indirekte Quellen.

Direkte Quellen sind immer ein oder mehrere Erfordernisse im Nutzungskontext.

Beispiel für eine Nutzungsanforderung:

• Der Benutzer muss am Terminmanagementsystem erkennen können, ob und um wie viele Minuten sich der Beginn eines anstehenden Behandlungstermins verzögert.

Zugrunde liegendes Erfordernis (direkte Quelle):

• Der Patient muss wissen, ob sich sein Behandlungstermin verzögert, um die verbleibende Zeit bis zum Beginn des Behandlungstermins sinnvoll nutzen zu können.

Indirekte Quellen für qualitative Nutzungsanforderungen sind:

• Benutzerbezogene Qualitätsziele (siehe hierzu Abschnitt 3.1.2)
• Gesetzliche/regulatorische Anforderungen
• Marktanforderungen
• Organisatorische Anforderungen
• Forderungen
• Identifizierte oder antizipierte Nutzungsprobleme
• Dialogprinzipien und Heuristiken (z.B. Erwartungskonformität, Fehlertoleranz), die bei der Spezifikation von qualitativen Nutzungsanforderungen herangezogen werden.

Grundsätzlich lässt sich bei jeder indirekten Quelle einer qualitativen Nutzungsanforderung Folgendes ermitteln:

• Was der relevante Nutzungskontext ist (z.B. Tablet als Bildschirmarbeitsplatz).
• Welches Erfordernis darin enthalten ist (z.B. der mobil Arbeitende muss wissen, welche Richtlinien an einem mobilen Arbeitsplatz eingehalten werden müssen, um keine Gesundheitsrisiken einzugehen).

Auf diese Weise kann bei jeder Nutzungsanforderung aus einer indirekten Quelle geklärt werden, was die konkrete Quelle der Nutzungsanforderung ist und aus welchen Erfordernissen diese Nutzungsanforderung abgeleitet wurde. Dieses Vorgehen bietet sich grundsätzlich immer an, insbesondere jedoch dann, wenn die Nutzungsanforderung unklar oder strittig ist.

2.1.3Quellen für quantitative...