© 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