Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft 1) Requirements – Management 2) Use Cases Dipl.-Inf. Robert Nittel.

Ähnliche Präsentationen


Präsentation zum Thema: "© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft 1) Requirements – Management 2) Use Cases Dipl.-Inf. Robert Nittel."—  Präsentation transkript:

1 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft 1) Requirements – Management 2) Use Cases Dipl.-Inf. Robert Nittel Mixed Mode GmbH – Lochhamer Schlag 17 – Gräfelfing

2 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft 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 1 Einführung RM2 Use Cases & UML

3 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft 1. Einführung in das Requirements - Management RequirementsEntwicklungsprozessRequirements TypenErmittlung

4 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Was sind Requirements? Requirements EntwicklungsprozessRequirements TypenErmittlung

5 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Requirement = Anforderung zur Spezifikation von Software Definition eines benötigten Programms aus der Sicht des Auftraggebers 1.Was soll die Software leisten?(Nicht: Wie... !) BedingungenUmfang Performance 2.Unter welchen Bedingungen, in welchem Umfang, mit welcher Performance,... soll die Software das leisten? Requirements EntwicklungsprozessRequirements TypenErmittlung

6 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Requirementsanalyse in Entwicklungsprozessen Requirements Entwicklungsprozess Requirements TypenErmittlung

7 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Requirementsanalyse Test Design Implementierung Systemintegration 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 Requirements Entwicklungsprozess Requirements TypenErmittlung

8 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft In heutigen Softwareentwicklungsprojekten nicht gewährleistet Unrealistisch Requirementsanalyse Test Design Implementierung Systemintegration Phasenmodell (klassisch): Wasserfall Requirements Entwicklungsprozess Requirements TypenErmittlung

9 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Phasenmodell mit Iteration Sequentielle Abarbeitung der Phasen Iterationen Beliebig viele Iterationen Requirements Entwicklungsprozess Requirements TypenErmittlung Requirementsanalyse Test Design Implementierung Systemintegration

10 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Typen von Requirements RequirementsEntwicklungsprozess Requirements Typen Ermittlung

11 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Typen von Requirements Benutzer System Non-functional Requirements Eigenschaften / Qualität der Ausführung 4 Sekunden Welche Qualität? Welche Funktionalität? Functional Requirements vom System angebotene Funktionalität - Zweck Route berechnen RequirementsEntwicklungsprozess Requirements Typen Ermittlung Welche Einschränkungen? Constraints Vorgaben durch Umgebung Nur Linux.

12 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Checkliste für Requirements: FunctionalityFunktionalitäten, Fähigkeiten, Sicherheit UsabilityVerständlichkeit, Erlernbarkeit, Bedienbarkeit Reliability Fehlertoleranz, Wiederherstellbarkeit PerformanceZeitverhalten, Verbrauchsverhalten SupportabilityAnpassbarkeit, Austauschbarkeit, Modifizierung FURPS+FURPS Implementation Interface Operations Legal + Resourcen Limits, Sprachen, Tools, Hardware Schnittstellen zu externen Systemen Entwicklungsprozesse, Organisationsstrukturen Lizenzen, Gesetzgebung Functional Requirements Non – Functional Requirements Constraints RequirementsEntwicklungsprozess Requirements Typen Ermittlung

13 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Lebenszyklen von Requirements Dokumentation Requirements Specification = Vertrag über das zu entwickelnde System Erfassung Requirements Workshop Functional Requirements Non-functional Requirements Constraints Informationsträger Analyst Änderungen Change Management Änderungswünsche Informationsträger Analyst RequirementsEntwicklungsprozess Requirements Typen Ermittlung

14 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Erfassen und Darstellen von Requirements Constraints Functional Requirements Non-functional Requirements Landschaft in 3D Zoomfunktion … BrainstormingUse Case Analyse RequirementsEntwicklungsprozess Requirements Typen Ermittlung

15 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Erfassen und Darstellen von Requirements Constraints Functional Requirements Non-functional Requirements + Beschreibung TabellarischUse Cases (Diagramm) Unterschied zum Erfassen: Die dargestellten Requirements sind für ALLE Personen nachvollziehbar. RequirementsEntwicklungsprozess Requirements Typen Ermittlung

