1) Requirements – Management 2) Use Cases

1) Requirements – Management 2) Use Cases Dipl.-Inf. Robert Nittel Mixed Mode GmbH – Lochhamer Schlag 17 – 82166 Gräfelfing www.mixed-mode.de

1 Einführung RM 2 Use Cases & UML Inhalt und Vorgehensweise • Einführung in das Requirements - Management • Requirements? • Requirements im Entwicklungsprozess • Arten von Requirements • Requirements aufdecken mit Use Cases und UML • Use Cases? • Use Cases & UML • Erstellen von Use Cases

Requirements Entwicklungsprozess Requirements Typen Ermittlung 1. Einführung in das Requirements - Management

Requirements Entwicklungsprozess Requirements Typen Ermittlung Was sind Requirements?

Requirements Entwicklungsprozess Requirements Typen Ermittlung Requirement = Anforderung zur Spezifikation von Software Definition eines benötigten Programms aus der Sicht des Auftraggebers Wassoll die Software leisten? (Nicht: Wie... !) Unter welchen Bedingungen, in welchem Umfang,mit welcher Performance, ... soll die Software das leisten?

Requirements Entwicklungsprozess Requirements Typen Ermittlung Requirementsanalyse in Entwicklungsprozessen

Requirementsanalyse Design Implementierung Test Systemintegration Requirements Entwicklungsprozess Requirements Typen Ermittlung Phasenmodell (klassisch): Wasserfall Sequentielle Abarbeitung der Phasen Vollständige Beendigung einer Phase vor Eintritt in die folgende 1. Phase: Requirements Werden nach Abschluss nicht mehr angetastet

Requirementsanalyse Design Implementierung Test Systemintegration Requirements Entwicklungsprozess Requirements Typen Ermittlung Phasenmodell (klassisch): Wasserfall In heutigen Softwareentwicklungsprojekten nicht gewährleistet • Unrealistisch

Requirementsanalyse Design Implementierung Test Systemintegration Requirements Entwicklungsprozess Requirements Typen Ermittlung Phasenmodell mit Iteration Sequentielle Abarbeitung der Phasen Iterationen Beliebig viele Iterationen

Requirements Entwicklungsprozess Requirements Typen Ermittlung Typen von Requirements

Welche Funktionalität? Welche Einschränkungen? Welche Qualität? Functional Requirements Non-functional Requirements Constraints vom System angebotene Funktionalität - “Zweck” Eigenschaften / Qualität der Ausführung Vorgaben durch Umgebung Route berechnen 4 Sekunden Nur Linux. Requirements Entwicklungsprozess Requirements Typen Ermittlung Typen von Requirements System Benutzer

Functional Requirements Non – Functional Requirements Constraints Requirements Entwicklungsprozess Requirements Typen Ermittlung F FURPS+ U R P S + Checkliste für Requirements: Functionality Funktionalitäten, Fähigkeiten, Sicherheit Usability Verständlichkeit, Erlernbarkeit, Bedienbarkeit Reliability Fehlertoleranz, Wiederherstellbarkeit Performance Zeitverhalten,Verbrauchsverhalten Supportability Anpassbarkeit,Austauschbarkeit,Modifizierung Resourcen Limits, Sprachen, Tools, Hardware Implementation Interface Schnittstellen zu externen Systemen Entwicklungsprozesse, Organisationsstrukturen Operations Legal Lizenzen, Gesetzgebung

Änderungen Change Management Analyst Informationsträger Änderungswünsche Requirements Entwicklungsprozess Requirements Typen Ermittlung Lebenszyklen von Requirements Erfassung Requirements Workshop Analyst Informationsträger Functional Requirements Non-functional Requirements Constraints Dokumentation Requirements Specification = Vertrag über das zu entwickelnde System

Requirements Entwicklungsprozess Requirements Typen Ermittlung Erfassen und Darstellen von Requirements Brainstorming Use Case Analyse • Landschaft in 3D • Zoomfunktion • … Non-functional Requirements Functional Requirements Constraints

Requirements Entwicklungsprozess Requirements Typen Ermittlung Erfassen und Darstellen von Requirements Tabellarisch Use Cases (Diagramm) + Beschreibung Non-functional Requirements Functional Requirements Constraints Unterschied zum Erfassen: Die dargestellten Requirements sind für ALLE Personen nachvollziehbar.

Requirements Entwicklungsprozess Requirements Typen Ermittlung Methoden zur Ermittlung von Requirements

