Date post: | 05-Apr-2015 |
Category: |
Documents |
Upload: | hugubert-zehrung |
View: | 102 times |
Download: | 0 times |
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Systems Engineering & Consulting
1) Requirements – Management
2) Use Cases
Dipl.-Inf. Robert Nittel
Mixed Mode GmbH – Lochhamer Schlag 17 – 82166 Gräfelfing
www.mixed-mode.de
© 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 RM 2 Use Cases & UML
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
1. Einführung in das
Requirements - Management
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Was sind Requirements?
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 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... !)
2. Unter welchen BedingungenBedingungen, in welchem UmfangUmfang,
mit welcher PerformancePerformance, ... soll die Software das leisten?
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Requirementsanalysein Entwicklungsprozessen
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 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 Typen Ermittlung
© 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 Typen Ermittlung
© 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 Typen Ermittlung
Requirementsanalyse
Test
Design
Implementierung
Systemintegration
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Typen von Requirements
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 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
WelcheQualität?
Welche Funktionalität?
Functional Requirementsvom System angebotene Funktionalität - “Zweck”
Route berechnen
Requirements Entwicklungsprozess Requirements Typen Ermittlung
Welche Einschränkungen?
Constraints
Vorgaben durch Umgebung
Nur Linux.
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
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
FURPS+FURPS
Implementation
InterfaceOperationsLegal
+
Resourcen Limits, Sprachen, Tools, Hardware
Schnittstellen zu externen SystemenEntwicklungsprozesse, OrganisationsstrukturenLizenzen, Gesetzgebung
Functional Requirements
Non – Functional Requirements
Constraints
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Lebenszyklen von Requirements
DokumentationRequirements Specification = Vertrag über das zu entwickelnde System
ErfassungRequirements Workshop
Functional Requirements
Non-functional Requirements
Constraints
Informationsträger
Analyst
ÄnderungenChange Management
Änderungswünsche
Informationsträger
Analyst
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Erfassen und Darstellen von Requirements
Constraints Functional RequirementsNon-functional Requirements
•Landschaft in 3D•Zoomfunktion•…
Brainstorming Use Case Analyse
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Erfassen und Darstellen von Requirements
Constraints Functional RequirementsNon-functional Requirements
+ Beschreibung
Tabellarisch Use Cases (Diagramm)
Unterschied zum Erfassen:
Die dargestellten Requirements sind für ALLE Personen nachvollziehbar.
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Methoden zur Ermittlung von Requirements
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Requirementsanalyse Analyst
Informationsträger
1. Erfassung der Informationsträger 2. Erfassung der Aktoren3. Festlegung des Kontextes4. Benutzerziele Identifizieren5. Use Cases formulieren6. Ergänzende Spezifikationen
Aktion Ziel
Stakeholder List+ Actor List + Context Diagram + User Goal List + Use Cases+ Supplementary Spec.
= Specification
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Vergessene Stakeholder Vergessene 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
ZuliefererManagement
Servicepersonal
Vertrieb
Produktgegner
Vollständige Liste von Stakeholdern = Vollständige Liste von Informationsquellen
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Requirementsanalyse Analyst
Informationsträger
1. Erfassung der Informationsträger 2. Erfassung der Aktoren3. Festlegung des Kontextes4. Benutzerziele Identifizieren5. Use Cases formulieren6. Ergänzende Spezifikationen
Aktion Ziel
Stakeholder List+ Actor List + Context Diagram + User Goal List + Use Cases+ Supplementary Spec.
= Specification
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Vergessene Aktoren Vergessene Systemfunktionalitäten
Der Aktor will ...
Berechnung der Route starten
Route berechnenin 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
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Requirementsanalyse Analyst
Informationsträger
1. Erfassung der Informationsträger 2. Erfassung der Aktoren3. Festlegung des Kontextes4. Benutzerziele Identifizieren5. Use Cases formulieren6. Ergänzende Spezifikationen
Aktion Ziel
Stakeholder List+ Actor List + Context Diagram + User Goal List + Use Cases+ Supplementary Spec.
= Specification
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 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 Fremdsystem Schnittstelle⇨
Der Aktor will ...
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Requirementsanalyse Analyst
Informationsträger
1. Erfassung der Informationsträger 2. Erfassung der Aktoren3. Festlegung des Kontextes4. Benutzerziele Identifizieren5. Use Cases formulieren6. Ergänzende Spezifikationen
Aktion Ziel
Stakeholder List+ Actor List + Context Diagram + User Goal List + Use Cases+ Supplementary Spec.
= Specification
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 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.
Requirements Entwicklungsprozess Requirements Typen Ermittlung
Aktor Benutzerziel Priorität Use Case #
Benutzer Eingabe des Zielorts Mittel 1 1 10 31.12.12
Zeit Neubestimmung der momentanen Position Leicht 2 4 3 31.12.12
TechnischeSchwierigkeit
Zeitab-schätzung [md]
Release Datum
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Requirementsanalyse Analyst
Informationsträger
1. Erfassung der Informationsträger 2. Erfassung der Aktoren3. Festlegung des Kontextes4. Benutzerziele Identifizieren5. Use Cases formulieren6. Ergänzende Spezifikationen
Aktion Ziel
Stakeholder List+ Actor List + Context Diagram + User Goal List + Use Cases+ Supplementary Spec.
= Specification
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Use Case Route berechnen
Basic – Flow:1. User gibt Zielort ein2. System berechnet Route3. 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.
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Requirementsanalyse Analyst
Informationsträger
1. Erfassung der Informationsträger 2. Erfassung der Aktoren3. Festlegung des Kontextes4. Benutzerziele Identifizieren5. Use Cases formulieren6. Ergänzende Spezifikationen
Aktion Ziel
Stakeholder List+ Actor List + Context Diagram + User Goal List + Use Cases+ Supplementary Spec.
= Specification
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 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.
Requirements Entwicklungsprozess Requirements Typen Ermittlung
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
2. Requirements aufdecken
mit Use Cases und UML
Use Cases / UML Use Cases erstellen UC Requirements
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Use Cases und dieUnified Modeling Language
(UML)
Use Cases / UML Use Cases erstellen UC Requirements
© 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 erstellen UC Requirements
© 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
SponsorGesetzgeber
Zulieferer
Motivation
Use Cases / UML Use Cases erstellen UC Requirements
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Use Case Route berechnen
Basic – Flow:1. User gibt Zielort ein2. System berechnet Route3. System zeigt die Route im
Navigations-system an
Alternative – Flow:2a. Keine Verbindung zu GPS
Exceptions:*a. Fehlermeldung
Use Case Diagramme Use Case Text
Route berechnen
GPSNutzer
Use Cases / UML Use Cases erstellen UC Requirements
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Use Cases / UML Use Cases erstellen UC Requirements
TanzenTrinken
Extension points
Nachschub
Unterhalten
Nachschubordern
Gästehinausbegleiten
Feier auflösen
Feier abruptbeenden
<<extend>>
<<extend>>
<<Vorbedingung>>{Kühlschrank geplündert}
<<include>>
<<include>>
Gast
Polizei
Gastgeber
Einweihungsfeier
EssenExtension 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.
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Use Cases erstellen
Use Cases / UML Use Cases erstellen UC Requirements
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
beliebige Templates verwendbarSind 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
© 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
GeltungsbereichUse Case NamePrimärer AktorVorbedingungenNachbedingungenMinimale ZusicherungInkludierungspunkteErweiterungspunkteStakeholderOffene 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
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Use Case Route berechnen
Basic – Flow:1. User gibt Zielort ein2. System berechnet Route3. 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
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
konsistent Glossary anlegenWortwahl
keine “Noise-Words”
20 - 30 Use Cases auf oberster Ebene
Quantität 10 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
© 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 WertBenutzer startet Messung
Wert wird validiertMessung starten wird ausgewählt
1. Benutzer gibt Parameter ein2. System validiert Wert3. System positioniert Sensor
1. Parameter eingeben2. Wert wird validiert3. Sensor wird positioniert
© 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 Casekeine 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
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Use Cases und Requirements
Use Cases / UML Use Cases erstellen UC Requirements
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Use Cases / UML Use Cases erstellen UC Requirements
System Requirements
Functional Requirements
Non-functional RequirementsConstraints
User Requirements
1
n
Use Cases beinhalten alle Verhaltens-Requirements (funktionale)
Und damit 1/3 aller Requirements eines Systems
Namen des Use Cases
Schritte der Use Cases
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
System Requirements
Functional Requirements
Non-functional RequirementsConstraints
Use Cases
Haupt-Erfolgsszenario:1. Schritt 12. Schritt 23. Schritt 34. Schritt 45. Schritt 56. Schritt 67. 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 / UML Use Cases erstellen UC Requirements
© 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 / UML Use 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 5.000 Projekten
© 2009 Mixed Mode GmbH, ein Unternehmen der PIXEL Group
technik.mensch.leidenschaft
Vor- / Nachteile von Use Cases (1/4)?
Use Cases / UML Use Cases erstellen UC Requirements
Quelle: SQS, Empirische Daten aus 5.000 Projekten
© 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 / UML Use Cases erstellen UC Requirements
© 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 ein2. System berechnet Route3. 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ünchenVerbindung zum GPS ist vorhanden
-----------------------------------------Endstatus/Output: Routendetails berechnet
Route auf dem Navi ausgegeben
Alternavtive – Flow 2a. Test-----------------------------------------Ausgangsstatus/Input: Ziel Berlin
Start MünchenKeine Verbindung zum GPS
-----------------------------------------Endstatus/Output: Hinweismeldung
Verbindung erneut suchen oderAbbrechen
Use Cases / UML Use Cases erstellen UC Requirements
© 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 / UML Use Cases erstellen UC Requirements
UC1 UC2 UC3 UC4
R
D
C
T
R
D
C
T
R
D
C
T
R
D
C
T
Eine Iteration