Voraussetzung Umfang des Projektes und Nutzersituation sind definiert in Form von: Konzept (Projektziel, Funktionen) Personas (Zielgruppe) Nutzungskontext (Technik, Umgebung, Zeitrahmen) Funktionen (Interessen / Funktionen / Nutzen)
Use cases Was sind use cases? Definition von Anforderungen und Zielsetzungen für ein zu entwickelndes Produkt - detaillierte Beschreibung der Interaktions-Abläufe - eingeführt von Ivar Jacobson et al. im Bereich objektorientierte Systementwicklung ("Object-Oriented Software Engineering (OOSE)" /Jacobson, 1992) - sieht vor, Anwendungsfälle ("") in Textform zu beschreiben.
Use cases - Nutzen Hilfe beim Abschätzen von Komplexität + Kosten durch Definition von Umfang und Zweck des zu erstellenden Systems Erfassen der funktionellen und inhaltlichen Anforderungen. Welche Abläufe sollen zu erst behandelt werden? Fortwährende Kontrolle der vereinbarten Zielsetzungen während des Entwicklungsprozesses effektives Mittel zur Verständigung unter den Projektbeteiligten. Minimieren des Risikos von Missverständnissen und auseinandergehenden Erwartungen Referenz für Testszenarien in UX-Test.
Use cases - Form Ausprägungen Bei Softwareentwicklern oft als Funktionsdiagramm sinnvoll erst später in Projekt-Entwicklung technisch-logische Strukturierung interner Systemabläufe Funktionsdiagramm: Speichern des Spiels
Use cases - Form im UX-Design Interaktionsabläufe in Textform beschreiben, am besten tabellarisch Beschreibung aus Sicht der Benutzer (nicht die inneren Abläufe des techn. Systems) Aufschlüsseln des Gesamtvorganges in einzelne Handlungsschritte Standardbeispiel: Vorgang Bargeld am Automaten beziehen (ATM):
Use cases - Form
Use cases - Tabelle Elemente Voraussetzungen >> vor Ablauf Use Case Szenarios erfüllt >> evtl. hat anderer Use Case diese Vorbedingung(en) eingerichtet. Trigger >> Auslöser des Use Case Szenarios aus >> oft erste Aktion des Standardablaufes Standardszenario >> Idealablauf ( happy path ) >> Ergebnis im Erfolgsfall Alternative Möglichkeiten >> Sondersituationen Mindestgarantie >> was erhält Primärakteur bei Nichterreichen des Interaktionszieles?
Use cases - Tabelle Ebenen Use Case Tabellen immer gleich strukturiert, jedoch mit unterschiedlicher Betrachtungsnähe (Ebene): Überblick Aktion Unteraktion Beispiel ATM im Detail:
Use cases - Tabelle ATM - Überlicksebene Was würde der UC beinhalten? Voraussetzungen welche? Trigger welcher? Standardszenario Einzelne Handlungsschritte werden wiederum in Unter-UseCases ausgelagert Alternative Möglichkeiten Sonderfälle? Mindestgarantie Was bleibt bei Misserfolg?
Use cases - Tabelle Beispiel ATM Use Case 2.0: Geld abheben Voraussetzungen Use Case 1.0 (Authentifizierung) erfolgreich >> kann über verschiedene Methoden erfolgen >> definiert in Use Case 1.0 Trigger Use Case 1.0 (Authentifizierung)
Use cases - Tabelle Beispiel ATM Use Case 2.0: Geld abheben Standardszenario - Auswahl des abzuhebenden Geldbetrages (Menüpunkte oder freier Betrag) (!) - überprüfen, ob (!) sich genügend Bargeld im Automaten befindet - Anfrage an die Bank (Datenverbindung) (!) - Bestätigung seitens der Bank erhalten (!) - Auszahlung der korrekten Summe - Archivierung des Vorgangs im System - Auf Wunsch (!) Ausdruck einer Quittung - Karte zurück geben (!) >> evtl. in Use Case 0.0 bereits erfasst
Use cases - Tabelle Beispiel ATM Use Case 2.0: Geld abheben Alternativen (!) - Auszahlung seitens Bank nicht genehmigt: >> Information an den Nutzer >> Abbruch des Vorgangs - Nutzer kann Vorgang jederzeit vor der Auszahlung abbrechen - Karte nicht lesbar >> falsch eingesteckt? >> defekt / ungültig? - Nicht ausreichend Geld im Automaten, um Anfrage zu bedienen etc. >> Information an den Nutzer >> evtl. Vorschlag eine geringere Summe zu wählen
Use cases - Tabelle Beispiel ATM Use Case 2.0: Geld abheben Mindestgarantie - Karte zurück geben - Keine Kontobewegung bzw. keine Gebührenberechnung
Use cases - Inhalt Funktionale Anforderungen an ein System aus Sicht von externen Bedienern ("Aktoren"). Beschreiben von Anwendungsfällen (). Spezifizierung von - Voraussetzungen (zur Ausführung des ) - auslösender Impuls - Interaktionsablauf - Ergebnis im Erfolgsfall - Ergebnis bei Abweichungen vom happy path, ggf. Weiterverzweigungen zu anderen Nur die Aktionen bzw. Ereignisse zu spezifizieren, die aus der Sicht der Bedienungseinheit erkennbar sind! (Nicht aber Details, die beschreiben, wie das System intern arbeiten soll.)
Use cases - Beispiel Beispiel einer gelungenen Tabelle Aqualogic - Steuerung Kläranlage Master IMS 2011
Use cases - Beispiel Aqualogic - Steuerung Kläranlage Master IMS 2011
Nummerierung + Titel: Nummerierung kennzeichnet Hierarchie der. Titel benennt den Vorgang
Datum + Version: Der Übersichtlichkeit halber empfohlen!
Akteur: Nur notwendig bei wechselnden Akteuren, bzw. auf Überblicksebene
Ebene: Überblick, Aktion, Unteraktion... Korrespondiert mit Nummerierung
Voraussetzung: Trigger-Aktion; bzw. vorher abgelaufene UCs
Erfolgsfall: Ziel der Interaktion auf dieser Ebene Mindestgarantie bei Misserfolg
Standardszenario: Idealablauf schrittweise durchnummeriert Einzelschritte können bei Bedarf als UCs (Ebene Unteraktion) im Detail separat beschrieben werden
Erweiterungen: Abweichungen vom Happy Path Sondersituationen (User bricht ab, Vorgang misslingt an einer Stelle etc.)
Use cases - Beispiel Problematische Lösung (IA6 / 2009) Alles auf einer Seite
xioscreen: Verbindung über WLAN aufbauen und mit Screen interagieren Aufbereitung: Einteilung und Kategorien prinzipiell gut, allerdings zu eng gelistet >> kaum Platz für Behandlung der Ausnahmefälle (Erweiterungen) >> unübersichtlich >> schlecht handhabbar
Use cases - Bestandteile Besser (nach Alistair Cockburn (2003): Pro Use Case ein Blatt mit Tabelle, dabei in voll ausformulierter Form folgende Punkte (optional) verwenden: 1. Nummer und Name des Use-Case (Handlungsbeschreibung) 2. Charakteristische Information wie Hauptakteur, Ebene, Rahmen, Auslöser 3. Haupt-Erfolgsszenario: beschreibt schrittweise Interaktion zwischen Hauptakteur und System 4. Erweiterungen zum Haupt-Erfolgsszenario 5. Alternative Variationen des Szenario-Ablaufs, falls Verzweigungen im Hauptszenario vorhanden 6. Weitere Informationen wie Priorität, Frequenz, sekundäre Akteure 7. Offene Punkte, die ferner zu diskutieren sind 8. Verfassungsdatum oder -version
Use cases - Bestandteile Quelle: Benjamin Mayer, 2016
Use cases - Bestandteile Weiterführende Informationen: http://faculty.washington.edu/jtenenbg/courses/360/f03/project/ usecaseguidelines.html Buch: effektiv erstellen von Alistair Cockburn (Autor), Rüdiger Dieterle (Übersetzer)
Erstellen eigener use case Tabellen
Use cases - Tabellen Erstellen detaillierte Auflistung aller Schritte der Mensch-Maschine-Interaktion (gesamte System-Funktionalität allgemein verständlich und formal korrekt festhalten) Definition notwendiger Handlungen und Interaktions-Schritte zur Erledigung einer bestimmten Zielstellung Priorisierung einzelner (Unter-) Aktionen ggf. Unterscheidung von einzelner use cases entsprechend verschiedener Zielgruppen
Use cases - Template Pro Use case 1 Blatt A4
Use cases - Tabellen Übersichtlichkeit Vielzahl der Tabellen wird schnell unübersichtlich >> Use-Case Diagramm anlegen
Quelle: Moser: User Experience Design; Springer Vieweg, 2012, S. 101
Use cases - Tabellen Übersichtlichkeit Vielzahl der Tabellen wird schnell unübersichtlich >> Use-Case Diagramm anlegen Ausprobieren!
Use cases Empfehlung Tabellen und Diagramm ausdrucken und im Arbeitsraum sichtbar anbringen dadurch: konstante Referenz für alle Projektteilnehmer in allen Entwicklungsphasen
Use cases Evaluieren Erstellte im Team selbst evaluieren: konkretes Durchspielen der Abläufe auf den verschiedenen Use Case Ebenen natürliche Personen übernehmen dabei die Rolle des Nutzers und des Systems
Termine 24. April Gruppenkonsultationen 2 Slots á 3 Teams parallel Demo UX-Lab (Hr. Plail) 2 Slots á 3 Teams 01. Mai Feiertag (Tag der Arbeit) (terminieren!) 08. Mai Abgabe (alle) + Präsentationen (2 Teams): Vortrag User-Tests konzipieren www.hs-augsburg.de/~john