Requirements Engineering

transcript

Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer

2Dr. D. Fehrer

Phasen der SW-Entwicklung (nach Balzert)

Planung

Definition

Entwurf

Implementierung

Abnahme &Einführung

Wartung &Pflege

Wasserfall-Modell

System-Anforderungen

Software-Anforderungen

Analyse

Entwurf

Codierung

Testen

Betrieb

V-Modell 97 (grob)

Anforderungs-definition

Modul-test

Implemen-tation

Integrations-test

Fein-entwurf

Grob-entwurf

System-test

Abnahme-test

Anwendungsszenarien

Testfälle

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

Motivation

Spezifikation Entwurf Codierung Test Abnahme Betrieb

Relative Fehlerbehebungskosten

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

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?)

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)

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)

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

Zur Terminologie

• Klassische Bezeichnung:Requirements Analyse

• legt traditionelles Phasenmodell nahe

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

Schwierigkeiten der Analyse

• Aufwand der Dokumenterstellung(Automatisierung!)

• inadäquate Methodik(lernen!)

• unterschiedliche Sprachen(graphisch!)

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

Analyse

• ist schwierig: heterogene Personengruppen mit unterschiedlichen Zielvorstellungen

• ist frustrierend!

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

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.“

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!!!

Die Realität

• Oftmals nur vage Produkt- / Lösungsidee

• unterschiedlichste Vorstellungen der verschiedenen Entscheider („stakeholder“)

Konsequenzen„erarbeiten“ statt nur „aufdecken“

(Requirements Engineering!) gegenüberstellen und gewichten

(Priorisierung) laufend anpassen

(Requirements Management) und frühzeitig spiegeln

(ablauffähige Modelle?)

Lösung 2: iterative Entwicklung (Spiralmodell) Test

Design

• hohe Flexibilität

• rasches Feedback

• risikobasiert

• gute Erfolgskontrolle der einzelnen (Zwischen-)Ergebnisse

• kein „Hellsehen“ nötig

Minus:

• schlecht langfristig planbar

• schlechte Gesamt-Fortschrittskontrolle

Requirements Engineering

documentingdiscovering maintaining

Vgl. Sommerville&Sawyer

eliciting modelling communicating agreeing evolving

Vgl. Nuseibeh&Easterbrook

Aktivitäten im RE• Anforderungsgewinnung (Elicitation)

• Verhandlung (Negotiation)

• Spezifikation (inkl. Dokumentation)

• Validierung / Verifikation

• Management– Change– Versionierung– Tracing

Vorgehen

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

• betroffene Benutzer identifizieren

• Interviews

• Diagramme erstellen

• Walkthroughs mit Nutzern (Validierung)

• Veröffentlichung des Resultats

„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

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

Ideale Eigenschaften von Anforderungsmodellen

• graphisch

• hierarchisch

• streng

• wartbar

• iterativ

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

Arten von Anforderungsmodellen:

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

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

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

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.

Arten von Anforderungen

• Funktionale Anforderungen

• Design-Anforderungen (!)

• Schnittstellen-Anforderungen

• Performance-Anforderungen

• Physikalische Anforderungen

• Qualitätsattribute

Beispiele für eingebettete Systeme

Funktion Performanz Qualität

Latenz

Sicherheit (safety)

Zuverlässigkeit

VerfügbarkeitEnergieverbrauch

Timing

Wartbarkeit

Messwertdarstellung

Parametrierung

Messen

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

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

Die 3 Dimensionen des RE

Inhalt

vollständigund korrekt

Repräsentationinformell formal

Überein-stimmung

gemeinsameSicht

individuelle Sichten

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

• Wichtiges Thema

• hohe Komplexität

• es gibt Techniken und Methodik

• es gibt für einiges sogar Werkzeuge

• hoher Anteil persönlicher Skills

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

Requirements Engineering

Documents