Sie sind auf Seite 1von 3

Requirements Engineering

Use Case Diagram

Verhaltensmodell (Sequenzdiagramm)

Requirements Elicitation (Erhebung)

1)
2)
3)
4)
5)
6)

Die Anforderungen des Kundens ermitteln, Sprache der


Kundschaft, Kommunikation mit dem Kunden.
Vorgehen:
Akteure identifizieren
Szenarien identifizieren
Use Cases identifizieren
Systemgrenzen festlegen
Zusammenhnge zwischen Use Cases und Akteuren
Nicht funktionale Anforderungen identizifieren
Qualittskriterien fr Requirements Spezifikation:
Korrekt: Anforderungen reprsentieren die Bedrfnisse der
Nicht-funktionale Anforderungen (Wie?)
User/Kundinnen (=correct)
Textuelle Dokumentation von
Konsistent: Anforderungen widersprechen sich nicht
1) Qualittsanforderungen: Merkmale der Software
(=consistent)
a) Funktionalitt (Angemessenheit, Richtigkeit, Sicherheit)
Vollstndig: Alle mglichen Szenarien werden beschrieben inkl.
b) Zuverlssigkeit
Ausnahmeverhalten (=complete)
c) Benutzbarkeit
Eindeutig: Anforderungen knnen auf genau eine Art
d) Effizienz
interpretiert werden (= unambiguous)
e) Wartbarkeit (Modifizierbarkeit)
Gewichtet: Wichtigkeit einer einzelnen Anforderung bestimmt
f)
bertragbarkeit
(=ranked)
2) Einschrnkungen: Technische Anforderungen der Umgebung
nderbar: Mglichkeit zur Vernderung der Anforderungen
Requirements Analysis (Analyse)
(Change Request) (= modifiable)
Die Anforderungen im Hinblick auf die Umsetzung analysieren,
berprfbar mit wiederholbaren Tests knnen die Anforderungen
ein Modell als Grundstck fr einen technischen Entwurf (vgl.
getestet und besttigt werden (= verifiable)
System Design), Kommunikation mit Software Engineer.
Verfolgbar: Vollstndige Referenz und Identifikatoren: alle
Abstraktion der Realitt, eine Vereinfachung
Angaben gehren zu einer Anforderung (= traceable)
Elemente identifizieren

Funktionale Anforderungen (Was?)

1) Anwendungsszenarien (User-Story): textuelle Beschreibung in


natrlicher Sprache, beschreibt ein spezifisches
Nutzungsszenario (vgl. Personas)
2) Anwendungsflle (Use Cases): Ablauf textuell beschrieben.
Erfasst in einem UML Use Case Diagramm.
Use Case Description
Namen
Ziel
Akteure
Vorbedingungen
Auslser
Beschreibung der Durchfhrunge
(Aktivitten)
Alternativen
Exception: <<extend>>
Sub: <<include>>
Nachbedingungen

1) Syntaktische: Nomen-Verb-Analyse
2) Spezialisten einbeziehen
3) Existierende Lsungen analysieren
Analyseobjektmodell (Klassendiagramm)
Auch konzeptionelles Modell, Domnenmodell

Software Design
Fokussiert auf die Lsungsdomne

System Design
Brcke zwischen der Problemstellung und der Lsung
Subsystem: Ein Teil eines grossen Systems welches eine Anzahl
Services an andere Subsysteme anbietet.
Service: Eine Gruppe von verwandten Operationen (eine
Schnittstelle), welche von einem Subsystem angeboten werden.

Zerlegung (Teile und Herrsche)


Warum?
Modularitt ist ein Software Engineering Prinzip
Management: Aufteilen des Entwicklungsaufwandes
nderung im Subsystem mglich ohne andere Subsysteme zu
beeinflussen
Reduzierung der Komplexitt (Jedes Subsystem ist klar und
eindeutig)
Wie? (Entwurfsprinzip)
Modularitt, Subsysteme
Bilden eine geschlossene Einheit
Sind ohne Kenntnisse ber den inneren Aufbau verwendbar
Funktionieren unabhngig vom Gesamtsystem
Es wird eine kapselnde Dekomposition gemacht, mit diesen
Zielen
jedes Subsystem kann ohne die Anderen verstanden werden
das Gesamtsystem kann ohne Detailkenntnisse der Subsysteme
verstanden werden
mglichst wenige Verbindungen zwischen Subsysteme
(=Kopplung)
mglichst starken inneren Zusammenhang jedes Subsystems
(=Kohsion)
Geheimprinzip
Andere Subsysteme nutzen die Leistung eines Subsystems ohne
zu wissen, wie sie funktioniert
Ein Subsystem gibt nur das ntigste Leistung bekannt
Nutzung von Vorhandenem
Verwendung von vorhandenen Lsungen (zb. API)
Das Subsystem muss abgeschlossen sein

Architektur

Klassendiagramm

Architektur schrnkt die Zerlegung ein. Definiert Layout vom


