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

ZIELE

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

Dir

ekth

eit

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“)


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?


Warum Usability Engineering?

• Der Benutzer

– ist nicht wie ich

– arbeitet und denkt 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


• 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


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)


– 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


– 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

http://mt.inf.tu-dresden.de/studium/lehre/ws_13-14/uie_13-14/

http://mt.inf.tu-dresden.de/studium/lehre/ws_13-14/uie_13-14/

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


• 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


Date post:	14-Jul-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

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

Documents