Modellbildung in der Anforderungsanalyse

(1)

Fakultät für Informatik

Lehrstuhl IV: Software & Systems Engineering 1

Modellbildung in der Anforderungsanalyse

Modellbildung in der Entwicklung Prof. Dr. Dr. h.c. Manfred Broy Gemeinsam mit Dr. Bernhard Schätz Fakultät für Informatik, TU München SS 2007

Inhalte

Vorlesungsinhalte:

1. Modellbegriff 2. Grundlagen 3. Anwendung 1. Ontologien 2. Anforderungsanalyse

1. Grundlagen 2. Modelle

1. Datensicht 2. Kontextsicht 3. Funktionssicht 4. Werkzeugbeispiel

4. Architekturen 5. Qualitätssicherung 6. Modellqualität

3. Modellgetriebene Entwicklung 4. Domänenspezifische Modellierung

Anforderungsanalyse

– Interdisziplinär: Integration aller Beteiligten („Stakeholders“) – Iterativ: Abstimmung der Anforderung

aller Beteiligten

– Initial: Formale Grundlage für alle weiteren Entwicklungstätigkeiten

• Integration in SE-Prozess:

– Vorgabe Entwicklung – Vorgabe Qualitätssicherung

• Zentrale Aufgaben:

– Herausarbeiten und Identifizieren – Spezifizieren und Dokumentieren – Analysieren und Validieren – Verwalten

P rodu k tinforma tionen

SE

Ź

7-SW SW -Integra tio n

SE

Ź

7.1-SW bis SE

Ź

7.4-SW SE

Ź

1 Sy stem-An forderun g s-

a na lys e SE 1.1 b is S E 1.8

SE

Ź

3 SW -/HW -An fo rde-

run g sana lys e SE 3.1 b i s S E 3.5

SE

Ź

4-SW SW -Grob entwu rf SE

Ź

4.1-SW bis SE

Ź

4.3-SW

SE

Ź

5-SW SW -Feinentwu rf SE

Ź

5.1-SW und SE

Ź

5.2-SW

SE

Ź

8 Sy stem-In teg ratio n

SE 8.1 b i s S E 8.3 Sys tem-

Eb ene SE

Ź

2 Sys tem-En twu rf SE 2.1 b i s S E 2.6

HW-Ei nhe it A nwen derfor derun ge n

SW-A rc hitektur

Da tenk atalog Integra tion s plan

B etrieb s infor ma tione n Sc hni tt ste llen besc hr eibung

SW -Einheits-/

HW -Einheits - Eb ene

Modu l-/Datenba nk - Eb ene SW -Kompo - nenten- Eb ene E xte rn e Vorgab e n (A G)

Impleme ntie rung s doku- me nte ( SW- Kom pone nte)

Da ten bank Rahm e nbed ingungen (f r SE 1.7 )

SWP €-Kon ze pt

B etrieb s infor matio nen

Betriebs informa tio ne n

SW-E ntwur f

SW-M odul Impleme ntie rung s dok ume nte

(SW-M odul, Da tenban k) Impleme ntie rung s dok ume nte

(SW-E inhe it)

SW- Kompon e nte B etrieb s infor matio ne n Sy ste m (ins ta ll ierba r )

Tec hnisc he A nforde run ge n Sy stemar c hitek tur

Tec hnisc he Anfor derun gen

SE

Ź

6-SW SW -Implementierun g SE

Ź

6.1-SW bis SE

Ź

6.3-SW Sy ste m (ins talli er t und in Be tr ie b)

SE

Ź

9

† b erleitun g in di e Nu tzun g SE 9.1 b i s 9.3

B etrieb s infor ma tio ne n

Leg end e :

Pr

fak tivit

te n (si ehe QS) Sc hni tt ste llenbe rsic ht

Sc hni ttste llenbe sc hrei bung Kos te n-/Nu tzenanalyse

Ange botsbe wertung

Sc hni tt ste llenbersic ht

Nich t-I T-A nteile SW-E inhe it P ro tok oll

Überblick

Fehlerarten im Entwicklungsprozess

Quellphase Fatal Schwer Mittel Leicht Total

Anforderungen 5,0 5,0 3,0 2,0 15,0

Design 3,0 22,0 10,0 5,0 40,0

