1) Requirements – Management

Präsentation zum Thema: "1) Requirements – Management"—  Präsentation transkript:

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

2 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

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

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

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

6 in Entwicklungsprozessen
Requirements Entwicklungsprozess Requirements Typen Ermittlung Requirementsanalyse in Entwicklungsprozessen

7 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

8 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

9 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

10 Typen von Requirements
Entwicklungsprozess Requirements Typen Ermittlung Typen von Requirements

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

12 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

13 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

14 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

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

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

17 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

18 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

19 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

20 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

21 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

22 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 ⇨

23 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

24 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 Zeit Neubestimmung der momentanen Position Leicht 2 4 3 Use Case Namen Personen “befragen” Systeme Domainexperten konsultieren “lesen” Actor – Goal – List Gliederung der Use Cases System – Funktionen und Prioritäten Kosten – / Zeitabschätzung

25 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

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

27 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

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

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

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

31 Ü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?

32 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

33 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

34 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

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

36 (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)‏

37 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? … …

38 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

39 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 Use Cases auf oberster Ebene Quantität 10 Schritte im Basic-Flow umfangreiche Alternative-Flows  Use Case konsistent  Glossary anlegen Wortwahl keine “Noise-Words”

40 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

41 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 !!!!

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

43 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

44 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

45 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 Projekten

46 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 Projekten

47 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

48 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

49 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