Requirements Entwicklungsprozess Requirements Typen Ermittlung Requirementsanalyse Analyst Informationsträger Aktion Ziel 1. Erfassung der Informationsträger Stakeholder List 2. Erfassung der Aktoren + Actor List 3. Festlegung des Kontextes + Context Diagram 4. Benutzerziele Identifizieren + User Goal List 5. Use Cases formulieren + Use Cases 6. Ergänzende Spezifikationen + Supplementary Spec. = Specification

Requirements Entwicklungsprozess Requirements Typen Ermittlung 1. Erfassung der Stakeholder Stakeholder sind alle Personen, Einrichtungen, ... die von der Systementwicklung sowie vom Einsatz und Betrieb des Systems betroffen sind. Laie Zulieferer Management Vertrieb Experte Entwickler Anwender Hersteller Servicepersonal Gesetzgeber Sponsor Produktgegner Vollständige Liste von Stakeholdern = Vollständige Liste von Informationsquellen Vergessene Stakeholder Vergessene Anforderungen

Requirements Entwicklungsprozess Requirements Typen Ermittlung 2. Erfassung der Aktoren Aktoren sind Personen (bzw. Systeme), die ein bestimmtes Ziel erreichen wollen und dazu den Service des Systems nutzen. Berechnung der Route starten Route berechnen in max. 1 sec. Der Aktor will ... System Vollständige Liste von Aktoren = Vollständige Liste von Systemfunktionalitäten Vergessene AktorenVergessene Systemfunktionalitäten

System – Funktionalität realisieren: ⇨ mittels Fremdsystem Schnittstelle eigenständig Requirements Entwicklungsprozess Requirements Typen Ermittlung 3. Festlegung des Systemkontext Der Systemkontext legt die Grenzen des zu entwickelnden Systems und somit seine Schnittstellen zur Außenwelt fest. Zielort eingeben Position bestimmen Der Aktor will ... Navigations System GPS

Requirements Entwicklungsprozess Requirements Typen Ermittlung 4. Identifizieren der Benutzerziele Ein Benutzerziel (User Goal) ist derjenige Wunsch, den ein Aktor bei der Nutzung des Systems erfüllt haben möchte. Überblick: Was soll das System leisten? Technische Schwierigkeit Zeitab- Release Aktor Benutzerziel Priorität Use Case # schätzung [md] Datum Benutzer Eingabe des Zielorts Mittel 1 1 10 31.12.12 Zeit Neubestimmung der momentanen Position Leicht 2 4 3 31.12.12 Actor – Goal – List Gliederung der Use Cases System – Funktionen und Prioritäten Kosten – / Zeitabschätzung

Requirements Entwicklungsprozess Requirements Typen Ermittlung 5. Formulieren der Use Cases (Functional Requirements)‏ Aktoren nutzen den Service des Systems, indem sie Prozesse auslösen. Ein Use Case beschreibt einen solchen Prozess. Use Case Route berechnen Basic – Flow: • User gibt Zielort ein • System berechnet Route • System zeigt die Route im Navigations-system an Alternative – Flow: 2a. Keine Verbindung zu GPS Exceptions: *a. Fehlermeldung Textdokument bestehend aus Ablauf im Idealfall alternativen Abläufen Fehlverhalten Use Cases sind heutiger Standard um funktionale Requirements abzubilden.

Requirements Entwicklungsprozess Requirements Typen Ermittlung 6. Verfassen der ergänzenden Spezifikation (Non-functional Requirements)‏ Die ergänzende Spezifikation enthält Non-functional Requirements, die nicht in den Use Cases erfasst wurden. Non-functional Requirement im Kontext eines Use Cases Non-functional Requirement gesondert in der ergänzenden Spezifikation (Supplementary Specification) Das System darf in 100 Betriebsstunden maximal einmal ausfallen und neu starten. Die aktuelle Position soll innerhalb von 0.5 Sekunden bestimmt werden.

Use Cases / UML Use Cases erstellen UC  Requirements 2. Requirements aufdecken mit Use Cases und UML

Use Cases / UML Use Cases erstellen UC  Requirements Use Cases und die Unified Modeling Language (UML)

Use Case Route berechnen • User gibt Zielort ein • System berechnet Route • System zeigt die Route im Navigationssystem an Use Cases / UML Use Cases erstellen UC  Requirements Überblick Was ist ein Use Case (Anwendungsfall) ? Texte, die Interaktionen über die Zeit beschreiben Workflows beschreiben Funktionelle (System-) Requirements finden Dokumentation (Abläufe, Vorgehensweise, ...) Wofür werden Use Cases verwendet?