Umsetzung 2,0 10,0 10,0 8,0 30,0

Dokumentation 0,0 1,0 2,0 2,0 5,0

Fehlereinf. 0,0 2,0 5,0 3,0 10,0

Gesamt 10,0 40,0 30,0 20,0 100,0

• Wann werden welche Fehler gemacht:

– Fatal: Anforderungsdefinition – Schwer: Entwurf

– Mittel, leicht: Entwurf, Umsetzung

Quelle: Jones, 1991, Applied Software Measurement

(2)

Grundlagen

Aufgaben Anforderungsanalyse:

• Erfassung des Anwendungsgebietes – „Wozu dient das zu erstellende System?“

– Unterstützte betriebliche Anläufe, gesteuerte technische Prozesse

• Abgrenzung des Leistungsumfangs – „Was leistet das zu erstellende System?“

– Bereitgestellte Funktionen

• Einschränkung der Systemkonzeption

– „Welchen Einschränkungen unterliegt das zu erstellende System?“

– Technische Vorgaben, rechtliche Rahmenbedingungen

Grundlagen

Hauptschritte Anforderungsanalyse:

1. Abgrenzung des Gegenstandsbereichs 2. Erfassung der Fachterminologie 3. Dokumentation von Nebenbedingungen

4. Erstellung eines fachlichen logischen Datenmodells 5. Erstellung eines fachlichen logischen Prozessmodells 6. Erfassung der (fachlichen) Schnittstellen

7. Erfassung der fachlichen Anforderungen

Überblick: Produkte der Anforderungsanalyse

Quelle: IEEE Std. 610.12-1990 A requirement is

• a condition or capability needed by a user to solve a problem or achieve an objective

• a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard,specification, or other formally imposed document

• a documented representation of a condition or capability as in (1) or (2)

Definition „Requirement“

Anforderungenspezifikationen:

• Abstrakt

– Nutzerorientiert („Aus der Sicht des Nutzers“, „Black Box“) – Neutral („Unabhängig von Entwurfsentscheidungen“)

• Prüfbar:

– Validierbar („Das richtige System entwickeln“) – Verifizierbar („Das System richtig entwickeln“)

(3)

Qualitätskriterien Anforderungsdefinition

Qualitätskriterien Anforderungsspezifikation (IEEE 830-1998):

• Konsistenz: Die Anforderungen sind in sich und untereinander widerspruchsfrei.

• Vollständigkeit: Die Anforderungen decken alle Eigenschaften des Zielsystems ab.

• Korrektheit: Die Anforderungen beschreiben die gewünschten Eigenschaften des Zielsystems.

• Eindeutigkeit: Die Anforderungen lassen keine mehrdeutige Interpretation zu.

• Verfolgbarkeit: Die Anforderungen lassen eine Rückverfolgung zur Quelle zu.

• Änderbarkeit: Änderungen an Anforderungen sind einfach umsetzbar.

• Prüfbarkeit: Die korrekte Umsetzung der Anforderungen im Zielsystem ist nachprüfbar.

Best Practices

Source: Jones, 2000, Software Assessments, Benchmarks and Best Practices

Best Requirements Practices for System Software:

1. Formal Requirements 2. Requirements Inspection 3. Requirements Tracing 4. Performance Requirements 5. Quality/Reliability Requirements 6. Requirements Notations 7. Requirements Segmentation 8. Function Point Measurement 9. Defect tracking

Formalisierte, strukturierte , integrierte Anforderungsmodelle

Sichten der funktionalen Spezifikation

3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Functional requirements 3.2.1 Mode 1 3.2.1.1 Functional requirement 1.1 .

. .

3.2.1.n Functional requirement 1.n 3.2.2 Mode 2 . . .

3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements

3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 System features 3.2.1 System Feature 1 3.2.1.1 Introduction/Purpose of feature 3.2.1.2 Stimulus/Response sequence 3.2.1.3 Associated functional requirements 3.2.1.3.1 Functional requirement 1 .

..

3.2.1.3.n Functional requirementn 3.2.2 System feature 2 ..

.3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements

3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Functional requirements 3.2.1 Information flows 3.2.1.1 Data flow diagram 1 3.2.1.1.1 Dataentities 3.2.1.1.2 Pertinent processes 3.2.1.1.3 Topology ..

