Geis / Polkehn | Praxiswissen User Requirements | E-Book | sack.de
E-Book

E-Book, Deutsch, 220 Seiten

Geis / Polkehn Praxiswissen User Requirements

Nutzungsqualität systematisch, nachhaltig und agil in die Produktentwicklung integrieren. Aus- und Weiterbildung zum UXQB® Certified Professional for Usability and User Experience – Advanced Level "User Requirements Engineering"

E-Book, Deutsch, 220 Seiten

ISBN: 978-3-96088-588-7
Verlag: dpunkt
Format: EPUB
Kopierschutz: Wasserzeichen (»Systemvoraussetzungen)



User Requirements Engineering schlägt die Brücke zwischen Human-centred Design (HCD) und Requirements Engineering. Es verbindet User-Research-Methoden mit Theorie und Methoden der Anforderungsanalyse, um den Fokus auf die eigentlichen Nutzer eines Systems zu setzen.
Das Buch vermittelt Wissen über die Grundlagen und deren praktische Anwendung für die Herleitung und Strukturierung von Nutzungsanforderungen. Nach einer fundierten Einführung in die Nutzungskontextanalyse erläutern die Autoren wesentliche Begriffe sowie Methoden von User Research und User Requirements Engineering. Detailliert wird beschrieben, wie Benutzergruppenprofile erstellt, Nutzungskontextinformationen erhoben und dokumentiert, Erfordernisse aus Nutzungskontextbeschreibungen extrahiert und Nutzungsanforderungen spezifiziert, strukturiert und priorisiert werden.
Der Leser gewinnt ein tiefes Verständnis für Human-centred Design und wie die Nutzungsqualität interaktiver Systeme bereits zu Projektbeginn berücksichtigt werden kann.
Dieses Buch eignet sich nicht nur als Vorbereitung auf die Zertifizierung CPUX-UR, sondern auch als kompaktes Basiswerk zum Thema "User Requirements" in der Praxis und an Hochschulen.
Geis / Polkehn Praxiswissen User Requirements jetzt bestellen!

Autoren/Hrsg.


Weitere Infos & Material


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...


Thomas Geis ist Geschäftsführer der ProContext Consulting GmbH und seit 25 Jahren Vollzeit im Arbeitsgebiet Usability- Engineering tätig. Er ist Vorsitzender des International Usability and User Experience Qualification Board (UXQB) und Gründer des Arbeitskreises Qualitätsstandards des deutschen Berufsver-bands der Usability und User Experience Professionals (German UPA), Leiter des ISO-Ausschusses "Common Industry Format for Usability", Editor von ISO 9241-110 "Grundsätze der Dialogge-staltung" und von ISO 25060 "Common Industry Format (CIF) for Usability – General Framework for Usability-related Information", Leiter des DIN-Ausschusses "Benutzungsschnittstellen" sowie Träger des Usability Achievement Award der German UPA (2013).
Knut Polkehn ist seit vielen Jahren als Partner, Berater und Pro-jektleiter bei artop – Institut an der Humboldt-Universität zu Ber-lin tätig. Zu seinen Aufgabenbereichen gehören Kundenprojekte zu Analyse, Design und Evaluation interaktiver Systeme sowie die Weiterbildung von Usability Professionals. Als systemischer Kom-plementärberater bildet die Begleitung von Veränderungspro-zessen durch Training, Mentoring, Moderation sowie verschie-dene Formen von Fach- und Prozessberatung insbesondere hinsichtlich des Etablierens von Human-centred Design-Aktivitä-ten in Organisationen einen weiteren Schwerpunkt seiner Tätig-keit. Er bringt seine Expertise in Arbeitskreisen der German UPA sowie im Vorstand des UXQB e.V. ein und ist Co-Editor für das Curriculum CPUX-UR.


Ihre Fragen, Wünsche oder Anmerkungen
Vorname*
Nachname*
Ihre E-Mail-Adresse*
Kundennr.
Ihre Nachricht*
Lediglich mit * gekennzeichnete Felder sind Pflichtfelder.
Wenn Sie die im Kontaktformular eingegebenen Daten durch Klick auf den nachfolgenden Button übersenden, erklären Sie sich damit einverstanden, dass wir Ihr Angaben für die Beantwortung Ihrer Anfrage verwenden. Selbstverständlich werden Ihre Daten vertraulich behandelt und nicht an Dritte weitergegeben. Sie können der Verwendung Ihrer Daten jederzeit widersprechen. Das Datenhandling bei Sack Fachmedien erklären wir Ihnen in unserer Datenschutzerklärung.