slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
1) Requirements – Management 2) Use Cases PowerPoint Presentation
Download Presentation
1) Requirements – Management 2) Use Cases

Loading in 2 Seconds...

play fullscreen
1 / 49

1) Requirements – Management 2) Use Cases - PowerPoint PPT Presentation


  • 106 Views
  • Uploaded on

1) Requirements – Management 2) Use Cases. Dipl.-Inf. Robert Nittel Mixed Mode GmbH – Lochhamer Schlag 17 – 82166 Gräfelfing www.mixed-mode.de. 1 Einführung RM. 2 Use Cases & UML. Inhalt und Vorgehensweise Einführung in das Requirements - Management Requirements?

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '1) Requirements – Management 2) Use Cases' - austin


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

1) Requirements – Management

2) Use Cases

Dipl.-Inf. Robert Nittel

Mixed Mode GmbH – Lochhamer Schlag 17 – 82166 Gräfelfing

www.mixed-mode.de

slide2

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
slide3

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

1. Einführung in das

Requirements - Management

slide4

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

Was sind Requirements?

slide5

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

Requirement = Anforderung

zur Spezifikation von Software

Definition eines benötigten Programms aus der Sicht des Auftraggebers

Wassoll die Software leisten? (Nicht: Wie... !)

Unter welchen Bedingungen, in welchem Umfang,mit welcher Performance, ... soll die Software das leisten?

slide6

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

Requirementsanalyse

in Entwicklungsprozessen

slide7

Requirementsanalyse

Design

Implementierung

Test

Systemintegration

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

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

slide8

Requirementsanalyse

Design

Implementierung

Test

Systemintegration

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

Phasenmodell (klassisch): Wasserfall

In heutigen

Softwareentwicklungsprojekten

nicht gewährleistet

  • Unrealistisch
slide9

Requirementsanalyse

Design

Implementierung

Test

Systemintegration

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

Phasenmodell mit Iteration

Sequentielle Abarbeitung der Phasen

Iterationen

Beliebig viele Iterationen

slide10

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

Typen von Requirements

slide11

Welche Funktionalität?

Welche Einschränkungen?

Welche

Qualität?

Functional Requirements

Non-functional Requirements

Constraints

vom System angebotene

Funktionalität - “Zweck”

Eigenschaften / Qualität der

Ausführung

Vorgaben durch Umgebung

Route berechnen

4 Sekunden

Nur Linux.

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

Typen von Requirements

System

Benutzer

slide12

Functional Requirements

Non – Functional Requirements

Constraints

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

F

FURPS+

U

R

P

S

+

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

Resourcen Limits, Sprachen, Tools, Hardware

Implementation

Interface

Schnittstellen zu externen Systemen

Entwicklungsprozesse, Organisationsstrukturen

Operations

Legal

Lizenzen, Gesetzgebung

slide13

Änderungen

Change Management

Analyst

Informationsträger

Änderungswünsche

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

Lebenszyklen von Requirements

Erfassung

Requirements Workshop

Analyst

Informationsträger

Functional Requirements

Non-functional Requirements

Constraints

Dokumentation

Requirements Specification = Vertrag über das zu entwickelnde System

slide14

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

Erfassen und Darstellen von Requirements

Brainstorming

Use Case Analyse

  • Landschaft in 3D
  • Zoomfunktion

Non-functional

Requirements

Functional Requirements

Constraints

slide15

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

Erfassen und Darstellen von Requirements

Tabellarisch

Use Cases (Diagramm)

+ Beschreibung

Non-functional

Requirements

Functional Requirements

Constraints

Unterschied zum Erfassen:

Die dargestellten Requirements sind für ALLE Personen nachvollziehbar.

slide16

Requirements

Entwicklungsprozess

Requirements Typen

Ermittlung

Methoden zur Ermittlung von Requirements

slide17

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

slide18

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

Vertrieb

Experte

Entwickler

Anwender

Hersteller

Servicepersonal

Gesetzgeber

Sponsor

Produktgegner

Vollständige Liste von Stakeholdern = Vollständige Liste von Informationsquellen

Vergessene Stakeholder Vergessene Anforderungen

slide19

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

slide20

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

Vollständige Liste von Aktoren = Vollständige Liste von Systemfunktionalitäten

Vergessene AktorenVergessene Systemfunktionalitäten

slide21

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

slide22

System – Funktionalität realisieren:

mittels Fremdsystem

Schnittstelle

eigenständig

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

slide23

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

slide24

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

Actor – Goal – List

Gliederung der Use Cases

System – Funktionen und Prioritäten

Kosten – / Zeitabschätzung

slide25

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

slide26

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.

slide27

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

slide28

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)