Gesamtsystem.
Client/Server (vgl. Thin/ fat client)
Peer-To-Peer
Repository
Model/View/Controller
Pipes and Filters
Layered Architecture
Client/Server
Pro
Billige Client-Hardware
Effiziente Nutzung von verteilten Systemen
Leichte Erweiterung um Server
Availability mit mehreren Servern kann eine hoher Grad an
Verfgbarkeit sichergestellt werden.
Contra
Datenaustausch kann erschwert werden (verschiedene
Datenformate)
Kommunikation gestrt (Netzwerkproblem)
Single Point of Failure (Serverproblem)

Komponentendiagramm

Implementierung
Model-Driven Development
Pro
Nur mit Design-Modell arbeiten
Automatische Codegenerierung
Verschiedenen Technologie, Programmiersprachen und
Plattformen => sauberer Code
Modelle werden nicht nur fr die Dokumentation verwendet.
Contra
Stark abstrahiert
Unvollstndige Spezifikation
Wartung des Codes ist erschwert (wegen der Automatisierung)

Test-Driven Development

Integration und Test

Fr Objekt-orientiertes programmieren

Das International Software Testing Qualifications Board (ISTQB)


definiert:
Grundsatz 1: Testen zeigt die Anwesenheit von Fehlern
Grundsatz 2: Vollstndiges Testen ist nicht mglich
Grundsatz 3: Mit dem Testen frhzeitig beginnen
Grundsatz 4: Hufung von Fehlern
Grundsatz 5: Wiederholungen haben keine Wirksamkeit
Grundsatz 6: Testen ist abhngig vom Umfeld
Grundsatz 7: Keine Fehler ein brauchbares System

Teststufen

Test schreiben bevor ausprogrammiert wird


Fhre die Tests automatisch aus und den Code so zu schreiben,
sodass es erfolgreich durchlaufen kann.

Detailed Design

Ein guter Test deckt hohe funktionale oder nichtfunktionale


Bereiche ab
Ein Test ist dann erfolgreich, wenn er einen Fehler gefunden hat!

Keine Software ist fehlerfrei. Testen ist eine wichtige Grundlage


fr ein erfolgreiches Projekt. Systematisches und geplantes
Testen sind notwendig und dient der Qualittssicherung. Durch
weitere Einbinden von Subsysteme fhrt das zu einer erhhten
Komplexitt, die durch Tests nach Fehler geprft werden knnen.
Definitionen
Fehler: Entwurfs- oder Codierungsfehler => unerwnschtes
Verhalten der Software
Strfall: Abweichung des beobachtenden Verhaltens vom
spezifizierten Verhalten.
Fehlerhafter Zustand: Unerwnschter Systemzustand, welcher
durch einen Fehler verursacht wird
Testfall: Definieren von Eingaben und erwarteten Ausgaben zur
Prfen von allflligen Strflle.
Kosten der Fehlererhebung (Construction, Detailed Design,
Architecture, Requirements)
Zielsetzung von Softwaretests
Testflle, mit der hchsten Wahrscheinlichkeit gegeben ist,
festzustellen

Unit Testing

1)
2)
1)
2)

Testen eine Komponente (Subsystem oder Klasse)


Ziel: Fehler zu finden
Statische Analyse (beim Komplieren oder Reviews)
Dynamisched Analyse (at run time, Black Box Testing, White Box
Testing)
Black Box Testing
Grundlage bildet die Spezifikation der Komponenten
Fehlervergleich zur Spezifikation (Elicitation)
Fokus auf die Zielereichung der Software
quivalenztest (Equivalence Testing)
Whle Sinnvolle Werte aus dem Wertebereich aus
Test Case fr jede Kombination von Eingabewert
Grenzwerttest (Boundary Testing)
Fehlverhalten zeigt sich bei Grenzwerten
Test fr alle Grenzwerte
White Box Testing
Codebasiertes Testverfahren
Fehler in Teilkomponenten aufdecken und lokalisieren
Debugging ist auch ein Beispiel fr White Box Testing
Alle Quellcodeteile mssen mindestens einmal zur Ausfhrung
bringen
Ablauforientierte Testflle anhand von Programmlogik erstellen
und ausfhren
Testende bei festgelegter Abdeckung (in %)
Kontrollflussgraph

a)
b)
c)

Anweisungsabdeckung (Statement Coverage)


Entscheidungsabdeckung (Decision Coverage)
Pfadabdeckung (Path Coverage)

Integration Testing
Test einer Gruppe von Subsystemen
Ziel: Fehler im Zusammenspiel oder den Schnittstellen der
Subsysteme finden

User Acceptance Testing und Usability Testing


Evaluation des Endproduktes (bergabe des Produktes)
Die Kundschaft testen
Zielsetzung: Erkennen welche Bedingungen fr das System noch
nicht erfllt werden

System Testing
Test des gesamten Systems
Zielsetzung: Abweichung des Gesamtsystems von den
Anforderungen (FA/NFA)

Created by Roger Siegenthaler, Vithushan Mahendran and David


Schlebusch