Uni Freiburg, 24.7.2008Requirements Engineering Dr. D. Fehrer1 Requirements Engineering.

Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer

1

Requirements Engineering


2Dr. D. Fehrer

Phasen der SW-Entwicklung (nach Balzert)

Planung

Definition

Entwurf

Implementierung

Abnahme &Einführung

Wartung &Pflege


3

Wasserfall-Modell

System-Anforderungen

Software-Anforderungen

Analyse

Entwurf

Codierung

Testen

Betrieb


4

V-Modell 97 (grob)

Anforderungs-definition

Modul-test

Implemen-tation

Integrations-test

Fein-entwurf

Grob-entwurf

System-test

Abnahme-test

Anwendungsszenarien

Testfälle

Testfälle

Tf.


5

Klassische Definition Analyse

• ... mündet in ein Zieldokument („Lastenheft“): „was“, nicht „wie“– detaillierte Funktionsbeschreibung– Vorhersagen für wichtige Parameter

(geht ein in Kosten, Nutzen, Performanz)– Übereinstimmung zwischen allen

Vertragspartnern


6

Motivation

Spezifikation Entwurf Codierung Test Abnahme Betrieb

10

200

100

Relative Fehlerbehebungskosten

ca. 65% der schwerwiegenden Fehler in Programmen sind auf Fehler bei der Analyse zurückzuführen!


7

Effekt der Analyse auf den SW-Lebenszyklus

• bessere Kommunikation (intern und extern)

• Redundanzelimination in der Dokumentation

• Doku startet früh

• leichtere Änderbarkeit der Dokumentation

• vollständige Studie ganzer Felder

• aber: der Zyklus wird frontlastig! (Panik?)


8

warum Analyse?

• bessere Beurteilbarkeit im Vorfeld• Erhebung von Vergleichsdaten für künftige

Projekte• Wiederverwendung von Entwürfen

GERADE für Änderungen/Varianten!

• weniger zur Erfolgserzielung als zur Fehlervermeidung (defensiv)


9

Fehler und Ressourcenmanagement

• Fehler in unterschiedlichen Phasen von unterschiedlichen Auswirkungen

• „zu viel Zeit verbraten“,„jetzt endlich Resultate sehen“

• schwer vermittelbar (außer Bereiche wie Luftfahrt)


10

Lösung 1: spezifikationsorientierte Entwicklung („schwergewichtig“)Plus:

• (scheinbar) gute Planbarkeit

• viel Hilfestellung durch definierten Prozess

• Unterstützung durch Vorlagen und Checklisten möglich

• Qualitätssicherung durch frühe Testplanung

Minus:

• teilweise sehr aufwändig

• Feedback-Schleifen recht lang

• hoher Lernaufwand


11

Zur Terminologie

• Klassische Bezeichnung:Requirements Analyse

• legt traditionelles Phasenmodell nahe

• Voraussetzungen:– gut verstandene Domäne– existierende Lösungen (in SW nachbauen)


12

Schwierigkeiten der Analyse

• Aufwand der Dokumenterstellung(Automatisierung!)

• inadäquate Methodik(lernen!)

• unterschiedliche Sprachen(graphisch!)


13

Probleme der Anforderungsanalyse

• Unklare Zielvorstellungen (verschiedene Personengruppen)

• Hohe Komplexität der Aufgabe (wechselseitige Abhängigkeiten)

• Kommunikationsbarrieren

• Requirements creeping (Dazulernen)

• Schlechte Qualität der Anforderungen (Mehrdeutigkeiten, Redundanzen, Widersprüche)

• Gold-plating

• Ungenaue Planung und Verfolgung


14

Analyse

• ist schwierig: heterogene Personengruppen mit unterschiedlichen Zielvorstellungen

• ist frustrierend!

• ist schlecht definierbar: es ist oft nicht einmal klar, wann sie zuende ist


15

Zitat (Tom De Marco):

„So analysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult.In a word, it is fascinating.Once you‘re hooked, the old easy pleasures of system building are never again enough to satisfy you.“


16

Kein System wird erfolgreich werden ohne die aktive und bereitwillige Beteiligung seiner Nutzer.

Benutzer müssen damit vertraut gemacht werden, wie das System funktioniert, und wie man damit umgeht.

Der „Tuning-Kanal“ muß offen bleiben

DAS IST DIE AUFGABE DES ANALYTIKERS!!!


17

Die Realität

• Oftmals nur vage Produkt- / Lösungsidee

• unterschiedlichste Vorstellungen der verschiedenen Entscheider („stakeholder“)


18

Konsequenzen„erarbeiten“ statt nur „aufdecken“

(Requirements Engineering!) gegenüberstellen und gewichten

(Priorisierung) laufend anpassen

(Requirements Management) und frühzeitig spiegeln

(ablauffähige Modelle?)


19

Lösung 2: iterative Entwicklung (Spiralmodell) Test

Design

Plus:

• hohe Flexibilität

• rasches Feedback

• risikobasiert

• gute Erfolgskontrolle der einzelnen (Zwischen-)Ergebnisse

• kein „Hellsehen“ nötig

Minus:

• schlecht langfristig planbar

• schlechte Gesamt-Fortschrittskontrolle


20



documentingdiscovering maintaining

Vgl. Sommerville&Sawyer

eliciting modelling communicating agreeing evolving

Vgl. Nuseibeh&Easterbrook


21

Aktivitäten im RE• Anforderungsgewinnung (Elicitation)