.3.2.2 Process descriptions 3.2.2.1 Process 1 3.2.2.1.1 Input dataentities 3.2.2.1.2 Algorithmor formula of process 3.2.2.1.3 Affected data entities ..

.

Quelle: IEEE Standard 1998-830

Benötigte Sichten:

• Schnittstellen

• Systemdaten

• Betriebsmodi

• Funktionen

• Entwurfsbeschränkungen

Passende Modelle:

• Strukturmodelle

• Datenmodelle

• Verhaltensmodelle

• Ablaufmodelle

• Strukturmodelle

Hauptsichten in der Anforderungsanalyse

Hauptsichten in der SE-Anforderungsanalyse

• Datenmodellierung: Relevante Information

– Konzeptuelle Sicht: Welche Informationen werden vom System beeinflusst/beeinflussen das System?

• Kontextmodellierung: Betroffene Umgebung

– Prozesssicht: In welche Prozesse ist das System eingebettet?

– Schnittstellensicht: Über welche Schnittstellen ist das System eingebettet?

• Funktionsmodellierung: Angebotene Leistung des Systems – Funktionssicht: Welche Funktionen bietet das System?

– Nutzungssicht: Wie werden die Funktionen genutzt?

– Verhaltenssicht: Wie werden die Funktionen integriert?

(4)

Datenmodellierung

Datenmodellierung: Konzeptuelles Datenmodell – Modellierung der Konzepte der Anwendungsdomäne – Fokussierung auf für fachlichen Prozess relevanten Objekte der

Anwendungsdomäne

– Schwerpunkt: Modellierung betrieblicher Prozesse

• Charakterisierung der Struktur der relevanten Informationen – Aufbau der Daten

– Beziehungen zwischen Daten

• Varianten

– Datenrelationsmodelle: Daten und ihrer Beziehungen – Objektorientierte Modelle: Objektwelten

Konzeptmodellierung

• Anwendungsschwerpunkt: Modellierung der Zusammenhänge fachlicher Informationen (in betrieblichen Informationssystemen)

• Aufgaben:

– Klassifikation und Attributierung:

Identifikation der Objekte der Prozesse in der Anwendungsdomäne – Assoziation und Rollenbildung:

Festlegung von Beziehungen zwischen den Objekten der Anwendungsdomäne

– Generalisierung und Spezialisierung:

Identifikation von Gemeinsamkeiten der Objekte der Anwendungsdomäne

• Konzepte: Klasse, Assoziation/Aggregation, Restriktion, Rolle, Generalisierung, Attribut

Konzeptmodellierung

Modellierungsschritte:

1. Identifikation von Klassen

• Beeinflussende/beeinflusste Objekten des fachlichen Prozesses

• Eigenständige Struktur, langlebig 2. Identifikation von Assoziationen

• Fachliche Beziehungen zwischen Objekten

• Rollenorientiert, langlebig

3. Identifikation von Aggregationen und Restriktionen

• Rangordnungen oder semantische Zusammenhänge

• Eigenständige Struktur, invariant

Konzeptmodellierung

4. Identifikation von Attributen

• Problemrelevante Eigenschaften von Anwendungsobjekten

• Objektspezifisch, lösungsunabhängig 5. Identifikation von Generalisierungen

• Gemeinsamkeiten von Objekten der Anwendungsdomäne

• Minimal, invariant

Potentiell Zusätzlich:

• Identifikation von Operationen

• Identifikation des Objektlebenszyklus

(5)

Beispiel: Konzeptmodellierung

istMitglied bearbeitetVon zugeteiltZu

1..* 0..*

Name: String Vorname: String Gehalt:Int Personalnummer: Int

Mitarbeiter

gibName(): String gibVorname():String gibGehalt():Int ändereGehalt(Int)

Name: String Nummer: Int Budget: Int

Projekt

gibName: String gibNummer: Int gibBudget: Int änderBudget(Int)

istPhaseVon enthält

0..*Name: String Start: Datum Ende: Datum Phase

gibName: String gibStart(): Int ändereEnde(Int) gibEnde(Int)

Name: String Vorname: String Gehalt:Int Personalnummer: Int Freigabegrenze: Int

