BCSM 104 Kap 03 Anforderungsanalyse PDF

BCSM 104 - Qualitative Methoden der WI & Geschäftsprozesse BCSM 104 - KAP. 03: ANFORDERUNGSANALYSE Prof. Dr. Gael Pentang Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 2 Lernziele Am Ende...  lernen Sie die wesentlichen Methoden zur Analyse und Gestaltung von Information...

BCSM 104 - Qualitative Methoden der WI & Geschäftsprozesse BCSM 104 - KAP. 03: ANFORDERUNGSANALYSE Prof. Dr. Gael Pentang Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 2 Lernziele Am Ende...  lernen Sie die wesentlichen Methoden zur Analyse und Gestaltung von Informationssystemen kennen.  verstehen Sie, wie Anwendungsfalldiagramme zur Darstellung und Analyse von Nutzeranforderungen eingesetzt werden.  sind Sie in der Lage, die Bestandteile und Funktionen eines Mock-ups zu definieren und es zur Visualisierung von Interfaces einzusetzen.  können Sie selbstständig einfache Anwendungsfalldiagramme und Mock-ups zur Unterstützung der Anforderungsanalyse erstellen und nutzen. Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 3 Gliederung 1. Methoden der Analyse und der Gestaltung von Informationssystemen 2. Anwendungsfalldiagramme 3. Was ist ein Mock-up Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 4 Gliederung 1. Methoden der Analyse und der Gestaltung von Informationssystemen 2. Anwendungsfalldiagramme 3. Was ist ein Mock-up Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 5 1. Methoden der Analyse und der Gestaltung von Informationssystemen Definition  Eine Anforderung (engl. Requirement) ist eine Fähigkeit oder Eigenschaft, die ein System erfüllen muss.  Eine Bedingung bzw. Fähigkeit, die ein Stakeholder benötigt oder stellt, um ein Problem zu lösen oder ein Ziel zu erreichen  Eine dokumentierte Darstellung eines Bedürfnisses, einer Fähigkeit, einer Eigenschaft oder einer Bedingung. Quelle: Pohl, Klaus; Rupp, Chris: Basiswissen Requirements Engineering. 4. Auflage; 2015; dpunkt. Verlag GmbH; Heidelberg Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 6 1. Methoden der Analyse und der Gestaltung von Informationssystemen Anforderungen definieren mit Use-Case-Diagrammen und Mock-ups. Fragestellung  Was will man mit dem Anwendungssystem tun?  Wie soll die Oberfläche des Anwendungssystems aussehen? Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 7 1. Methoden der Analyse und der Gestaltung von Informationssystemen Weg der Anforderungen (vereinfacht) Entwurf Spezifikation Code Anforderungs sammlung Kunde Entwickler Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 8 1. Methoden der Analyse und der Gestaltung von Informationssystemen Was will man haben? Anforderungen.... Ich erkläre es einmal: Das bekommen Ist ja logisch, Wir brauchen ein wir recht schnell die zeitliche Informationssystem, mit und einfach hin Ah, ja, Umsatzentwicklung dem wir das... kenne ich, braucht ja jedes Kaufverhalten unserer verspreche ich habe ich mal Handels- Kunden... Ihnen. für einen unternehmen Produktions- betrieb gemacht.. Die erfahrene Sachbearbeiterin Der erfahrene Berater Was läuft hier falsch? Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 9 1. Methoden der Analyse und der Gestaltung von Informationssystemen Wie kommuniziert man die Anforderungen? 5 beauftragt Auftraggeber Auftragnehmer 4 akzeptiert 2 liest 1 schreibt 3 schreibt Lasten- Pflichten- heft heft  Lastenheft: Darin schreibt der Auftraggeber, was er dem Auftragnehmer alles lästiges aufgibt.  Pflichtenheft: Darin schreibt der Auftragnehmer, wie er denn seine Pflicht erfüllen will Quellen: Pohl, Klaus; Rupp, Chris (2001): Basiswissen Requirements Engineering. Heidelberg DIN 69901-5 (Begriffe der Projektabwicklung) Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 10 1. Methoden der Analyse und der Gestaltung von Informationssystemen Systemkontext Auftraggeber Quellen: Pohl, Klaus; Rupp, Chris (2001): Basiswissen Requirements Engineering. Heidelberg DIN 69901-5 (Begriffe der Projektabwicklung) Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 11 1. Methoden der Analyse und der Gestaltung von Informationssystemen Systemkontext besteht aus: − Geschäftsprozessen − Technischen Prozessen − Personen − Organisationsstrukturen − IT-Infrastruktur (z.B. Datenbanken) Systemgrenze  trennt das System von dessen Kontext und kann sich während der Entwicklung verändern  Innerhalb der Systemgrenze: Dinge, die während der Entwicklung verändert werden können  Außerhalb der Systemgrenze: Unveränderbare Aspekte, die zum Kontext gehören Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 12 1. Methoden der Analyse und der Gestaltung von Informationssystemen Modellierung von Anforderungen – Zweck  Spezifikation  Dekomposition (Zerlegung)  Paraphrasierung (Umschreiben)  Validierung (Überprüfung) Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 13 1. Methoden der Analyse und der Gestaltung von Informationssystemen Modellierung von Anforderungen – Vor- und Nachteile + Beziehungen zwischen Anforderungen werden klarer + Fokus auf einen Aspekt verringert Herausforderung + Syntax der Modellierungssprachen reduziert Mehrdeutigkeit − Konsistenz halten ist schwierig − Aufteilung der Information auf mehrere Modelle macht eine Integration notwendig − Hauptsächlicher Fokus auf funktionale Anforderungen − Nicht jede Information kann dargestellt werden Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 14 1. Methoden der Analyse und der Gestaltung von Informationssystemen Modellierung von Anforderungen – Typische Diagrammtypen  Boxes-and-Lines-Diagramme  Datenflussdiagrammen  Blockdefinitionsdiagramme der SysML (Systems Modeling Language)  Use-Case-Diagramme der UML (Unified Modeling Language) - Anwendungsfalldiagramme Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 15 Gliederung 1. Methoden der Analyse und der Gestaltung von Informationssystemen 2. Anwendungsfalldiagramme 3. Was ist ein Mock-up Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 16 2. Use-Case-Diagramme Definition  Ein Anwendungsfall (engl. Use Case) ist eine definierte, typische Interaktion eines Akteurs mit einem System, die dazu führt, dass ein oder mehrere Akteure durch die Nutzung des Systems einen Mehrwert erhalten.  erstmals von [Jacobson et al. 1992] vorgestellt  bündelt alle möglichen Szenarien, die eintreten können, wenn ein Akteur versucht, mithilfe des betrachteten Systems ein bestimmtes fachliches Ziel (engl. business goal) erreichen möchte. [Wikipedia]  meist in natürlicher Sprache  gut geeignet um Information über den Kontext zu dokumentieren: (Personen oder andere Systeme, die mit dem System interagieren, Vorbedingungen, die zu Beginn des Szenarios erfüllt sein müssen, …). Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 17 2. Use-Case-Diagramme Anwendungsfall – warum?  Anwendungsfälle − repräsentieren die Anforderungen der Kunden − konzentrieren sich auf das fundamentale Problem bei der Entwicklung eines Systems, der Entwicklung einer Lösung für den Kunden bzw. Anwender, die der Kunde bzw. der Anwender auch gewünscht hat − Funktionalität eines geplanten oder existierenden Systems auf der Basis einfacher Modelle  Akteur interagiert mit System im Kontext der Anwendungsfälle  Akteur: − Rolle, die jemand oder etwas einnimmt und die in Beziehung zum Geschäftsbereich steht, oder − Alles was, mit dem System interagiert  Transaktionen innerhalb eines Systems implizieren, dass dem Akteur eine Reihe von Möglichkeiten geboten wird um mit dem System zu kommunizieren und dass durch sie ein messbarer Nutzen erzeugt wird. Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 18 2. Use-Case-Diagramme Anwendungsfall – Beispiel Snackautomat Use Case „Snack kaufen“  Standardablauf der Benutzerinteraktion − Snack auswählen − Münze einwerfen − Klappe öffnen − Snack entnehmen Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 19 2. Use-Case-Diagramme Anwendungsfall – Darstellung  Use-Case Ansatz basiert auf zwei Konzepten 1. Use-Case Diagramm Übersichtsbild 2. Use-Case Spezifikation Tabelle Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 20 2. Use-Case-Diagramme Definition  Anwendungsfalldiagramm (engl. Use-Case Diagramm) ist ein praktisches, einfaches Modellierungsinstrument, um Anforderungen aufzuschreiben. Es beschreibt kurz und prägnant das erwartete Verhalten von Software. 1. Aufgabe des Use-Case-Diagramms ist es, eine grobe Ordnung in detailreiche Anforderungen zu bringen. 2. Das Use-Case-Diagramm verschafft Überblick, was ein Nutzer (Akteur) mit einem Informationssystem machen kann. Funktionen des Systems (Use-Cases). 3. Es geht um das Was, nicht um das Wie 4. Das Use-Case-Diagramm ist ein einfacher Diagrammtyp  Daraus besteht ein Use-Case Diagramm im Wesentlichen: Akteur System (-grenzen) Use-Case (Anwendungsfall) Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 21 2. Use-Case-Diagramme Anwendungsfalldiagramm – Wie kann man die Anforderungen formalisiert aufschreiben?  Die Unified Modelling Language (UML) − dient zur Modellierung, Dokumentation, Spezifikation und Visualisierung komplexer Systeme, unabhängig vom Fachgebiet. − besteht aus 14 Diagrammarten, davon 7 Strukturdiagramme (statisch, Objektbezogen), 7 Verhaltensdiagramme, davon 4 Interaktionsdiagramme. − ist im Wesentlichen eine semi-formale Notation (wie zeichne ich etwas).  UML ist (nicht...) − nicht perfekt und nicht vollständig − keine Programmiersprache − kein vollständiger Ersatz für eine textliche Beschreibung Quelle: Rupp, Chris; Queins, Stefan: UML 2 glasklar – Praxiswissen für die UML-Modellierung. 4. Auflage, 2012. Hanser, München Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 22 2. Use-Case-Diagramme Anwendungsfalldiagramm – Identifikation Akteure  Wer benutzt die wesentlichen Anwendungsfälle?  Wer braucht Systemunterstützung für die tägliche Arbeit?  Wer ist für die Systemadministration zuständig?  Mit welchen externen Geräte / (Software-) Systemen muss das System kommunizieren können  Wer oder was interessiert sich für die Ergebnisse des Systems? Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 23 2. Use-Case-Diagramme Anwendungsfalldiagramm – Identifikation Anwendungsfälle  Nach der Identifikation der Akteure, Trigger für Anwendungsfälle suchen  Welches Ziel verfolgt der Akteur?  Was sind die Aufgaben, die der Akteur vom System erwartet?  Auf welche Informationen greift der Akteur zu?  Über welche externen Änderungen muss der Akteur das System informieren?  Über welche Ereignisse muss das System den Akteur unterrichten? Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 24 2. Use-Case-Diagramme Anwendungsfalldiagramm – Anwendungsfallbeschreibung  Sprache/Grammatik 1. Schreiben Sie Use-Cases in der Gegenwartsform. 2. Schreiben Sie Use-Cases in der Aktivform. 3. Schreiben Sie in einfachen Sätzen. 4. Vermeiden Sie Modalverben (z.B. müssen, können, sollen, wollen, mögen, dürfen).  Struktur 5. Trennen Sie jede Interaktion deutlich von anderen Interaktionen.  Inhalt 6. Beschreiben Sie aus dem Blickwinkel eines Außenstehenden. 7. Benennen Sie explizit die Akteure. 8. Benennen Sie das Ziel des Use-Cases explizit. 9. Fokussieren Sie bei der Use-Cases Beschreibung auf die Erfüllung des Ziels. Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 25 2. Use-Case-Diagramme Anwendungsfalldiagramm – Beispiel Smartphone Kalender Smartphone Kalender  System (was wird beschrieben?) − Der Smartphone Kalender Termin erfassen  Akteur (wer benutzt das System?) Termine abfragen − Benutzer des Smartphone Kalender  Anwendungsfälle des Benutzers Termin ändern (was machen die Akteure?) − Erfassen von Terminen Termin exportieren − Ändern von Terminen Benutzer − Löschen von Terminen Termin löschen − Abfragen von Terminen − Exportieren von Terminen Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 26 2. Use-Case-Diagramme Anwendungsfalldiagramm – Akteur  Akteure interagieren mit dem System … − Indem Sie das System benutzen, d.h. die Ausführung von Anwendungsfälle initiieren − Indem sie vom System benutzt werden, d.h. Funktionalität zur Realisierung von Anwendungsfällen zur Verfügung stellen  Akteur wird durch Assoziationen mit Anwendungsfällen verbunden – er kommuniziert mit dem System  Jeder Akteur muss mit mindestens einem Anwendungsfall kommunizieren  Die Assoziation ist binär und kann Multiplizitäten aufweisen  Notationsvarianten: Benutzer Benutzer Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 27 2. Use-Case-Diagramme Anwendungsfalldiagramm – Multiplizität: Pilot 2 Flug durchführen Pilot Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 28 2. Use-Case-Diagramme Anwendungsfalldiagramm – Akteur (Eigenschaften)  Akteure repräsentieren Rollen der Benutzer: Konkrete Benutzer können gleichzeitig mehrere Rollen spielen, annehmen und ablegen  Sie Befinden sich klar außerhalb der Systemgrenzen  Beispiel: Kassierer:in − Als Akteur am Kassenterminal o Die Rolle, in der die Person mit dem Kassensystem interagiert − Die Klasse Kassierer:in umfasst Objekte, welche die Benutzerdaten beinhalten (Name, Sozialversicherungsnummer, …) Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 29 2. Use-Case-Diagramme Anwendungsfalldiagramm – Akteur (Klassifikation)  Menschlich: z.B. Anfänger, geübter Benutzer, Admin  Nicht-menschlich: z.B. Email-System, Fax-System  Primär: Hauptnutznießer der Anwendung  Sekundär: notwendig für das Funktionieren des Systems  Aktiv: stößt selbst Anwendungsfälle an  Passiv: stößt selbst keine Anwendungsfälle an Smartphone Kalender Termin Teilnehmer erfassen benachrichtigen Email-Server Benutzer Menschlich Nicht-menschlich Primär Sekundär aktiv passiv Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 30 2. Use-Case-Diagramme Anwendungsfalldiagramm – Anwendungsfälle  Anwendungsfälle (use-cases) beschreiben das Verhalten, das von dem zu entwickelnden Systemen erwartet wird  Identifizierung durch Sammeln von Kundenwünschen und Analyse der textuellen Problemstellung  Notationsvarianten Termin Termin erfassen erfassen Termin erfassen Termin >>Notiz zum Anwendungsfall >base use-case Basis-Anwendungsfall A Benötigt „B“ um die Funktionalität sicher zu stellen Akteur >>included use-case Inkludierter-Anwendungsfall B Kann auch separat ausgeführt werden Snack kaufen  Beispiel Termin erfassen Person Benutzer Münze Kalender einwerfen aktualisieren Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 32 2. Use-Case-Diagramme Anwendungsfalldiagramm – - Beziehung  Verhalten von B kann in A inkludiert werden − Somit entscheidet A, ob B ausgeführt wird  B kann von A aktiviert werden, muss aber nicht  A bzw. B können auch separat ausgeführt werden  Angabe des >>wo>Wann>base use-case A Akteur >>extending use-case Benutzer CD B beschriften Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 33 2. Use-Case-Diagramme Anwendungsfalldiagramm – - Beziehung  Mehrere Erweiterungsstellen (extension points) je Anwendungsfall möglich  Namen von Erweiterungsstellen − Müssen eindeutig sein − Müssen nicht mit Namen der erweiternden Anwendungsfälle übereinstimmen  Beispiel: Snackautomat Condition: {es sind keine fallenden Geräusche von Snacks zu hören} Snack kaufen Extension points: Automat Automat schütteln schütteln Benutzer Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 34 2. Use-Case-Diagramme Anwendungsfalldiagramm – Generalisierung  B erbt das Verhalten von A und kann dieses überschreiben oder ergänzen  B erbt alle Beziehungen von A A  B benötigt A (übernimmt Grundfunktionalität von A) >>base use-case  B entscheidet, was von A ausgeführt bzw. geändert wird Akteur >>extending use-case B  Modellierung abstrakter Anwendungsfälle möglich: {abstract}  Abstrakte Anwendungsfälle sind nicht ausführbar!  Beispiel: {abstract} Eintrag erfassen Benutzer Termin ToDo erfassen erfassen Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 35 2. Use-Case-Diagramme Anwendungsfalldiagramm – Generalisierung bei Akteuren (1/2)  Akteur A erbt von Akteur B  A kann mit den Anwendungsfällen X und Y kommunizieren A B  B kann nur mit Y kommunizieren X Y  Mehrfachvererbung ist erlaubt  Beispiel: Administrator Benutzer Benutzer Termin anlegen erfassen Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 36 2. Use-Case-Diagramme Anwendungsfalldiagramm – Generalisierung bei Akteuren (2/2)  Unterscheidung, ob mehrere Akteure gemeinsam mit einem Anwendungsfall kommunizieren können oder müssen A A x x c B B A und B kommunizieren mit x A oder B kommuniziert mit x Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 37 2. Use-Case-Diagramme Anwendungsfalldiagramm – - Standard vs. Best Practice Standard Best Practice Use Case 1 Use Case 1 A1 A1 Use Case 2 Use Case 2 Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 38 2. Use-Case-Diagramme Anwendungsfalldiagramm – - Standard vs. Best Practice Standard Best Practice Use Case 1 Use Case 1 A1 A1 Use Case 2 Use Case 2 Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 39 2. Use-Case-Diagramme Anwendungsfalldiagramm – Basisnotationselemente Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 40 2. Use-Case-Diagramme Anwendungsfalldiagramm – Erläuterungen (zum Nachlesen) ➊ Use-Cases: Die für das System definierten Use-Cases werden durch Ovale dargestellt, die den Namen des Use-Case enthalten. Alternativ dazu kann der Name auch unterhalb des Use-Case angegeben werden. ➋ Akteure: Akteure liegen außerhalb der Systemgrenzen und stehen jeweils stellvertretend für Personen oder Systeme, die mit dem betrachteten System interagieren. Akteure werden durch ein Rechteck repräsentiert, das den Namen des Akteurs enthält und mit dem Stereotyp «actor» versehen ist. Ist der Akteur eine Person, so kann dies durch ein Strichmännchen angezeigt werden. Handelt es sich bei dem Akteur um ein System, so wird dieses entweder durch ein Rechteck oder durch ein Strichmännchen mit dem zusätzlichen Stereotyp «system» repräsentiert. ➌ Systemgrenzen: Die Systemgrenzen innerhalb eines Use-Case-Diagramms separieren die Teile des Use-Case, die zum System gehören, von den Teilen (Personen und Systemen), die außerhalb der Systemgrenze liegen. Optional kann der Name des Systems an den Systemgrenzen angegeben werden. ➍ Extend-Beziehung: Eine Extend-Beziehung («extend») von einem »Use-Case A« zu einem »Use-Case B« besagt, dass die in »Use- Case A« enthaltene Interaktionsfolge die in »Use-Case B« definierte Interaktionsfolge an einem definierten Punkt (Extension Point) erweitert. Diese Erweiterung ist abhängig vom Eintreten einer definierten Bedingung. ➎ Include-Beziehung: Eine Include-Beziehung («include») von einem »Use-Case A« zu einem »Use-Case B« drückt aus, dass »Use- Case A« in jedem Fall die in »Use-Case B« definierte Interaktionsfolge inkludiert. ➏ Beziehungen zwischen Akteuren und Use-Cases: Findet während der Ausführung eines Use-Case Kommunikation mit einem oder mehreren Akteuren in der Umgebung statt, so wird dies durch eine Kommunikationsbeziehung zwischen dem Use-Case und den entsprechenden Akteuren dargestellt. Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 41 2. Use-Case-Diagramme Anwendungsfalldiagramm – Werkzeuge  Weitere Beispiele googeln: „Use-Case“  Werkzeuge: − MS Powerpoint − MS Visio − https://www.draw.io Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 42 2. Use-Case-Diagramme Anwendungsfalldiagramm – Typische Modellierungsfehler  Anwendungsfalldiagramme modellieren keine Abläufe! Note übermitteln Zeugnis ausstellen Zeugnis benachrichtigen Benutzer Zeugnis abholen Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 43 2. Use-Case-Diagramme Anwendungsfalldiagramm – Typische Modellierungsfehler  Akteure sind immer außerhalb der Systemgrenze Studienabteilung Auskünfte geben Student Mitarbeiter Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 44 2. Use-Case-Diagramme Anwendungsfalldiagramm – Typische Modellierungsfehler Smartphone Kalender  Obwohl der Ablauf so ist: − Eintrag erfassen Termin erfassen − Kalender aktualisieren − Teilnehmer verständigen Kalender Ist dieses Modell falsch, denn Teilnehmer verständigen aktualisieren ist nicht Teil von Kalender aktualisieren Termin ändern Benutzer Termin löschen Teilnehmer verständigen Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 45 2. Use-Case-Diagramme Anwendungsfalldiagramm – Typische Modellierungsfehler  Beim Anwendungsfall Auskünfte geben sind M1 oder M2 involviert Studienabteilung Studienabteilung M1 Studentendaten {abstract} Auskünfte vewalten Mitarbeiter geben Auskünfte Studentendaten geben vewalten M1 Erfassung Erfassung von LVs von LVs M2 M2 Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 46 2. Use-Case-Diagramme Anwendungsfalldiagramm – Typische Modellierungsfehler  Beim Anwendungsfall Auskünfte geben sind M1 oder M2 involviert Studienabteilung Studienabteilung LV anlegen Verwalten LV M2 von LVs M2 aktualisieren LV löschen Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 47 2. Use-Case-Diagramme Anwendungsfalldiagramm – Typische Modellierungsfehler  Die einzelnen Schritte werden immer gemeinsam in einer vordefinierten Reihenfolge ausgeführt, daher handelt es sich nur um einen Anwendungsfall Snackautomat Snack auswählen Snackautomat Snack kaufen Münzen einwerfen Snack kaufen Benutzer Benutzer Klappe öffnen Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 48 Reflexionsfragen  Was kann man mit einem Use-Case Diagramm darstellen?  Was stellt ein Use-Case Diagramm nicht dar?  Was sind die drei wesentlichen Notationselemente für ein Use-Case Diagramm, heißt: dürfen in keinem Use-Case Diagramm fehlen? Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 49 Gliederung 1. Methoden der Analyse und der Gestaltung von Informationssystemen 2. Anwendungsfalldiagramme 3. Was ist ein Mock-up Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 50 3. Was ist ein Mock-up? Wie soll die Benutzungsoberfläche aussehen? Ich stelle mit vor, dass Das bekommen ich in einer Übersicht wir recht schnell Umsatz die Umsätze meiner und einfach hin Entwicklung Kunden...... Kunde A 3.000EUR Kunde B 5.000 EUR Was läuft hier falsch? Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 51 3. Was ist ein Mock-up? Definition  Ein Mock-up ist eine detailreiche Darstellung einer Benutzeroberfläche, die realistisch aussieht, aber keine Funktionsfähigkeit besitzt.  grafische Darstellungen eines Softwareprojekts, die oft in frühen Phasen der Entwicklung eingesetzt werden. Sie helfen dabei, das Konzept visuell zu veranschaulichen und Ideen effektiv zu kommunizieren.  Prototypen, mit deren Hilfe am Bildschirm (Computer, Smartphone, Tablet) die Entwurfsideen und Konzepte der Benutzungsschnittstelle realitätsnah dargestellt werden.  Solche Prototypen zeigen die Gestaltung der Benutzungsschnittstelle und erlauben es auch, die Bedienung der Benutzungsschnittstelle (z. B. Klick-folgen) erlebbar zu machen, ohne dass tatsächlich die Funktionalität des betrachteten Systems implementiert ist Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 52 3. Was ist ein Mock-up? Definition... und das ist es nicht:  Ein Mock-up legt sich noch nicht auf eine Systemumgebung (Smartphone unter iOS oder Android, Webbrowser, Windows, MacOS) fest.  Ein Mock-up kümmert sich noch nicht um Farben, Schrifttypen Designelemente (es sei denn sie sind geschäftskritisch) Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 53 3. Was ist ein Mock-up? Warum Mock-ups?  Ermöglichen allen Beteiligten, eine Vorschau des Endsystems zu sehen  Fördert die Kommunikation - Vereinfachen das Feedback, da konkrete Grafiken vorhanden sind  Helfen, potenzielle Designfehler frühzeitig zu erkennen (Frühwarnsysteme) – Fehlende Anforderungen werden identifiziert, Missverständnisse werden entdeckt  Reduziert Entwicklungsrisiko – Zeit und Kosten Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 54 3. Was ist ein Mock-up? Warum Mock-ups? Mock-ups vs. Prototypen  Mock-ups sind statische Entwürfe  Prototypen sind interaktive Modelle, die bestimmte Funktionalitäten simulieren Quelle: https://usersnap.com/de/blog/wireframes-mockups-prototypen/ Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 55 3. Was ist ein Mock-up? Skizzierung von Fensterdarstellungen eines Programms Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 56 3. Was ist ein Mock-up? Beispiel für ein Mock-up Mock-up  Ausgangspunkt: verbale Beschreibung Ansicht Umsatzentwicklung Ich stelle mit vor, dass ich in einer Übersicht die ------------------------------------ Umsatz heute Umsätze meiner Kunden... Kunde A: xxx € auch grafisch dargestellt werden. Kunde B: yyy € Kunde C: zzz € gesamt: aaa €  Werkzeuge: − MS Powerpoint − Figma Gesamtumsatzentwicklung − Sketch − Canva − Adobe XD − Moqups − Figma − … Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 57 3. Was ist ein Mock-up? Canva.com - Frames Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 58 3. Was ist ein Mock-up? Moqups.com - Anmeldung und Kontoverwaltung in der Hochschul-App Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 59 3. Was ist ein Mock-up? Zum Mitmachen: Übungsaufgabe für ein einfaches Mock-up  Zeichen Sie ein einfaches Mock-up (nur für die Smartphone-App) für ein Touristik-Anwendungssystem. Beschreibung: − Es gibt zwei Anwendergruppen: Urlauber und Hotelbesitzer. − Ein Urlauber kann mit seinem Smartphone a) eine Notfall-SMS an „sein“ Hotel schicken, b) eine Liste von Hotels und Restaurants in der Nähe aufrufen,. Kap. 02 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 60 Reflexionsfragen  Wozu können Sie ein Mock-up verwenden?  Warum ist es sinnvoll, im Rahmen der Anforderungsanalyse ein Mock-up anzufertigen?  Mit welchen Werkzeugen können Sie ein Mock-up erzeugen? Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 61 Fragen zur Veranstaltung Kap. 03 - BCSM 104 Qualitative Methoden der WI & Geschäftsprozesse 62