UsabilityEngineering 1 - TU Dresden...Mockups • Nichtfunktionale Prototypen – Enthalten...
Transcript of UsabilityEngineering 1 - TU Dresden...Mockups • Nichtfunktionale Prototypen – Enthalten...
Elektrotechnik und Informationstechnik Institut für Automatisierungstechnik, Professur für Prozessleittechnik
Usability Engineering 1 Grundlagen Requirements Engineering Grundlagen Requirements Engineering und Usability Engineering
VL MMS Wintersemester 2013/14Professur für Prozessleittechnik
L. Urbas; J. Ziegler
Ziele und Inhalt
• Requirements Engineering
– Übersicht
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 2
– Arten und Sichten von Anforderungen
– Methoden der Anforderungsermittlung und –analyse
• Usability Engineering
– Motivation und Definition
– Formaler Rahmen
– Konzepte und Vorgehensmodelle
– Methodenbaukasten
REQUIREMENTSENGINEERING
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 3
Anforderungsermittlung und Analyse
Vision
Business Case
ZIELE
Kontext
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 4
Risiken
Anforderungs-spezifikation
Nach: Ebert, Christoph (2010): Systematisches Requirements Engineering.
Marktanforderungen
Funktionale Anforderungen
Qualitäts-anforderungen
Randbedingungen
Produkt-anforderungen
QAFARB
Komponenten-anforderungen
QAFARB
Sichten auf Anforderungen
• Vision und Business Case
– Was wird das Produkt verändern? Warum ist das wichtig?
– Wer wird wie vom Produkt profitieren?
TU Dresden Folie 5
– Wer wird wie vom Produkt profitieren?
– Wie wird mit dem Produkt Wert geschöpft?
– Welche Aufwände und Risiken sind zulässig?
• Marktanforderungen
– Beschreiben Anforderungen an das Produkt aus Sicht des Kunden
– Problemorientiert (WARUM?)
– Beschreiben tatsächlich zu befriedigende Bedürfnisse (keine Wünsche), für die der Kunde bereit ist zu investieren
– Sind Bestandteil von Verträgen etc. und dienen als Maßstab für den Erfolg
MMST © Urbas, Ziegler 2006-2013
Sichten auf Anforderungen
• Produktanforderungen
– Beschreiben Anforderungen an das Produkt aus Sicht der Realisierung einer späteren Lösung
TU Dresden Folie 6
– Lösungsorientiert (WAS?)
– Bilden die Arbeitsgrundlage für den Entwickler
• Komponentenanforderungen
– Beschreiben Anforderungen an eine Komponente des Produkts
– Lösungsorientiert (WIE?)
– Beschreiben aus Sicht der Realisierung und späteren Lösung, wie Produktanforderungen durch diese Komponente adressiert werden
– Dienen der rekursiven Verfeinerung der Produktanforderungen
MMST © Urbas, Ziegler 2006-2013
Arten von Anforderungen
• Funktionale Anforderungen
– Beschreiben vom System oder einer Komponente bereitzustellende Funktionen (funktionsorientiert)
TU Dresden Folie 7
– Abbildung von Eingangsparametern auf Ausgangsparameter
• Qualitätsanforderungen
– Beschreiben qualitative Eigenschaften des Systems oder einzelner Funktionen, also die Güte der bereitgestellten Funktionen
• Randbedingungen
– Beschreiben organisatorische oder technische Anforderungen, die die Realisierung des Systems oder einer Komponente einschränken
– Häufig Bedürfnisse, Verpflichtungen oder Einschränkungen in den Geschäftsprozessen auf Lieferanten-/Kundenseite
MMST © Urbas, Ziegler 2006-2013
Arten von Anforderungen
Anforderungen
TU Dresden Folie 8MMST © Urbas, Ziegler 2006-2013
Nach Ebert, Christoph (2010): Systematisches Requirements Engineering.
Funktionale Anforderungen
Qualitäts-anforderungen
Randbedingungen
•Kosten•Marktanalyse•Prozesse•Infrastruktur•Vertrieb und Verteilung•Organisation•Dokumentation
Externe Sicht
•Benutzungs-schnittstelle•Anwendungsfälle•Dienstleistungen
Interne Sicht
•Architektur•Lastbalancierung•Stromversorgung
Externe Sicht
•Performanz•Sicherheit•Benutzbarkeit
Interne Sicht
•Testbarkeit•Wartbarkeit•Portierbarkeit
Sichten und Arten im Zusammenhang
Vision
Markt-
Geschäfts-ziele
Qualitätsziele
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 9
Teststrategie
anforderungen
Produkt- und Komponenten-anforderungen
Anforderungs-spezifikation
Einschränkungen
Qualitäts-anforderungen
Funktionale Anforderungen
Anforderungs-beschreibung
Nach: Ebert, Christoph (2010): Systematisches Requirements Engineering.
Requirements Engineering Process
• Systematische Ermittlung, Analyse und Abstimmung von Anforderungen
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 10
Quelle: Ebert, Christoph (2010): Systematisches Requirements Engineering.
Requirements Engineering Methoden
Dir
ekth
eit
Offene Beobachtung
Begleitende Beobachtung
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 11
Formalisierung
User Survey
Verdeckte Beobachtung
Offene Beobachtung
Fernbeobachtung Contextual Inquiry
Focus Groups
Analytische Methoden
Interview
Beobachtung
• Verdeckte Beobachtung
– Nutzer (vorher) wird nicht aufgeklärt
• Offene Beobachtung
TU Dresden Folie 12
• Offene Beobachtung
– Nutzer wird aufgeklärt, es besteht aber kein Kontakt
• Begleitende Beobachtung
– Nutzer wird direkt begleitet und ggf. zu seinem Verhalten befragt
Unmittelbare, ganzheitliche, tiefe, unabhängige Methode
Invasivität stark abhängig von Art und Durchführung
Beschränkt auf die Leistungsfähigkeit und Wahrnehmungsfähigkeit des Beobachters
Sehr hoher Aufwand
MMST © Urbas, Ziegler 2006-2013
Interview
• Befragung, bei der eine Person (Respondent) um Auskunft durch eine interviewende Person gebeten wird
• persönlich oder telefonisch, mit Fragebogen oder PC, ggf. online
TU Dresden Folie 13
• persönlich oder telefonisch, mit Fragebogen oder PC, ggf. online
Mittelbare, direkte, fokussierte und abhängige Methode
Sehr zielgerichtete Erfassung von relevanter Information möglich
Verzerrungen durch Interviewer- Respondent Situation möglich
MMST © Urbas, Ziegler 2006-2013
Contextual Inquiry
• strukturierte Feldbefragungsmethode
– Mischung aus Interview und Beobachtung
– Interview-Ziel ist vorher klar festgelegt
TU Dresden Folie 14
– Interview-Ziel ist vorher klar festgelegt
– Findet im realen Arbeitsumfeld des Nutzers statt
Interview soll seinen experimentellen Charakter verlieren
– Häufig ergänzt durch Post-Task Reviews
Unmittelbare, ganzheitliche, tiefe, abhängige Methode
Ziel: Informationen über die Ziele der Anwender, ihre Aufgaben und das Arbeitsumfeld gewinnen
MMST © Urbas, Ziegler 2006-2013
Fokusgruppen
• Gruppendiskussion, bei der unter Leitung und Aufsicht eines Moderators ein bestimmtes Thema oder ein bestimmter Themenkomplex behandelt wird
TU Dresden Folie 15
• ca. 6 bis 12 Personen mit sorgfältig gewählter Zusammensetzung
– Fachliche, soziale und Persönlichkeitsmerkmale beachten!
– Leitung durch einen Moderator, ggf. Überwachung durch Supervisor
– Themat. Schwerpunkt wir zu Beginn durch einen Stimulus bestimmt (Idee, Stories oder Prototyp)
– Dauer ca. 1,5 bis 2 Stunden, Aufzeichnung eines Transkripts
Qualitative, aufwandsarme, direkte, mittelbare Methode
Entwicklung von Hypothesen zu Motiven, Einstellungen, Annahmen, Wünschen bzgl. Ideen oder Prototypen
MMST © Urbas, Ziegler 2006-2013
Ergebnisse der Anforderungsermittlung
Requirements
Scenario
TU Dresden Folie 16
Workflows
Requirements
Use Cases
Business Processes
Mockups
Personas User Stories
With kind permission of Tobias Münch, SAP 2011
Persona
• Fiktiver Nutzer einer bestimmten Nutzer-gruppe innerhalb des Anwendungsfalls
• Beschrieben durch ein detailliertes Profil, das Eigenschaften, Verhalten und Ziele dieses Nutzers, enthält:
TU Dresden Folie 17
• Beschrieben durch ein detailliertes Profil, das Eigenschaften, Verhalten und Ziele dieses Nutzers, enthält:
– Name, Alter, Geschlecht, Bild– Beschreibung physischer und psychischer Eigenschaften– Bildung, Ausbildung, Erfahrung, Fähigkeiten, Fertigkeiten– Hobbies, Interessen, Vorlieben, Abneigungen– Erwartungen, Annahmen, Gewohnheiten– Ggf. private und berufliche Ziele
Liefert ein konsistentes, umfassendes und damit vorstellbares Bild eines menschlichen Nutzers
3 -10 Personas pro Anwendungsfall
Mindestens 1 Persona mit negativer Einstellung zum Produkt
With kind permission of Tobias Münch, SAP 2011
User Story (Scenario)
• „As-Is“ User Story
– Realistisches, relevantes Szenario, das heute existiert
– Beschreibt, was der Nutzer tun soll und wo dabei Probleme auftreten
TU Dresden Folie 18
– Beschreibt, was der Nutzer tun soll und wo dabei Probleme auftreten
– Beschreibt Werkzeuge und deren Grenzen
– Identifiziert sämtliche Beteiligte und deren Rolle (häufig als Personas)
– Wird unterstützt durch fiktive, anonymisierte Datenbestände
• „To-Be“ User Story (Vision)
– Szenario, wie es aussehen soll
– Hebt die Probleme und deren Lösung hervor
– Zeigt den Mehrwert der Lösung
– Beschreibt Methoden, Prozesse, Produkte oder auch nur Konzepte
With kind permission of Tobias Münch, SAP 2011
Entwicklung von User Stories
1. Initialzustand beschreiben
– Vor- und Randbed., Nutzerinteraktionen, Datenwerte, Initialisierungen…
2. Regulären Ablauf beschreiben („sunshine scenario“)
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 19
2. Regulären Ablauf beschreiben („sunshine scenario“)
3. Schnittstellen zu parallelen Szenarien beschreiben
4. Irreguläre Abläufe ergänzen
– Mit Verzweigungspunkt und Auslöser
5. Endzustand für jede Verzweigung beschreiben
– Nachbedingungen, geänderte Daten, Ausgaben, Endzustände
– Folgen
Beispiele für User Stories• Nicht zwangsläufig als Zeitachse
oder sequenziell
• Problem- oder lösungsorientiert
• Max. 1 -1,5 Seiten je Story
TU Dresden Folie 20With kind permission of Tobias Münch, SAP 2011
Mockups
• Nichtfunktionale Prototypen
– Enthalten keinerlei Business-Logik
– Statische Navigationslogik und Dialoge
TU Dresden Folie 21
– Statische Navigationslogik und Dialoge
– Häufig beabsichtigt unfertiges Aussehen
Erweitern das Verständnis von User Stories
Erleichtern das kollaborative Ermitteln von Anforderungen
Beschleunigen die Entwicklung von Navigationslogik und Dialogen
With kind permission of Tobias Münch, SAP 2011
Workflows
• Detaillierte Ablaufbeschreibungen innerhalb einer User Story
– Streng sequenziell und rein exemplarisch
• Detaillierte Beschreibung der erwarteten Ergebnisse und des
TU Dresden Folie 22
• Detaillierte Beschreibung der erwarteten Ergebnisse und des Systemverhaltens
– Vertieft die User Story
With kind permission of Tobias Münch, SAP 2011
Use Case: Plant Monitoring1. The operator checks in at the production facility2. He takes his iPad and opens the facility monitoring app3. He dircectly goes to the ‚Plant Overview‘ tab to open the plant view4. He checks all main indicators for a redlight5. The water pump for the welding robot shows a warning by a small
yellow icon due to increased vibration and energy consumption6. He opens the details view to get more details7. ...
Business Processes
• Folge von Einzeltätigkeiten, die schrittweise ausgeführt werden, um ein geschäftliches oder betriebliches Ziel zu erreichen
Teil der betrieblichen Ablauforganisation
TU Dresden Folie 23
– Generalisiert, wird mehrfach durchlaufen
– Kann hierarchisiert sein
• Erläutert Fluss und Transformation von Material, Informationen, Operationen und Entscheidungen [Osterloh, Frost 1998]
– Genau definierte Ein- und Ausgänge (Informationen, Gegenstände, Ereignisse und/oder Zustände)
With kind permission of Tobias Münch, SAP 2011
Ableitung von Anforderungen
• Objektorientierte Analyse
– Entwicklung von Use Case-, Komponenten-, Ablaufdiagrammen etc.
– Modelle (häufig in UML-/SysML-Notation) zur Dokumentation
TU Dresden Folie 24
– Modelle (häufig in UML-/SysML-Notation) zur Dokumentation
• Volere Requirements Specification
– Sammlung von Werkzeugen zur Anforderungsanalyse
– Requirements Process als formaler Analyseprozess
– Volere Requirements Specification Templates (VRST) zur Dokumentation
• Entwicklung einer Anforderungsspezifikation oder eines Pflichtenhefts
– Software Requirements Specification nach ANSI/IEEE Std 1233-1998
– Pflichtenheft nach DIN 69901-2009
MMST © Urbas, Ziegler 2006-2013
Dokumentation von Anforderungen
Volere Snowcards
TU Dresden Folie 25MMST © Urbas, Ziegler 2006-2013
IEEE-830 Requirements Specification Template
SysML Requirements Diagram
Dokumentation nach IEEE Std. 830
• Klare Trennung zwischen Markt-, Produkt- und Komponentenanforderungen
TU Dresden Folie 26
• Klare Trennung zwischen funktionalen Anforderungen, Qualitätsanforderungen und Randbedingungen
Standard schlägt verschiedene Strukturen vor
With kind permission of Tobias Münch, SAP 2011
Beschreibung von Anforderungen
TU Dresden Folie 27MMST © Urbas, Ziegler 2006-2013
Quelle: Ebert, Christoph (2010): Systematisches Requirements Engineering.
USABILITY ENGINEERING
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 28
Warum Usability Engineering?
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 29
Warum Usability Engineering?
• Der Benutzer
– ist nicht wie ich
– arbeitet und denkt nicht wie ich
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 30
– arbeitet und denkt nicht wie ich
– weiß, kennt und erwartet andere Dinge als ich.
Systematische Einbeziehung der Benutzersicht in den Entwicklungsprozess eines Produkts notwendig!
Perspektivenübernahme:
– Erfassen, Bewerten und Verstehen einer bestimmten Begebenheit aus der Sicht eines anderen.
Was ist Usability Engineering?
• Usability = Gebrauchstauglichkeit
• Engineering = Gestaltung, Entwurf, Realisierung
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 31
• Engineering = Gestaltung, Entwurf, Realisierung
Usability Engineering:
– Methoden zur Verbesserung von Gebrauchstauglichkeit
– Methoden zur Vermeidung von Fehlern in Bezug auf Gebrauchstauglichkeit
– systematische Einbeziehung von Benutzern
Nutzerzentrierter Entwurf (User-Centered Design)
Prinzipien des Usability Engineering
1. Frühzeitiger und kontinuierlicher Fokus auf Nutzer und Aufgabe
2. Empirische Messungen mit Nutzern
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 32
2. Empirische Messungen mit Nutzern
3. Iteratives und integriertes Design [nach Gould & Lewis, 1985]
Prozessmodelle des Software-Engineering
• umfassen prinzipiell folgende Tätigkeiten:
– Anforderungsermittlung und Planung
– Entwicklung (meist unterteilt in Grob- und Feinentwurf)
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 33
– Entwicklung (meist unterteilt in Grob- und Feinentwurf)
– Realisierung
– Test, Inbetriebnahme und Auslieferung
– Betrieb und Instandhaltung
Prozessmodell:
– Aufteilung der Gesamtaktivität in Arbeitseinheiten
– Festlegung definierter Arbeitsabläufe, Tätigkeiten und Methoden
– Spezifikation der zu erbringenden (Zwischen-)Resultate
Beispiele:
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 34
www.techsphere.de www.softwebsolutions.com
Prozessmodelle des Usability-Engineering
• umfassen prinzipiell folgende Tätigkeiten:
– Verstehen und Festlegen des Nutzungskontext
– Festlegen der Nutzungsanforderungen
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 35
– Festlegen der Nutzungsanforderungen
– Erarbeiten von Gestaltungslösungen
– Evaluation
• sind in der Regel
– iterativ
– kriterienbasiert
– nutzerzentriert
Beispiel: Benutzerorientierter Entwicklungszyklus nach ISO 9241-210
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 36
DIN EN ISO 9241-210 (2010) Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme
Nebenläufigkeit von Usability-Engineering und Software-Engineering
Usability- Engineering Entwicklungsphase Software Engineering
Nutzer- und Aufgabenanalyse
Anforderungs-analyse
Anwendungsgestaltung
Mensch oder Maschine
Anforderungs-
Hardware oder Software
TU Dresden Folie 37MMST © Urbas, Ziegler 2006-2013
(nach Curtis and Hefley 1994)
Mensch oder Maschine
Anforderungs-zuordnung
Hardware oder Software
Dialoggestaltung Konzeptphase Architekturentwurf
Anzeigegestaltung Entwurfsphase Logischer Entwurf
Programmierung
Realisierungs-phase
Programmierung
Usability lab Komponententest Unit und Integration testing
Contextual observation Systemtest Systemtest
menschliche Leistungsfähigkeit
Optimierung Leistungsfähigkeit der Maschine
The Usability Engineering LifeCycle
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 38
Nach: Mayhew, D. (1999) The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design
Scenario Based Usability Engineering
Analyse der Interessen-gruppen,
Feldstudien
Aktuelle Praxis
Problem-szenarien
Analysieren
Entwerfen
Weiterführende Veranstaltungen: Institut für Software- und Multimediatechnik
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 39
Nach: Rosson, M. B., Carroll, J. M. (2001) Usability Engineering
Aktivitätsszenarien
Informationsszenarien
Interaktionsszenarien
Metaphern, Informations-technologie, MMI-Theorie, Richtlinien
Iterative Analyse der
Anforderungen an
Gebrauchs-tauglichkeit,
Redesign
SummativeEvaluation
Formative Evaluation
Spezifikation d.
Gebrauchs-tauglichkeit
Entwerfen
Fertigen und Evaluieren
Parallel SE and UI Development Process
Nach: Leventhal, L., & Barnes, J.
Problem Analysis
System Design ImplementationSystem Testing
ProceduralDesign
ArchitecturalDesign
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 40
Nach: Leventhal, L., & Barnes, J. (2007). Usability engineering: Process, products and examples.
RequirementsAnalysis
Design, Implementation, Testing Installation
Task Analysis Implementation User Testing
Design
Design ofInteraction
User Interface Design
Design
Design of Interface
Kritik am nutzerzentrierten Entwurf
• Ziel: Entwicklung eines hinsichtlich der spezifizierten Ziele optimalen Systems
• ABER: Der Benutzer
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 41
• ABER: Der Benutzer
– kann sich irren
– kann sich Neuerungen verweigern oder widersetzen
– ist beschränkt auf seinen Erfahrungshorizont und sein technisches und gestalterisches Verständnis
Nicht zwingend das System, welches der Nutzer wünscht!
Nicht zwingend ein System, welches erfolgreich ist!
Methodenbaukasten
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 42
(nach www.usabilitynet.org, Barnum and others )
Zusammenfassung
• Requirements Engineering
– Ermittlung von Anforderungen durch nutzerzentrierte Methoden
– Dokumentation mithilfe von Use Cases, Personas, User Stories,
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 43
– Dokumentation mithilfe von Use Cases, Personas, User Stories, Business Processes und Workflows
– Analyse und Spezifikation z.B. durch OOA, Volere, IEEE Std. 830 oder DIN 69901
• Usability Engineering
– Stellt den Benutzer in den Mittelpunkt des Entwurfs
– Verbessert systematisch GT und vermeidet Design-Fehler
– Ist in viele Entwicklungsprozesse integrierbar
– Stellt einen umfangreichen Methodenbaukasten bereit
Literatur
• Norman, Donald A. (1986): User Centred System Design: New Perspectives on Human/Computer Interaction. Lawrence Erlbaum Associates Inc.
• Nielsen, Jakob (1993): Usability Engineering. Morgan Kaufmann.
• Mayhew, Deborah J. (1999): The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design. Morgan Kaufmann.
• Rosson, Mary B.; Carroll, John M. (2001): Usability Engineering: Scenario-Based Development of Human-Computer Interaction. Morgan Kaufmann.
• Leventhal, Laura; Barnes July (2008): Usability Engineering: Process, Products and Examples. Pearson Prentice Hall.
• Barnum, Carol M. (2010): Usability Testing Essentials: Ready, Set … Test! Morgan Kaufmann.
• Ebert, Christoph (2010): Systematisches Requirements Engineering. Dpunkt Verlag.
• Sarodnick, Florian; Brau, Henning (2. Aufl., 2011): Methoden der UsabilityEvaluation: Wissenschaftliche Grundlagen und praktische Anwendung. Huber Verlag.
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 44
Online-Quellen
• http://www.cheval-lab.ch/cheval-wissensbasis
• http://usability.gov
• http://www.usabilitynet.org• http://www.usabilitynet.org
• http://www.sdi-research.at
• http://www.berlin-usability.de/de/usability.html
TU Dresden MMST © Urbas, Ziegler 2006-2013 Folie 45