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

Inhalt und Vorgehensweise 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 - Management Entwicklungsprozess Requirements Typen Ermittlung 1. Einführung in das Requirements - Management

Was sind Requirements? Requirements Entwicklungsprozess Requirements Typen Ermittlung Was sind Requirements?

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

in Entwicklungsprozessen Requirements Entwicklungsprozess Requirements Typen Ermittlung Requirementsanalyse in Entwicklungsprozessen

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

Phasenmodell (klassisch): Wasserfall Requirements Entwicklungsprozess Requirements Typen Ermittlung Phasenmodell (klassisch): Wasserfall Requirementsanalyse Test Design Implementierung Systemintegration In heutigen Softwareentwicklungsprojekten nicht gewährleistet Unrealistisch Requirements sind - anfangs nicht vollständig erfassbar - nicht stabil

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

Typen von Requirements Entwicklungsprozess Requirements Typen Ermittlung Typen von Requirements

Typen von Requirements Entwicklungsprozess Requirements Typen Ermittlung Typen von Requirements Welche Einschränkungen? Constraints Vorgaben durch Umgebung Nur Linux. Benutzer System Welche Funktionalität? Functional Requirements vom System angebotene Funktionalität - “Zweck” Route berechnen Non-functional Requirements Eigenschaften / Qualität der Ausführung 4 Sekunden Welche Qualität? Das Navigationssystem berechnet die Route in Abhängigkeit von der aktuellen Position. Die Berechnung der Route darf max. 4 Sekunden dauern. Die Software für das Navigationssystem soll auf einem Linux-System laufen.

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

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

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

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

Methoden zur Ermittlung von Requirements Entwicklungsprozess Requirements Typen Ermittlung Methoden zur Ermittlung von Requirements

1. Erfassung der Informationsträger Stakeholder List 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

1. Erfassung der Stakeholder 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 Experte Entwickler Vertrieb Hersteller Anwender Servicepersonal Gesetzgeber Sponsor Produktgegner wichtigste: direkte Benutzer -> Akzeptanz Vollständige Liste von Stakeholdern = Vollständige Liste von Informationsquellen Vergessene Stakeholder Vergessene Anforderungen

1. Erfassung der Informationsträger Stakeholder List 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 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 Person/System hat Verhalten Vollständige Liste von Aktoren = Vollständige Liste von Systemfunktionalitäten Vergessene Aktoren Vergessene Systemfunktionalitäten

1. Erfassung der Informationsträger Stakeholder List 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

3. Festlegung des Systemkontext 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 System – Funktionalität realisieren: eigenständig mittels Fremdsystem Schnittstelle ⇨

1. Erfassung der Informationsträger Stakeholder List 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

4. Identifizieren der Benutzerziele 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 Use Case Namen Personen “befragen” Systeme Domainexperten konsultieren “lesen” Actor – Goal – List Gliederung der Use Cases System – Funktionen und Prioritäten Kosten – / Zeitabschätzung

1. Erfassung der Informationsträger Stakeholder List 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

5. Formulieren der Use Cases (Functional 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.

1. Erfassung der Informationsträger Stakeholder List 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

6. Verfassen der ergänzenden Spezifikation 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) Die aktuelle Position soll innerhalb von 0.5 Sekunden bestimmt werden. Das System darf in 100 Betriebsstunden maximal einmal ausfallen und neu starten.

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

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

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

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

Use Case Diagramme Use Case Text Use Case Route berechnen 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

Einweihungsfeier Tanzen Nachschub ordern Unterhalten Feier auflösen 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 Tanzen <<Vorbedingung>> {Kühlschrank geplündert} Trinken Extension points Nachschub Gast Essen Extension points Nachschub <<extend>> Nachschub ordern <<extend>> Unterhalten Feier auflösen Gäste hinausbegleiten <<include>> Nicht zwangsläufig müssen Use Case Diagramme aúf Hard und Software beschränkt sein. 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. Gastgeber <<include>> Feier abrupt beenden Polizei

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

(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): Header Szenarien (Verhalten über die Zeit)‏

Feld Beschreibung Geltungsbereich Use Case Name Primärer Aktor Use Cases / UML Use Cases erstellen UC  Requirements Beispiel für den Header eines Use Case Templates (vollständige Erfassung): Feld Beschreibung 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 Use Case Name: Beispiel: Route berechnen Vorbedingungen: Beispiel: Start und Ziel müssen angegeben sein Offene Punkte: Beispiel: Wie Schnell soll die Route berechnet werden? … …

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 Ein möglicher Weg (keine Verzweigungen) Interaktion Aktor – System Startet / endet mit stabilen Systemzustand Liefert ein messbares Ergebnis Alternative Flow 2 Alternative Flow 2.1 Alternative Flow 2.2 Basic Flow Zeit Fehler, die das System detektieren kann Gehören nicht zum regulären Programmablauf

Use Case Formulieren (1/3) 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 Case Formulieren (2/3) 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

Use Case Formulieren (3/3) 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 Qualität / Vollständigkeit beurteilen: Szenarien mit Daten durchlaufen  Software Test !!!!

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

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

Use Case und System Requirements Use Cases / UML Use Cases erstellen UC  Requirements Use Case und System Requirements System Requirements Functional Requirements Non-functional Requirements Constraints Use Cases Ergänzende Spezifikation 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: Szenario ende Functionality Usability Reliability Performance Supportability

Vor- / Nachteile von Use Cases (1/4)? 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

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

Vor- / Nachteile von Use Cases (2/4)? 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

Vor- / Nachteile von Use Cases (3/4)? 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 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 Basic – Flow Test ----------------------------------------- Ausgangsstatus/Input: Ziel Berlin Start München Verbindung zum GPS ist vorhanden Endstatus/Output: Routendetails berechnet Route auf dem Navi ausgegeben Alternavtive – Flow 2a. Test ----------------------------------------- Ausgangsstatus/Input: Ziel Berlin Start München Keine Verbindung zum GPS Endstatus/Output: Hinweismeldung Verbindung erneut suchen oder Abbrechen

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