Laie Zulieferer Experte Entwickler Hersteller Anwender Sponsor Gesetzgeber Prinzip Jeder Stakeholder versteht Use Cases Use Cases / UML Use Cases erstellen UC  Requirements Motivation Einfacher Informationsaustausch zwischen Personen mit unterschiedlichem Wissensstand und Vokabular Background und Verständnis Blickwinkel ...

Use Cases / UML Use Cases erstellen UC  Requirements Use Case Diagramme Use Case Text Use Case Route berechnen Basic – Flow: • User gibt Zielort ein • System berechnet Route • System zeigt die Route im Navigations-system an Alternative – Flow: 2a. Keine Verbindung zu GPS Exceptions: *a. Fehlermeldung Route berechnen Nutzer GPS

Essen Extension points Nachschub Use Cases / UML Use Cases erstellen UC  Requirements Den Zeitpunkt , an dem ein Verhalten eines Use-Case erweitert werden kann, bezeichnet man als Erweiterungspunkt (Extension Point). Ein Use-Case darf mehrere Erweiterungspunkte haben. Einweihungsfeier <<Vorbedingung>> {Kühlschrank geplündert} Tanzen Trinken Extension points Nachschub Gast <<extend>> Nachschub ordern <<extend>> Unterhalten Feier auflösen Gäste hinausbegleiten <<include>> Gastgeber <<include>> Feier abrupt beenden Polizei

Use Cases / UML Use Cases erstellen UC  Requirements Use Cases erstellen

Header Szenarien (Verhalten über die Zeit)‏ Use Cases / UML Use Cases erstellen UC  Requirements Use Case Templates beliebige Templates verwendbar Sind nicht genormt individuelle Erweiterungen Beispiel für ein Use Case Template (vollständige Erfassung):

Use Cases / UML Use Cases erstellen UC  Requirements Beispiel für den Header eines Use Case Templates (vollständige Erfassung): Beschreibung Feld Geltungsbereich Unternehmen, Abteilung, System, Subsystem Use Case Name Aussagekräftige Benennung Primärer Aktor Möchte sein Ziel erfüllt haben Vorbedingungen Werden nur vor Beginn der Ausführung geprüft Nachbedingungen Sind nach erfolgreichem Abschluss erfüllt Minimale Zusicherung Sind nach jedem Abschluss erfüllt Inkludierungspunkte Nutzung eines Use Cases Erweiterungspunkte Optimale Erweiterung durch anderen Use Case Stakeholder Interessen müssen in jedem Schritt gewahrt werden Offene Punkte Die noch zu klären sind … …

Ein möglicher Weg (keine Verzweigungen) • Interaktion Aktor – System • Startet / endet mit stabilen Systemzustand • Liefert ein messbares Ergebnis Alternative Flow 2.1 Basic Flow Alternative Flow 2.2 Alternative Flow 2 Zeit • Fehler, die das System detektieren kann • Gehören nicht zum regulären Programmablauf Use Cases / UML Use Cases erstellen UC  Requirements Beispiel für Szenarien in einem Use Case Templates (vollständige Erfassung): Use Case Route berechnen Basic – Flow: • User gibt Zielort ein • System berechnet Route • System zeigt die Route im Navigations-system an Alternative – Flow: 2a. Keine GPS Verbindung: • Hinweismeldung wird angezeigt und Verbindungssuche wiederholt • Nutzer kann Verbindungssuche abbrechen  Szenario abgebrochen Exceptions: *a. System bekommt keine Rückmeldung trotz stabiler Verbindung

Use Cases / UML Use Cases erstellen UC  Requirements Use Case Formulieren (1/3) eindeutig Gute Use Cases sind einfach kurz 20 - 30 Use Cases auf oberster Ebene Quantität 10 Schritte im Basic-Flow umfangreiche Alternative-Flows  Use Case konsistent  Glossary anlegen Wortwahl keine “Noise-Words”

Use Cases / UML Use Cases erstellen UC  Requirements Use Case Formulieren (2/3) Schritt-Schema / Aussagekräftige Benennung Wer macht Was? Wert wird validiert Messung starten wird ausgewählt System validiert Wert Benutzer startet Messung Verantwortlichkeit ist zu jedem Zeitpunkt klar “Wer hat den Ball?” 1. Parameter eingeben 2. Wert wird validiert 3. Sensor wird positioniert 1. Benutzer gibt Parameter ein 2. System validiert Wert 3. System positioniert Sensor