• Verhandlung (Negotiation)

• Spezifikation (inkl. Dokumentation)

• Validierung / Verifikation

• Management– Change– Versionierung– Tracing


22

Vorgehen

• Feld festlegen (nicht zu speziell, aber ...)

• betroffene Benutzer identifizieren

• Interviews

• Diagramme erstellen

• Walkthroughs mit Nutzern (Validierung)

• Veröffentlichung des Resultats


23

„Phasen“

frühe Phase späte PhaseKunden-wünsche

Domänen-wissen

Altsystem-randbedingungen

Anforderungs-modelle

Kontext-beschrei-bungen

Gewinnung

Verhandlung

Spezifikation

Validierung

Gewinnung

Verhandlung

Spezifikation

Verifikation

R-Management

Entwurf

System-Spezifikation


24

Partitionierung SW / HW• Annahme V-Modell 97:

frühe Auftrennung in HW und SW eine gemeinsame System-Phase,

danach zwei unabhängige Pfade• Beobachtung 1:

viele Anforderungen, die das Gesamtsystem betreffen, können erst detailliert werden, wenn man ein Teilsystem genauer betrachtet

• Beobachtung 2:viele Anforderungen ergeben sich erst nach der erfolgten Aufteilung


25

Ideale Eigenschaften von Anforderungsmodellen

• graphisch

• hierarchisch

• streng

• wartbar

• iterativ

• logische Sicht, nicht physikalisch (aber ...)


26

Arten von Anforderungsmodellen:

• Lösungsorientiert– Strukturbeschreibungen, Schnittstellen, Zustände ...

• Zielmodellierung– Hierarchie von Teilzielen, Abhängigkeiten, Konflikte

...

• Szenarien und Use Cases– Verwendung, Validierungsorientierte Tests, ...


27

Requirement (Anforderung)Definition (gemäß IEEE Standard Glossary of Software Engineering

Terminology 610.12-1990):

Eine dokumentierte Darstellung (representation) einer Bedingung oder Fähigkeit (capability) gemäß 1 oder2:

1. Beschaffenheit oder Fähigkeit, die von einem Benutzer zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.

2. Beschaffenheit oder Fähigkeit, die ein System oder System-Teile erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.


28

Arten von Anforderungen

• Funktionale Anforderungen

• Design-Anforderungen (!)

• Schnittstellen-Anforderungen

• Performance-Anforderungen

• Physikalische Anforderungen

• Qualitätsattribute


29

Beispiele für eingebettete Systeme

Funktion Performanz Qualität

Latenz

Sicherheit (safety)

Zuverlässigkeit

VerfügbarkeitEnergieverbrauch

Timing

Wartbarkeit

Messwertdarstellung

Parametrierung

Messen


30

Qualitätskriteria (einzelne Anforderung)

• vollständig* (eher: gereift?)

• korrekt* (gemäß Stakeholder!)

• klassifizierbar (rechtliche Relevanz)

• konsistent*

• prüfbar*

• eindeutig* (kein Interpretationsspielraum)

• verstehbar (für alle Stakeholder)

• gültig und aktuell

• realisierbar (+ Kosten?)

• notwendig

• verfolgbar*

• bewertet* (Priorisierung!)

* = IEEE 830-1998


31

Qualitätskriteria (gesamte Spec)

• angemessener Umfang und klare Struktur (--> Reviews)

• sortierbar

• qualitativ hochwertig

• vollständig (inkl. Normreferenzen)

• eindeutig und konsistent

• verfolgbar

• modifizierbar und erweiterbar*

• gemeinsam zugreifbar

• optimiert bezüglich Vorgehen

* = IEEE 830-1998


32

Die 3 Dimensionen des RE

Inhalt

vage

vollständigund korrekt

Repräsentationinformell formal

Überein-stimmung

gemeinsameSicht

individuelle Sichten


33

Techniken

Umfrage unter allen Stakeholdern

Verhandlungen bei Unstimmigkeit

Implementierungsprototyp

Prototyp

Automatischer Test von Modellen

Bildung von Modellen

Analyse des Umfelds

Re-Engineering

Generierung von Artefakten


34

Fazit

• Wichtiges Thema

• hohe Komplexität

• es gibt Techniken und Methodik

• es gibt für einiges sogar Werkzeuge

• hoher Anteil persönlicher Skills


35

LiteraturRequirements Engineering für eingebettete Systeme, Klaus Pohl / Ernst Sikora, in: Software Engineering eingebetteter Systeme, Peter Liggesmeyer / Dieter Rombach (Hrsg.), Elsevier, München 2005

Requirements-Engineering und -Management, Chris Rupp & die SOPHISTen, Carl Hanser Verlag, München 2007

Requirements Engineering - A good practice guide, Ian Sommerville & Pete Sawyer, Wiley, Chichester 1997

Systematisches Requirements Management, Christof Ebert, dpunkt Verlag, Heidelberg 2005

Software Requirements & Specifications, Michael Jackson, Addison-Wesley, Harlow 1995

Requirements Engineering, Linda A. Macaulay, Springer, London 1996

Lehrbuch der Software-Technik. Software-Entwicklung, Helmut Balzert, Spektrum Akad. Verlag, Berlin 1996

Uni Freiburg, 24.7.2008Requirements Engineering Dr. D. Fehrer1 Requirements Engineering.

Documents

Transcript of Uni Freiburg, 24.7.2008Requirements Engineering Dr. D. Fehrer1 Requirements Engineering.