16 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Methoden zur Ermittlung von Requirements RequirementsEntwicklungsprozessRequirements Typen Ermittlung

17 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Requirementsanalyse Analyst Informationsträger 1. Erfassung der Informationsträger 2. Erfassung der Aktoren 3. Festlegung des Kontextes 4. Benutzerziele Identifizieren 5. Use Cases formulieren 6. Ergänzende Spezifikationen AktionZiel Stakeholder List + Actor List + Context Diagram + User Goal List + Use Cases + Supplementary Spec. = Specification RequirementsEntwicklungsprozessRequirements Typen Ermittlung

18 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Vergessene StakeholderVergessene Anforderungen 1. Erfassung der Stakeholder Stakeholder sind alle Personen, Einrichtungen,... die von der Systementwicklung sowie vom Einsatz und Betrieb des Systems betroffen sind. Experte Laie Hersteller Entwickler Anwender SponsorGesetzgeber Zulieferer Management Servicepersonal Vertrieb Produktgegner Vollständige Liste von Stakeholdern=Vollständige Liste von Informationsquellen RequirementsEntwicklungsprozessRequirements Typen Ermittlung

19 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Requirementsanalyse Analyst Informationsträger 1. Erfassung der Informationsträger 2. Erfassung der Aktoren 3. Festlegung des Kontextes 4. Benutzerziele Identifizieren 5. Use Cases formulieren 6. Ergänzende Spezifikationen AktionZiel Stakeholder List + Actor List + Context Diagram + User Goal List + Use Cases + Supplementary Spec. = Specification RequirementsEntwicklungsprozessRequirements Typen Ermittlung

20 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Vergessene AktorenVergessene Systemfunktionalitäten Der Aktor will... Berechnung der Route starten Route berechnen in max. 1 sec. 2. Erfassung der Aktoren System Aktoren sind Personen (bzw. Systeme), die ein bestimmtes Ziel erreichen wollen und dazu den Service des Systems nutzen. Vollständige Liste von Aktoren=Vollständige Liste von Systemfunktionalitäten RequirementsEntwicklungsprozessRequirements Typen Ermittlung

21 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Requirementsanalyse Analyst Informationsträger 1. Erfassung der Informationsträger 2. Erfassung der Aktoren 3. Festlegung des Kontextes 4. Benutzerziele Identifizieren 5. Use Cases formulieren 6. Ergänzende Spezifikationen AktionZiel Stakeholder List + Actor List + Context Diagram + User Goal List + Use Cases + Supplementary Spec. = Specification RequirementsEntwicklungsprozessRequirements Typen Ermittlung

22 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft 3. Festlegung des Systemkontext Der Systemkontext legt die Grenzen des zu entwickelnden Systems und somit seine Schnittstellen zur Außenwelt fest. Zielort eingeben Navigations System GPS Position bestimmen System – Funktionalität realisieren: eigenständig mittels FremdsystemSchnittstelle Der Aktor will... RequirementsEntwicklungsprozessRequirements Typen Ermittlung

23 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Requirementsanalyse Analyst Informationsträger 1. Erfassung der Informationsträger 2. Erfassung der Aktoren 3. Festlegung des Kontextes 4. Benutzerziele Identifizieren 5. Use Cases formulieren 6. Ergänzende Spezifikationen AktionZiel Stakeholder List + Actor List + Context Diagram + User Goal List + Use Cases + Supplementary Spec. = Specification RequirementsEntwicklungsprozessRequirements Typen Ermittlung

24 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Überblick: Was soll das System leisten? Gliederung der Use Cases Kosten – / Zeitabschätzung System – Funktionen und Prioritäten Actor – Goal – List 4. Identifizieren der Benutzerziele Ein Benutzerziel (User Goal) ist derjenige Wunsch, den ein Aktor bei der Nutzung des Systems erfüllt haben möchte. RequirementsEntwicklungsprozessRequirements Typen Ermittlung Aktor BenutzerzielPrioritätUse Case # BenutzerEingabe des ZielortsMittel ZeitNeubestimmung der momentanen PositionLeicht Technische Schwierigkeit Zeitab- schätzung [md] Release Datum