Qualität / Vollständigkeit beurteilen: Szenarien mit Daten durchlaufen  Software Test !!!! Use Cases / UML Use Cases erstellen UC  Requirements Use Case Formulieren (3/3) • „Abbruch wählen“, „Beenden drücken“, … Beschreiben GUI Design •  beschreibt WIE •  GUI Änderung bewirkt ungültigen Use Case keine GUI Beschreibung in Use Cases Szenarien auch mit UML beschreibbar (Aktivitätsdiagramm) ersetzen nicht die textuelle Erfassung setzt Kenntnisse der Notation vorraus

Use Cases / UML Use Cases erstellen UC  Requirements Use Cases und Requirements

Use Cases / UML Use Cases erstellen UC  Requirements User Requirements Namen des Use Cases 1 n System Requirements Schritte der Use Cases Non-functional Requirements Constraints Functional Requirements Use Cases beinhaltenalle Verhaltens-Requirements(funktionale) Und damit1/3 aller Requirementseines Systems

Haupt-Erfolgsszenario: 1. Schritt 1 2. Schritt 2 3. Schritt 3 4. Schritt 4 5. Schritt 5 6. Schritt 6 7. Schritt 7 Alternative Szenarien: 4a. Kondition: 1. Schritt 1 2. Schritt 2 3. Schritt 3 Szenario ende Use Cases / UML Use Cases erstellen UC  Requirements Use Case und System Requirements System Requirements Non-functional Requirements Constraints Functional Requirements Use Cases Ergänzende Spezifikation Functionality Usability Reliability Performance Supportability

Use Cases / UML Use Cases erstellen UC  Requirements Vor- / Nachteile von Use Cases (1/4)? Spezifikation ist die Hauptquelle aller Probleme in einem Softwareentwicklungszyklus Requirements finden: systematische Vorgehensweise richtige Methodik 70% der Fehler entstehen während der Analyse- und Design-Phase, aber nur 10% Prozent werden in diesen Phasen entdeckt und beseitigt  Quelle: SQS, Empirische Daten aus 5.000 Projekten

Use Cases / UML Use Cases erstellen UC  Requirements Vor- / Nachteile von Use Cases (1/4)? Quelle: SQS, Empirische Daten aus 5.000 Projekten

Use Cases / UML Use Cases erstellen UC  Requirements Vor- / Nachteile von Use Cases (2/4)? Use Cases spiegeln wirkliche Anforderungen der Benutzer wieder Was? und Warum? Requirements werden gefunden UND verstanden Brauchbare Alternativen vorhanden? z.B. vertragsartige Listen, unstrukturierte Textdokumente Use Case Templates sind projektspezifisch adaptierbar

Use Cases / UML Use Cases erstellen UC  Requirements Vor- / Nachteile von Use Cases (3/4)? Use Cases sind Test Cases → für den Abnahmetest → vollständig in der Analysephase Basic – Flow Test ----------------------------------------- Ausgangsstatus/Input: Ziel Berlin Start München Verbindung zum GPS ist vorhanden ----------------------------------------- Endstatus/Output: Routendetails berechnet Route auf dem Navi ausgegeben Use Case Route berechnen Basic – Flow: • User gibt Zielort ein • System berechnet Route • System zeigt die Route im Navigations-system an Alternative – Flow: 2a. Keine GPS Verbindung: • Hinweismeldung wird angezeigt und Verbindungssuche wiederholt • Nutzer kann Verbindungssuche abbrechen  Szenario abgebrochen Exceptions: *a. System bekommt keine Rückmeldung trotz stabiler Verbindung Alternavtive – Flow 2a. Test ----------------------------------------- Ausgangsstatus/Input: Ziel Berlin Start München Keine Verbindung zum GPS ----------------------------------------- Endstatus/Output: Hinweismeldung Verbindung erneut suchen oder Abbrechen

UC3 UC1 UC2 UC4 Eine Iteration R R R R D D D D C C C C T T T T Use Cases / UML Use Cases erstellen UC  Requirements Vor- / Nachteile von Use Cases (4/4)? Use Cases unterstützen die iterative Projektplanung Dokumentations- und Aktualisierungsaufwand

1) Requirements – Management 2) Use Cases