Use Cases. KP Ludwig John. Use Cases

Transkript

1

2 Voraussetzung Umfang des Projektes und Nutzersituation sind definiert in Form von: Konzept (Projektziel, Funktionen) Personas (Zielgruppe) Nutzungskontext (Technik, Umgebung, Zeitrahmen) Funktionen (Interessen / Funktionen / Nutzen)

3

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

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

6 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

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

8 Use cases - Form

9 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?

10 Use cases - Tabelle Ebenen Use Case Tabellen immer gleich strukturiert, jedoch mit unterschiedlicher Betrachtungsnähe (Ebene): Überblick Aktion Unteraktion Beispiel ATM im Detail:

11 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?

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

13 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

14 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

15 Use cases - Tabelle Beispiel ATM Use Case 2.0: Geld abheben Mindestgarantie - Karte zurück geben - Keine Kontobewegung bzw. keine Gebührenberechnung

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

17 Use cases - Beispiel Beispiel einer gelungenen Tabelle Aqualogic - Steuerung Kläranlage Master IMS 2011

18 Use cases - Beispiel Aqualogic - Steuerung Kläranlage Master IMS 2011

19 Nummerierung + Titel: Nummerierung kennzeichnet Hierarchie der. Titel benennt den Vorgang

20 Datum + Version: Der Übersichtlichkeit halber empfohlen!

21 Akteur: Nur notwendig bei wechselnden Akteuren, bzw. auf Überblicksebene

22 Ebene: Überblick, Aktion, Unteraktion... Korrespondiert mit Nummerierung

23 Voraussetzung: Trigger-Aktion; bzw. vorher abgelaufene UCs

24 Erfolgsfall: Ziel der Interaktion auf dieser Ebene Mindestgarantie bei Misserfolg

25 Standardszenario: Idealablauf schrittweise durchnummeriert Einzelschritte können bei Bedarf als UCs (Ebene Unteraktion) im Detail separat beschrieben werden

26 Erweiterungen: Abweichungen vom Happy Path Sondersituationen (User bricht ab, Vorgang misslingt an einer Stelle etc.)

27 Use cases - Beispiel Problematische Lösung (IA6 / 2009) Alles auf einer Seite

28 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

29 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

30 Use cases - Bestandteile Quelle: Benjamin Mayer, 2016

31 Use cases - Bestandteile Weiterführende Informationen: usecaseguidelines.html Buch: effektiv erstellen von Alistair Cockburn (Autor), Rüdiger Dieterle (Übersetzer)

32 Erstellen eigener use case Tabellen

33 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

34 Use cases - Template Pro Use case 1 Blatt A4

35 Use cases - Tabellen Übersichtlichkeit Vielzahl der Tabellen wird schnell unübersichtlich >> Use-Case Diagramm anlegen

36 Quelle: Moser: User Experience Design; Springer Vieweg, 2012, S. 101

37 Use cases - Tabellen Übersichtlichkeit Vielzahl der Tabellen wird schnell unübersichtlich >> Use-Case Diagramm anlegen Ausprobieren!

38 Use cases Empfehlung Tabellen und Diagramm ausdrucken und im Arbeitsraum sichtbar anbringen dadurch: konstante Referenz für alle Projektteilnehmer in allen Entwicklungsphasen

39 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

40 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