BABOK Knowledge Area Requirements Analysis. Modeling Techniques. - Scope modeling - - Use cases - Holger Dexel,

Transkript

1 BABOK Knowledge Area Requirements Analysis Modeling Techniques - Scope modeling - - User stories - Use cases - Holger Dexel,

2 This presentation is build upon material of the Business Analysis Body of Knowledge (BABOK ) owned by the International Institute of Business Analysis (IIBA ). IIBA, the IIBA logo, BABOK and Business Analysis Body of Knowledge are registered trademarks owned by International Institute of Business Analysis. CBAP is a registered certification mark owned by International Institute of Business Analysis. Certified Business Analysis Professional, EEP and the EEP logo are trademarks owned by International Institute of Business Analysis. page2

3 Modellbegriffe Definitionen: Ein Modellist ein abstrahierendes Abbild einer existierenden Realität oder Vorbild für eine zu schaffende Realität Syntax: verwendete Modellelemente und gültige Kombinationen Semantik: Bedeutung der Modellelemente Formal: Definition von Syntax und Semantik über ein mathematisches Kalkül ist hoch Informal: ist niedrig page3

4 Scope Modeling page4

5 Scope modeling Scope Modell beschreiben die Abgrenzung des Analysegegenstands bzw. der Lösung. Sie beantworten zwei Fragen: Was gehört dazu und was nicht? Woher kommen die Anforderungen? System Systemkontext irrelevante Umgebung Modellierungstechniken: Data Flow Diagrams Use Case Diagrams Systemgrenze Kontextgrenze page5

6 Data Flow Diagrams (DFD) Ursprung: Strukturierte Analyse und Design (Tom De Marco 1978) Elemente: External Entity (Terminatoren, Datenquelle, Datensenke) Data Process (Prozess) Data Flow (Datenfluss) Data Store (Datenspeicher) page6

7 Data Flow Diagram als Context Diagram Beispiel: Gast Küche Bestellung Lieferung Pizzabestellung Pizza Abbuchung Scope Pizza- Lieferdienst Zahlung Bankkonto Getränkebestellung Getränke Lager Eingabe Verarbeitung Ausgabe Input Process Output page7

8 Use Case Diagrams Ursprung: Objektorientierte Modellierung (Ivar Jacobsen1992) Elemente: Name Use Case (Anwendungsfall) Name Person as Actor (Person als Akteur) Name System as Actor (System als Akteur) Association (Beziehung) Name System boundray (Systemgrenze) page8

9 Use Case Diagram als Context Diagram Beispiel 1: Scope Als Kontextdiagramm formal vollständig! Weniger Details als DFD! page9

10 Use Case Diagram als Context Diagram Beispiel 2: Scope Als Kontextdiagramm vollständiger! Gleiche Detailebene wie DFD! page 10

11 Übung: Erste Gruppe: Erstellen Sie ein ScopeModel zur Fallstudie mittels Data Flow Diagram Zweite Gruppe: Erstellen Sie ein ScopeModel zur Fallstudie mittels UseCase Diagram Zeit: 10 min page 11

12 User Stories page 12

13 User Stories Ursprung: agile bzw. iterative-inkrementelle Vorgehensmodelle Die User Story beschreibt in Usersprache, was das System für den User tun soll und warum. Beispiele: Als User will ich verschiedene Mitfahrangebote vergleichen können, um eine Entscheidung treffen zu können. Als Mitfahrer möchte ich meine Adressdaten abspeichern können, damit mich der Fahrer zu Hause abholen kann. Als Programmierer will ich einen automatisierten Deployment-Prozess, so dass die Anwendung schneller und weniger fehleranfällig ausgeliefert werden kann. Was verwendbares und nutzenstiftendes Feature User Benutzer- und andere Stakeholdergruppen bzw. -rollen Warum brauchen wir diese Story? Für wen hat die Story einen Nutzen/Wert? page 13

14 User Stories - Elemente Actor (User) Stakeholder der von der User Story profitiert Goal kurze textuelle Beschreibung was der Stakeholder erreichen möchte Motivation or Benefit Nutzen oder Wert der diesem oder einem anderen Stakeholder von der User Story geliefert wird User Stories scheinen trivial sind sie aber nicht! denn page 14

15 3 C s of User Stories Card (as representation not documentation) Just enough text to identify and prioritize the requirement + Conversation Promise for a conversation between customer and developer + Confirmation Needs acceptance criteria page 15

16 Details der User Story Die Anforderungsdetails sind in Anmerkungen und Notizen sowie den Akzeptanzkriterien beschrieben! Der Bewerber kann sich Informationen zu jedem Job der bei der Suche gefunden wurde anzeigen lassen. user story + conversation Der Bewerber kann sich Informationen zu jedem Job der bei der Suche gefunden wurde anzeigen lassen. Z eige B eschreibung, G ehalt und O rt + acceptance criteria Test mit leerer Job Beschreibung Test mit sehr langer Job Beschreibung Test mit fehlendem Gehalt Test mit 6-stelligem Gehalt page 16

17 Quality Criteria for User Stories I N V E S T Independent Negotiable Valuable Estimateable Short Testable Valuable = Business Value für User (Nutzen) oder Unternehmen (Wert) den die Lösung anbietet! page 17

18 Übung: Individuell: Erstellen Sie je eine vollständige User Story zu einer fachliche und einer nicht-fachliche Anforderung zur Fallstudie. Zeit: 10 min page 18

19 Use Cases(& Szenarios) page 19

20 Use Case Diagram - Beispiel Das kennen Sie ja schon alles page 20

