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

Anforderungsermittlung und Analyse

Vision

Business Case

Kontext

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

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

Arten von Anforderungen

Anforderungen

TU Dresden Folie 8MMST © Urbas, Ziegler 2006-2013

Nach Ebert, Christoph (2010): Systematisches Requirements Engineering.

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

Teststrategie

anforderungen

Produkt- und Komponenten-anforderungen

Anforderungs-spezifikation

Einschränkungen

Anforderungs-beschreibung

Nach: Ebert, Christoph (2010): Systematisches Requirements Engineering.

Requirements Engineering Process

• Systematische Ermittlung, Analyse und Abstimmung von Anforderungen

Quelle: Ebert, Christoph (2010): Systematisches Requirements Engineering.

Requirements Engineering Methoden

Offene Beobachtung

Begleitende Beobachtung

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

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

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

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

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

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

Entwicklung von User Stories

1. Initialzustand beschreiben

– Vor- und Randbed., Nutzerinteraktionen, Datenwerte, Initialisierungen…

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

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

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)

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

Dokumentation von Anforderungen

Volere Snowcards

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

Beschreibung von Anforderungen

Quelle: Ebert, Christoph (2010): Systematisches Requirements Engineering.

USABILITY ENGINEERING

Warum Usability Engineering?

• Der Benutzer

– ist nicht wie ich

– 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

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

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)

– 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:

www.techsphere.de www.softwebsolutions.com

Prozessmodelle des Usability-Engineering

• umfassen prinzipiell folgende Tätigkeiten:

– Verstehen und Festlegen des Nutzungskontext

– Festlegen der Nutzungsanforderungen

– Erarbeiten von Gestaltungslösungen

– Evaluation

• sind in der Regel

– iterativ

– kriterienbasiert

– nutzerzentriert

Beispiel: Benutzerorientierter Entwicklungszyklus nach ISO 9241-210

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

(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

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

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

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

– 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

(nach www.usabilitynet.org, Barnum and others )

Zusammenfassung

• Requirements Engineering

– Ermittlung von Anforderungen durch nutzerzentrierte Methoden

– Dokumentation mithilfe von Use Cases, Personas, User Stories,

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

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

UsabilityEngineering 1 - TU Dresden...Mockups • Nichtfunktionale Prototypen – Enthalten...

Documents

Umweltpolitik - TU Dresden

Introduction to Mathematical Logic - TU Dresden

into the participants list - TU Dresden

EXERCISE: GETTING STARTED - TU Dresden

Stefan Kaskel, TU Dresden, Germany

Michael Soffel & Sergei Klioner TU Dresden

23. Graphen in Java - TU Dresden

Foundations for Machine Learning - TU Dresden

Festschrift - TU Dresden

TRUSTED COMPUTING - TU Dresden

Welcome at TU Dresden

Chair of Communication Acoustics, TU Dresden Dresden, Germany · 2014. 8. 31. · TU Dresden Dresden, Germany sebastian.merchel@tu-dresden.de ABSTRACT In this paper, the development

2. Types of structures - TU Dresden

TUM Citation Guide - TU Dresden

Bridge Loads - TU Dresden

VBIC 1.20 Benchmarking - TU Dresden

Routing on Roles - TU Dresden

var - TU Dresden

Scalable parameter extraction methodologies ... - TU Dresden

12) Enterprise Java Beans - TU Dresden