25 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Requirementsanalyse Analyst Informationsträger 1. Erfassung der Informationsträger 2. Erfassung der Aktoren 3. Festlegung des Kontextes 4. Benutzerziele Identifizieren 5. Use Cases formulieren 6. Ergänzende Spezifikationen AktionZiel Stakeholder List + Actor List + Context Diagram + User Goal List + Use Cases + Supplementary Spec. = Specification RequirementsEntwicklungsprozessRequirements Typen Ermittlung

26 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Use Case Route berechnen Basic – Flow: 1.User gibt Zielort ein 2.System berechnet Route 3.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. 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. RequirementsEntwicklungsprozessRequirements Typen Ermittlung

27 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Requirementsanalyse Analyst Informationsträger 1. Erfassung der Informationsträger 2. Erfassung der Aktoren 3. Festlegung des Kontextes 4. Benutzerziele Identifizieren 5. Use Cases formulieren 6. Ergänzende Spezifikationen AktionZiel Stakeholder List + Actor List + Context Diagram + User Goal List + Use Cases + Supplementary Spec. = Specification RequirementsEntwicklungsprozessRequirements Typen Ermittlung

28 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft 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. 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. RequirementsEntwicklungsprozessRequirements Typen Ermittlung

29 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft 2. Requirements aufdecken mit Use Cases und UML Use Cases / UMLUse Cases erstellenUC Requirements

30 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Use Cases und die Unified Modeling Language (UML) Use Cases / UML Use Cases erstellenUC Requirements

31 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Was ist ein Use Case (Anwendungsfall) ? Überblick Texte, die Interaktionen über die Zeit beschreiben Use Case Route berechnen 1.User gibt Zielort ein 2.System berechnet Route 3.System zeigt die Route im Navigationssystem an Wofür werden Use Cases verwendet? Workflows beschreiben Funktionelle (System-) Requirements finden Dokumentation (Abläufe, Vorgehensweise,...) Use Cases / UML Use Cases erstellenUC Requirements

32 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Einfacher Informationsaustausch zwischen Personen mit unterschiedlichem Wissensstand und Vokabular Background und Verständnis Blickwinkel... Prinzip Jeder Stakeholder versteht Use Cases Experte Laie Hersteller Entwickler Anwender Sponsor Gesetzgeber Zulieferer Motivation Use Cases / UML Use Cases erstellenUC Requirements

33 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Use Case Route berechnen Basic – Flow: 1.User gibt Zielort ein 2.System berechnet Route 3.System zeigt die Route im Navigations- system an Alternative – Flow: 2a.Keine Verbindung zu GPS Exceptions: *a.Fehlermeldung Use Case DiagrammeUse Case Text Route berechnen GPSNutzer Use Cases / UML Use Cases erstellenUC Requirements

34 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Use Cases / UML Use Cases erstellenUC Requirements Tanzen Trinken Extension points Nachschub Unterhalten Nachschub ordern Gäste hinausbegleiten Feier auflösen Feier abrupt beenden > {Kühlschrank geplündert} > Gast Polizei Gastgeber Einweihungsfeier Essen Extension points Nachschub 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.

35 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Use Cases erstellen Use Cases / UML Use Cases erstellen UC Requirements

36 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft beliebige Templates verwendbar Sind nicht genormt individuelle Erweiterungen Beispiel für ein Use Case Template (vollständige Erfassung): Header Szenarien (Verhalten über die Zeit) Use Case Templates Use Cases / UML Use Cases erstellen UC Requirements

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

38 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Use Case Route berechnen Basic – Flow: 1.User gibt Zielort ein 2.System berechnet Route 3.System zeigt die Route im Navigations- system an Alternative – Flow: 2a.Keine GPS Verbindung: 1.Hinweismeldung wird angezeigt und Verbindungssuche wiederholt 2.Nutzer kann Verbindungssuche abbrechen Szenario abgebrochen Exceptions: *a.System bekommt keine Rückmeldung trotz stabiler Verbindung 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 Beispiel für Szenarien in einem Use Case Templates (vollständige Erfassung): Ein möglicher Weg (keine Verzweigungen) Interaktion Aktor – System Startet / endet mit stabilen Systemzustand Liefert ein messbares Ergebnis Use Cases / UML Use Cases erstellen UC Requirements