21 Use Case Diagram - Elemente Name Use Case (Anwendungsfall) Stereotype Name Person as Actor (Person als Akteur) <<actor>> Name System as Actor (System als Akteur) Name Name System boundray (Systemgrenze) Association (Beziehung) A <<include>> B include-beziehung A <<extend>> B extend-beziehung Extension Point page 21

22 <<Include>> vs. <<Extend>> Beziehung Include-Beziehung: Die Interaktionsfolge von Use Case A enthält in jedem Fall die Interaktionsfolge von Use Case B A <<include>> B Extend-Beziehung: Die Interaktionsfolge von Use Case A wird an einem definierten Punkt (Extension Point) um die Interaktionsfolge von Use Case B erweitert. Diese Erweiterung ist abhängig vom Eintreten einer definierten Bedingung A Extension Point <<extend>> B page 22

23 <<Include>> und <<Extend>> - Beispiel page 23

24 Der Use Case ist mehr als eine Ellipse im UML Use Case Diagramm! Neben der Repräsentation des UseCase im UMLUseCase Diagrammuss der Use Case mittels einer Schablone (Template) textuell beschrieben werden! Der UseCase (= Anwendungsfall) beschreibt eine Systemfunktionalität aus Sicht des aufrufenden Akteurs Der UseCase beschreibt weiterhin den Zustand des Systems vor und nach Ausführung des Use Case Der Use Case soll einen Nutzen oder Wert für den aufrufenden Akteur liefern Am UseCase lassen sich weitere Attribute (z.b. zur Anforderungsverwaltung) und weitere qualitative und nicht-funktionale Anforderungen verankern. Standard für Use Case Namen: Nomen (Objekt) Verb (in english: verb noun) page 24

25 Use Case Spezifikationstemplate Bezeichner Name Kurzbeschreibung Akteure Auslösendes Ereignis Vorbedingung Nachbedingung Ergebnis Hauptszenario Alternativ- und Ausnahmeszenarien Eindeutiger Bezeichner des Use Case Eindeutiger Name des Use Case Komprimierte Beschreibung des Use Case Auflistung der beteiligten Akteure, mit mitdem UseCase in Beziehung stehen Angabe des Ereignisses, das den Use Case auslöst Liste notwendiger Voraussetzungen, die erfüllt sein müssen, bevor die Ausführung des Use Case beginnen kann Liste von Zuständen, in denen sich das System unmittelbar nach der Ausführung des Hauptszenarios befindet Beschreibung der Ausgaben, die während der Ausführung des Use Case erzeugt werden Beschreibung des Ablaufs des Hauptszenarios eines Use Case Beschreibung des Ablaufs von Alternativ-und Ausnahmeszenarien des Use Case oder lediglich Angabe der auslösenden Ereignisse. Es gelten oftmals andere nachbedingungen als im Hauptszenarion enthalten sind! page 25

26 Use Case Spezifikation - Beispiel - Bezeichner Name Kurzbeschreibung Akteure Auslösendes Ereignis Vorbedingung Nachbedingung Ergebnis Hauptszenario Alternativ- und Ausnahmeszenarien UC-4711 Bestellung aufgeben Ein Gast gibt eine Bestellung auf, um eine Pizza geliefert zu bekommen. Das System prüft ob die Pizza hergestellt werden kann, bucht die Rechungvom Konto des Gasts ab und beauftragt die Küche die Pizza zu backen. Gast, Bankkonto, Küche Der Gast hat die Bestellhotline angerufen Der Gast ist hungrig Die Pizza kann hergestellt werden und wurde in der Küche beauftragt. Die Rechnung wurde bezahlt. Angenommene Pizzabestellung 1. Der Gast bestellt eine Pizza 2. Das System prüft, ob die Pizza hergestellt werden kann 3. Das System bucht die Rechnung mit Hilfe des UseCase "Rechnung abbuchen" vom Bankkonto des Gasts ab 4. Das System beauftragt die Küche die Pizza zu backen. 5. Das System bestätigt dem Gast die Bestellung. 3a. Bei fehlgeschlagener Prüfung ob Pizza hergestellt werden kann: weiter bei 4a. Bei fehlgeschlagener Abbuchung: weiter bei 5a. Das System teilt dem Gast mit, dass die Bestellung fehlgeschlagen ist. 5a1. weil die Pizza z.z. nicht hergestellt werden kann 5a2. weil die Abbuchung fehlgeschlagen ist Keine Prosa! Möglichst strukturiertes Deutsch/Englisch verwenden! page 26

27 Vergleich der Use Case Spezifikation Deutsch (IREB) Bezeichner Name Kurzbeschreibung Akteure Auslösendes Ereignis Vorbedingung Nachbedingung Ergebnis Hauptszenario Alternativ- und Ausnahmeszenarien Erweiterungspunkte English (IIBA) unique identifier name short description actors trigger pre-condition post-condition success guarantee / minimal guarantee main success scenario / primary flow extension / alternate flow / exception flow extension points page 27

28 Übung: Erste Gruppe: Erstellen Sie ein Use Case Diagram zur Fallstudie. Beschreiben Sie einen UseCase mit dem Mitarbeiter Material bestellen können. Zweite Gruppe: Erstellen Sie ein Use Case Diagram zur Fallstudie. Beschreiben Sie einen UseCase mit dem Mitarbeiter bestelltes Material erhalten. Zeit: 15 min page 28

29 Andere Ansätze zur Beschreibung von Systemfunktionalität Data Flow Diagram (DFD) Functional Decomposition page 29