Projektleiter

gibName(): String gibVorname():String gibGehalt():Int ändereGehalt(Int) gibFreigabegrenze():Int ändereFreigabegrenze(Int)

Kontextmodellierung

Kontextmodelle: Prozesssicht und Schnittstellensicht

– Modellierung der fachlichen Zusammenhänge, in die das System eingebettet ist

– Fokussierung auf relevante Ausschnitte der Anwendungsumgebung

• Charakterisierung der Verwendung des Systems – Beschreibung der Quellen und Senken von Information in der

Umgebung

– Beschreibung der (angebotenen und genutzten) Schnittstellen zwischen System und Umgebung

• Varianten

– Prozessmodelle: Aktivitätsflüsse der Anwendungsprozesse – Schnittstellenmodelle: Informationsaustausch System/Umgebung

Schnittstellenmodellierung

• Anwendungsschwerpunkt: Modellierung der Schnittstelle zwischen Anwendungsumgebung und Anwendung

• Aufgaben:

– Komponentenidentifikation :

Identifikation von potenziellen Aktoren in der Anwendungsdomäne – Datenflussidentifikation:

Identifikation der produzierten/genutzten Informationen – Schnittstellenidentifikation:

Identifikation der Informationswege zwischen Umgebung und System

• Konzepte: Komponente/Aktor, Schnittstelle, Datenfluss

Schnittstellenmodellierung

1. Identifikation von Komponenten bzw. Aktoren

• Produzenten und Verbraucher der Anwendungsumgebung

• Unabhängig, zusammengehörig 2. Identifikation von Datenflüssen

• Zwischen System und Umgebungskomponenten/-aktoren ausgetauschte Informationen

• Zusammengehörig, abstrakt 3. Identifikation von Schnittstellen

• Austauschpunkte zwischen Umgebungsaktoren/-komponenten und System

• Unabhängig, abstrakt

(6)

Beispiel: Kontextdiagramm

Button A

Pedestrian Light A Traffic Light A

Controller

Button B Pedestrian Light B

Traffic Light B Pressed

Pressed Indicator

TrafficSignal

PedSignal Indicator

TrafficSignal

PedSignal

Beispiel: Use-Case Diagramm

Administrator

Kursverwaltung

Dozent Teilnehmer

Anmelden

Abmelden

Anbieten

Anlegen Bewerten

Löschen Ändern

Bermerkung: Keine Datenflüsse, keine Schnittstellen

Prozessmodellierung

• Anwendungsschwerpunkt: Modellierung des betrieblichen/technischen Prozesses der Anwendungsdomänen

• Aufgaben:

– Identifikaton Akteure:

Festlegung der Akteure im Anwendungsprozess – Identifikation Aktivitäten:

Festlegung der möglichen Aktivitäten der einzelnen Akteure – Identifikation Abhängigkeiten:

Festlegung der Synchronisierungen zwischen den Aktivitäten

• Konzepte: Akteur, Aktivität, Aktivitätsfluss, Synchronisierungspunkt, Entscheidungspunkt

Prozessmodellierung

1. Identifikation Akteure

• Beeinflussende/beeinflusst Objekte des fachlichen Prozesses

• Unabhängig, abstrakt 2. Identifikation Aktivitäten

• Potenzielle Aktivitäten der am Anwendungsprozess beteiligten Akteure

• Abstrakt, atomar

3. Identifikation Snychronisierungen

• Abhängigkeiten zwischen auslösende und ausgelösten Aktivitäten

• Unabhängig, atomar

(7)

Beispiel: Prozessmodellierung

Funktionsmodellierung

Funktionsmodelle: Funktions-, Nutzungs und Verhaltenssicht – Modellierung der vom System bereitgestellten Funktionen zur

Erfüllung der Aufgaben des Anwendungsgebietes – Beschränkung auf die Nutzungsschnittstelle des Systems – Vermeidung von Vorwegnahme von Entwurfsentscheidungen

• Charakterisierung die Verwendung des Systems

– Beschreibung des Aufbaus der Gesamtfunktionalität des Systems – Beschreibung Nutzung der Einzelfunktionalitäten des Systems – Beschreibung des Zusammenspiels der bereitgestellten Funktionen