39 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft konsistent Glossary anlegen Wortwahl keine Noise-Words Use Cases auf oberster Ebene Quantität10 Schritte im Basic-Flow umfangreiche Alternative-Flows Use Case eindeutig Gute Use Cases sind einfach kurz Use Case Formulieren (1/3) Use Cases / UML Use Cases erstellen UC Requirements

40 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Schritt-Schema / Aussagekräftige Benennung Wer macht Was? Verantwortlichkeit ist zu jedem Zeitpunkt klar Wer hat den Ball? Use Case Formulieren (2/3) Use Cases / UML Use Cases erstellen UC Requirements System validiert Wert Benutzer startet Messung Wert wird validiert Messung starten wird ausgewählt 1. Benutzer gibt Parameter ein 2. System validiert Wert 3. System positioniert Sensor 1. Parameter eingeben 2. Wert wird validiert 3. Sensor wird positioniert

41 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Abbruch wählen, Beenden drücken, … Beschreiben GUI Design beschreibt WIE GUI Änderung bewirkt ungültigen Use Case keine GUI Beschreibung in Use Cases Qualität / Vollständigkeit beurteilen: Szenarien mit Daten durchlaufen Software Test !!!! Szenarien auch mit UML beschreibbar (Aktivitätsdiagramm) ersetzen nicht die textuelle Erfassung setzt Kenntnisse der Notation vorraus Use Case Formulieren (3/3) Use Cases / UML Use Cases erstellen UC Requirements

42 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Use Cases und Requirements Use Cases / UMLUse Cases erstellen UC Requirements

43 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Use Cases / UMLUse Cases erstellen UC Requirements System Requirements Functional Requirements Non-functional Requirements Constraints User Requirements 1 n Use Cases beinhalten alle Verhaltens-Requirements(funktionale) Und damit1/3 aller Requirementseines Systems Namen des Use Cases Schritte der Use Cases

44 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft System Requirements Functional Requirements Non-functional Requirements Constraints Use Cases 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 Ergänzende Spezifikation Use Case und System Requirements Functionality Usability Reliability Performance Supportability Use Cases / UMLUse Cases erstellen UC Requirements

45 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Requirements finden: systematische Vorgehensweise richtige Methodik Spezifikation ist die Hauptquelle aller Probleme in einem Softwareentwicklungszyklus Vor- / Nachteile von Use Cases (1/4)? Use Cases / UMLUse Cases erstellen UC Requirements 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 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Vor- / Nachteile von Use Cases (1/4)? Use Cases / UMLUse Cases erstellen UC Requirements Quelle: SQS, Empirische Daten aus Projekten

47 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft 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 (2/4)? Use Cases / UMLUse Cases erstellen UC Requirements

48 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Use Cases sind Test Cases für den Abnahmetest vollständig in der Analysephase Vor- / Nachteile von Use Cases (3/4)? Use Case Route berechnen Basic – Flow: 1.User gibt Zielort ein 2.System berechnet Route 3.System zeigt die Route im Navigations- system an Alternative – Flow: 2a.Keine GPS Verbindung: 1.Hinweismeldung wird angezeigt und Verbindungssuche wiederholt 2.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 Use Cases / UMLUse Cases erstellen UC Requirements

49 © 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft Dokumentations- und Aktualisierungsaufwand Use Cases unterstützen die iterative Projektplanung Vor- / Nachteile von Use Cases (4/4)? Use Cases / UMLUse Cases erstellen UC Requirements UC1UC2 UC3 UC4 R D C T R D C T R D C T R D C T Eine Iteration


Herunterladen ppt "© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group technik.mensch.leidenschaft 1) Requirements – Management 2) Use Cases Dipl.-Inf. Robert Nittel."

Ähnliche Präsentationen


Google-Anzeigen