Das System darf in 100 Betriebsstunden

maximal einmal ausfallen und neu starten.

Die aktuelle Position soll innerhalb von 0.5 Sekunden bestimmt werden.

slide29

Use Cases / UML

Use Cases erstellen

UC  Requirements

2. Requirements aufdecken

mit Use Cases und UML

slide30

Use Cases / UML

Use Cases erstellen

UC  Requirements

Use Cases und die

Unified Modeling Language (UML)

slide31

Use Case Route berechnen

  • User gibt Zielort ein
  • System berechnet Route
  • System zeigt die Route im Navigationssystem an

Use Cases / UML

Use Cases erstellen

UC  Requirements

Überblick

Was ist ein Use Case (Anwendungsfall) ?

Texte, die Interaktionen

über die Zeit

beschreiben

Workflows beschreiben

Funktionelle (System-) Requirements finden

Dokumentation (Abläufe, Vorgehensweise, ...)

Wofür werden Use Cases verwendet?

slide32

Laie

Zulieferer

Experte

Entwickler

Hersteller

Anwender

Sponsor

Gesetzgeber

Prinzip

Jeder Stakeholder versteht Use Cases

Use Cases / UML

Use Cases erstellen

UC  Requirements

Motivation

Einfacher Informationsaustausch zwischen Personen mit unterschiedlichem

Wissensstand und Vokabular

Background und Verständnis

Blickwinkel

...

slide33

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

slide34

Essen

Extension points

Nachschub

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

<<Vorbedingung>>

{Kühlschrank geplündert}

Tanzen

Trinken

Extension points

Nachschub

Gast

<<extend>>

Nachschub

ordern

<<extend>>

Unterhalten

Feier auflösen

Gäste

hinausbegleiten

<<include>>

Gastgeber

<<include>>

Feier abrupt

beenden

Polizei

slide35

Use Cases / UML

Use Cases erstellen

UC  Requirements

Use Cases erstellen

slide36

Header

Szenarien

(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):

slide37

Use Cases / UML

Use Cases erstellen

UC  Requirements

Beispiel für den Header eines Use Case Templates (vollständige Erfassung):

Beschreibung

Feld

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

slide38

Ein möglicher Weg (keine Verzweigungen)

  • Interaktion Aktor – System
  • Startet / endet mit stabilen Systemzustand
  • Liefert ein messbares Ergebnis

Alternative Flow 2.1

Basic Flow

Alternative Flow 2.2

Alternative Flow 2

Zeit

  • Fehler, die das System detektieren kann
  • Gehören nicht zum regulären Programmablauf

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

slide39

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”

slide40

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

slide41

Qualität / Vollständigkeit beurteilen: Szenarien mit Daten durchlaufen

 Software Test !!!!

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

slide42

Use Cases / UML

Use Cases erstellen

UC  Requirements

Use Cases und Requirements

slide43

Use Cases / UML

Use Cases erstellen

UC  Requirements

User Requirements

Namen des Use Cases

1

n

System Requirements

Schritte der Use Cases

Non-functional Requirements

Constraints

Functional Requirements

Use Cases beinhaltenalle Verhaltens-Requirements(funktionale)

Und damit1/3 aller Requirementseines Systems

slide44

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

Use Cases / UML

Use Cases erstellen

UC  Requirements

Use Case und System Requirements

System Requirements

Non-functional Requirements

Constraints

Functional Requirements

Use Cases

Ergänzende

Spezifikation

Functionality

Usability

Reliability

Performance

Supportability

slide45

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

slide46

Use Cases / UML

Use Cases erstellen

UC  Requirements

Vor- / Nachteile von Use Cases (1/4)?

Quelle: SQS, Empirische Daten aus 5.000 Projekten

slide47

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

slide48

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

Basic – Flow Test

-----------------------------------------

Ausgangsstatus/Input: Ziel Berlin

Start München

Verbindung zum GPS ist vorhanden

-----------------------------------------

Endstatus/Output: Routendetails berechnet

Route auf dem Navi ausgegeben

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

Alternavtive – Flow 2a. Test

-----------------------------------------

Ausgangsstatus/Input: Ziel Berlin

Start München

Keine Verbindung zum GPS

-----------------------------------------

Endstatus/Output: Hinweismeldung

Verbindung erneut suchen oder

Abbrechen

slide49

UC3

UC1

UC2

UC4

Eine Iteration

R

R

R

R

D

D

D

D

C

C

C

C

T

T

T

T

Use Cases / UML

Use Cases erstellen

UC  Requirements

Vor- / Nachteile von Use Cases (4/4)?

Use Cases unterstützen die iterative Projektplanung

Dokumentations- und Aktualisierungsaufwand