• Varianten

– Funktionsstrukturmodelle: Funktionskompositionshierarchie – Nutzungsfallmodelle: Funktionsanwendungsszenarien – Verhaltensmodelle: Zustands/ereignisbeschreibungen

Funktionsstrukturmodellierung

• Anwendungsschwerpunkt: Modellierung des Aufbaus der Systemgesamtfunktionalität

• Aufgaben:

– Funktionsidentifikation :

Identifikation von bereitgestellten Nutzungsfunktionen – Funktionsstrukturierung:

Identifikation von Unterfunktionen der Gesamtfunktionalität

• Konzepte: Funktion, Funktionskomposition

Funktionsstrukturmodellierung

• Identifikation der Nutzungsfunktionen

– Funktionalitäten zur Erfüllung eines fachlichen Ziels im Anwendungsprozess

– Fachlich zusammenhängend, realisierungsneutral

• Identifikation der Funktionshierarchie – Teilfunktionalitäten und Funktionsvarianten – Konjunktiv, disjunktiv

(8)

Beispiel: Funktionshierarchie

Beispiel: Use-Case-Modellierung

Kursverwaltung

Teilnehmer

Anmelden Registrieren

Gebühr zahlen Kurs wählen

Abmelden Eintragen

Kreditkarten -zahlung Bankeinzug

Kreditinstitut

<<include>>

Nutzungsfallmodellierung

• Anwendungsschwerpunkt: Modellierung des Aufbaus der Systemgesamtfunktionalität

• Aufgaben:

– Identifikation Akteure:

Festlegung von teilnehmenden Akteuren der Anwendungsdomäne – Definition Vorbedingung und Nachbedingung:

Festlegung von Voraussetzungen und Resultaten der Nutzung – Spezifikation Standardfall und Erweiterungen:

Festlegung von Einzelschritten der Funktionsnutzung

• Konzepte: Akteur, (Vor-/Nach-)Bedingung, Interaktion, Nutzungsschritt

Nutzungsfallmodellierung

1. Identifikation der Akteure

• Akteure, die an der Abwicklung des Nutzungsfalls beteiligt sind

• Verursachende oder betroffene Akteure 2. Identifikation der Vorbedingung

• Notwendige Voraussetzung zur Abwicklung des Nutzungsfalls

• Realisierungsunabhängig, aus Nutzungssicht 3. Identifikation der Nutzungszenarien

• Sequenz von Einzelschritten des Standard/Ausnahme-Nutzungsfalls

• Realisierungsunabhängig, aus Nutzungssicht 4. Identifikation der Nachbedingung

• Sichergestelltes Resultat aus der Abwicklung des Nutzungsfalls

• Realisierungsunabhängig, aus Nutzungssicht

(9)

Beispiel: Szenarienmodellierung

Verhaltensmodellierung

Nutzungsfallmodellierung

• Anwendungsschwerpunkt: Modellierung der Integration der Einzelfunktionen

• Aufgaben:

– Funktionspartitionierung:

Festlegung von bereitgestellten Anwendungsfunktionen – Funktionsstrukturierung:

Festlegung von Teilfunktionsbeziehung – Funktionsdefinition:

Festlegung von Funktionsverhalten

• Konzepte: Zustand, Ereignis, Aktion, Unterzustand

Verhaltensmodellierung

• Funktionspartitionierung

– Vom System bereitgestellte Anwendungsfunktionen – Eigenständig, abgeschlossen

• Funktionsstrukturierung – Funktion-/Teilfunktionsbeziehung – Alternativ, simultan

• Funktionsdefinition

– Funktionen bzw. Übergänge mittels Ereignis/Aktionspaare – Realisierungsunabhängig, aus Nutzungssicht

Beispiel: Zustandsmodellierung

Alarm Date Time

Enabled Disabled

On Off

Medium

High Off

Alarm Light

Power Display

press1/

showDate

press1/

showAlarm press1/

showTime

press2/

LightOn release2/

LightOff

BatLow/

Warning

BatOff/

Reset BatHi/

Init press2/

setAlarm

press2/

resetAlarm Clock

(10)

Ausflug: AutoRAID

AutoRAID Modellbasierte Anforderungsanalyse

Modellbildung in der Anforderungsanalyse