Transcript Requirements Engineering

Requirements Engineering
• Ziele dieses Abschnitts:
- Kennenlernen von Requirements Engineering (RE)
Aspekten, die über die rein SW-technische Sicht der
Anforderungsspezifikation (siehe VO SW-Engineering)
hinausgehen. Insbesondere:
Unternehmen: Ziele, Personal, Interaktion;
grober Applikationsbereich (domain);
verschiedene Sichten (Welten) von Anforderungen;
- Kennenlernen verschiedener Ansätze für die Aquisition
von Anforderungen und deren Validierung;
- Motivation für diese breitere Sicht auf das RE.
RE-1
Requirements Engineering
• RE befasst sich mit den Aktivitäten, die darauf ausgerichtet
sind, die exakten Bedürfnisse der Anwender/Betreiber
eines SW-Systems zu verstehen und sie präzise und
eindeutig zu beschreiben, um eine Vorgabe für die weitere
Systementwicklung darzubieten.
• moderne Sicht:
RE stellt die Verbindung (Brücke) dar zwischen:
- der Notwendigkeit/demWunsch nach einer Änderung am
bestehenden System in einem Unternehmen und
- der Technologie, die solch eine Änderung bewirken kann.
Folgerung:
RE kann als eine Möglichkeit des Managements von
Änderungen in einem Unternehmen gesehen werden.
RE-2
Requirements Engineering
• Organisatorische Perspektive auf RE:
Erfolgreiches Management von Änderungen inkludiert:
- ein tiefes Verständnis des momentanen Zustandes;
- eine klare Definition der Änderungen als eine Transition
von der alten (ist) Situation zur neuen (soll) Situation;
- die Implementierung dieser Änderung in Form
neuer/überarbeiteter Systemkomponenten;
- die Integration dieser neuen Implementierung in die
bestehende Umgebung.
RE-3
Requirements Engineering
• Software Engineering Perspektive auf RE:
Software Prozess Modelle (Vorgehensmodelle) beruhen
auf der Erstellung verschiedener Modelle. Der
Erstellungsprozess erfolgt schrittweise und kann als
Transition zwischen Modellen gesehen werden, wobei
leztere so verfeinert/ergänzt werden, dass der semantische
Inhalt erhalten bleibt.
Ausgangsmodell: Requirements Spezifikation;
Da SW ein immaterielles Gut ist, kann sie nicht mit
physischen Attributen beschrieben werden, sondern muss
durch nicht greifbare Konzepte wie Aufgaben,
Arbeitsabläufe, Umgebungen der Benutzung, etc.
charakterisiert werden.
RE-4
Requirements Engineering
• Definition: RE ist der systematische Prozess
der Bestimmung von Anforderungen durch
ein iteratives, ko-operatives Vorgehen
bestehend aus Problemanalyse,
Dokumentation der Erkenntnisse mit
geeigneten Repräsentationstechniken und
der Überprüfung der Gültigkeit des
gewonnenen Verständnisses.
RE-5
Requirements Engineering
• Requirements Spezifikation: Ergebnis des RE Prozesses;
wesentliche Einflußbereiche:
Anwendungsbereich
Funktionale
Anforderungen
Unternehmenskontext
Requirements
Spezifikation
Nicht-funktionale
Anforderungen
RE-6
Requirements Engineering
Zweck der Requirements Spezifikation:
- Kommunikation/Dokumentation des Verständnisses vom
entsprechenden Anwendungsgebiet, Unternehmen und
Zielsystem;
- Teil eines Software-Vertrages;
- Vorlage für den Software Entwurf;
- Referenz für die Evaluierung des Endproduktes,
insbesondere für den Akzeptanztest.
Grundlegende Aspekte des RE (als Basis für RE-Prozess):
- Erwerben des Problemverständnisses (was ist die Aufgabe);
- formalisierte Beschreibung der Problemstellung;
- Erreichen von Zustimmung zu Problem/Problemspezifikation.
RE-7
Requirements Engineering - Prozeß
• RE-Prozeß teilt sich in drei Subprozesse:
1) Erwerb (elicitation); 2) Spezifikation; 3)Validierung
• Skizze eines Frameworks für RE-Prozesse:
(Locopoulos,
Abb. 2.1,S. 21)
RE-8
Requirements Engineering - Erwerb
1) Erwerb von Anforderungen (R. elicitation)
Ziel: Erwerb von Wissen, welches für das Problem relevant
scheint und für die Problemspezifikation verwendbar ist.
• Inputs für den Erwerbsprozess:
- Fachleute des Anwendungsbereichs;
- Literatur/Aufzeichnungen zum Anwendungsbereich;
- existierende SW-Systeme im Anwendungsbereich;
- ähnliche SW-Applikationen in verwandten Bereichen;
- nationale/internationale Standards, die Rahmenbedingungen
für die Software im entsprech. Anwendungsgebiet vorgeben;
- Betroffene/Beteiligte/Sponsoren im groben Umfeld der
Applikation.
RE-9
Requirements Engineering - Erwerb
• Aktivitäten
- Herausfinden der Quellen von Wissen (siehe Inputs);
- Erwerb von Wissen;
- Abwägen der Relevanz der erworbenen Erkenntnisse für
die konkrete Problemstellung;
- Verstehen der Bedeutung des erworbenen Wissens für die
SW-Anforderungen;
• Outputs (“deliverables”) des R.Erwerbsprozesses:
Folge verschiedener Modelle, die durch Validierung zur
verlangten Spezifikation “konvergieren” (siehe Skizze):
(Locoup. Abb. 2.2, S. 23)
RE-10
Requirements Engineering - Erwerb
* Techniken des Erwerbs von Anforderungswissen:
• Erwerb von Benutzern:
intuitivster Ansatz, da Benutzer wissen sollten, “was sie
vom geplanten SW-System haben wollen”;
in der Praxis: oft problematisch aus folgenden Gründen:
- Benutzer wissen nicht genau, was sie vom (neuen) SWSystem erwarten können;
- Benutzern fällt es oft schwer, ihr Wissen/Erfahrung vom
Anwendungsbereich zu beschreiben;
- die Grundlagen und Ziele von Benutzern und Analytikern
differieren und beide verwenden eigene Terminologien;
- Benutzer wollen ggf. keine Änderungen und lehnen daher
jede Kooperation in Richtung eines neuen Systems ab.
RE-11
Requirements Engineering - Erwerb
• Techniken für den Erwerb von Benutzern:
- Brainstorming and collective decision making
(BCDA):
fördert gegenseitiges Verständnis als auch
Konsensfindung;
- offene Interviews: Benutzer erzählen über ihre
Aufgaben;
grobe Sicht über das Anwendungsgebiet wird
geboten;
- strukturierte Interviews: Analytiker stellen
Spezialfragen;
Details zur Anwendung werden erfragt;
RE-12
Requirements Engineering - Erwerb
• Zielanalyse:
Ausgangspunkt: teleologische Sicht eines Systems:
Jedes System besitzt Ziele. Das Verhalten eines
Systems läßt sich daraus erklären, daß das System
bestrebt ist, seine Ziele zu erreichen.
• Ziel der Zielanalyse:
Versuch, Anforderungen in einem breiteren
Kontext zu sehen und Zusammenhänge mit dem
Umsystem zu verstehen.
RE-13
Requirements Engineering - Erwerb
• Ziele variieren in ihrem Grad an Konkretheit;
Folge: Anordnung in einer Zielhierarchie mit abstrakten Zielen
(“objectives”) an der Spitze und konkreteren Subzielen weiter
unten. Beispiel einer Zielhierarchie:
Zerlegung in Subziele:
AND oder OR Verknüpfung;
Beziehungen innerhalb einer Ebene:
Konflikt, Verstärkung;
Randbedingungen: ”Constraints”
limitieren volle Zielerreichung;
Z1
Z3
Z2
Z4
Z5 Z6
Z7 Z8 Z9 Z10 Z11 Z12
Z13
Z14
RE-14
Requirements Engineering - Erwerb
• Beispiel:
Kontext (“Unternehmen”): Universität
Projekt: Verwaltung von Lehrveranstaltungen
abstrakte Ziele:
Z1..verbessere Studentenservice
Z2..erleichtere Organisation
Subziele: Z3..verkürze Wartezeiten
Z4..verbessere Zeugniswesen
Z5..vereinfache Anmeldungen
Z6..biete weniger Prüfungen
Zielkonflikt zwischen Z3, Z6; Verstärkung von Z3 durch Z5
Beispiel für weitere Zerlegung in Subziele:
Z7..verkürze Wartezeiten bei Anmeldungen AND
Z9.. verkürze Wartezeiten auf Zeugnisse;
Z13..verlängere Anmeldefrist OR Z14..biete www-Anmeldung;
Diskutiere: Ersetze Z6 durch: vereinfache Prüfungsorganisation;
Constraint: erforderliches Budget muß gleichbleiben
RE-15
Requirements Engineering - Erwerb
• Schritte bei der Zielanalyse:
- analysiere das Unternehmen und die Umgebung mit der es
interagiert durch Ermittlung von Zielen und constraints;
- stelle Zielhierarchie auf und ermittle Beziehungen zw. Zielen;
- validiere das Modell und erarbeite Konsens darüber (mit wem?)
- finde den für das SW-Projekt relevanten Hierarchie-Ausschnitt;
- eliminiere Konflikte im obigen Ausschnitt durch Verhandeln;
- selektiere Anforderungen/Tasks durch Wahl von Alternativen.
RE-16
Requirements Engineering - Erwerb
• Vorteile der Zielanalyse:
+ SW Anforderungen werden aus den
(dauerhafteren) Unternehmenszielen
abgeleitet;
+ SW Anforderungen und
Unternehmensziele werden in sichtbare
Beziehung gebracht;
+ tiefere Bedeutung des SW-Systems ist
ersichtlich und fördert die Motivation;
RE-17
Requirements Engineering - Erwerb
• Szenario-basierter Erwerb:
Szenario: beschreibt eine typische Instanz der
Interaktionen mit dem gewünschten System zur Lösung
einer Aufgabe;
eigentlich: eine Geschichte darüber, wie das künftige
System die Benutzerwünsche erfüllen soll;
• vergleiche: Use-Cases (UML), Geschäftsfälle;
• Szenarien können durch verschiedenste Medien
beschrieben werden, wie Text, Bilder, Diagramme,
Maskenfolgen...;
RE-18
Requirements Engineering - Erwerb
• Unterschied zu Prototypen:
Prototyp: eingeschränkte Version des künftigen
SW-Systems, die allgemeine Funktionalität bietet;
Szenario: beliebig beschriebene
Interaktionssequenz;
• Vorteile: die intensive Zusammenarbeit mit
Benutzern fördert die soziale Komponente des RE;
kostengünstiger als Prototyping;
RE-19
Requirements Engineering - Erwerb
• Beispiel: Szenario zum szenario-basierten Erwerb:
Kontext: Universitätsbibliothek; Szenario zur
Buchentlehnung:
> Studentin kommt mit Buch in der Hand zum Bibliothekar und ersucht
um Entlehnung
> Bibliothekar verlangt Studentenausweis und gibt die Matrikelnummer
ein;
> Der Bibliothekar sieht nach, ob die Studentin uneingeschränkte
Entlehnrechte hat. Falls ja, kann die Inventarnummer des Buches
eingegeben werden.
> Daraufhin erscheint der Buchtitel/Autor und das Fälligkeitsdatum für
die Entlehnung.
> Der Bibliothekar gibt “Y” auf den “OK” Prompt ein und das Buch gilt
als entlehnt.
RE-20
Requirements Engineering - Erwerb
• Das Szenario wird mit dem Bibliothekar besprochen.
Daraufhin bemerkt dieser, daß er bei jeder Entlehnung
prüft, ob ein Student noch überfällige Bücher entlehnt hat.
Falls ja, wird er darauf angesprochen.
Folgerung: Analytiker nimmt zur Kenntnis, daß:
- Bücher, die ausständig sind, als solche gekennzeichnet
werden müssen;
- alle ausständigen Bücher bei der Entlehnung angezeigt
werden müssen.
RE-21
Requirements Engineering - Erwerb
• Erwerb mittels Formularanalyse:
Ausgangspunkt: Formular: formattierte Kollektion von
Variablen für die Dateneingabe und das Retrieval;
• Formulare sind verläßliche Quellen für Anwendungswissen:
- Formulare sind konsistenter und eindeutiger als
natürlichsprachliche Beschreibungen/Äußerungen;
- wichtige Informationen sind oft in Formularform vefügbar;
- Formulare sind eine beliebte und leicht zugängliche Form der
Organisation von Information für datenintensive Applikationen;
- begleitende Instruktionen zu Formularen bieten eine weitere
Quelle von Wissen über die Anwendung;
- die Formularanalyse kann einfacher automatisiert werden als der
Erweb aus anderen Wissensquellen (wie Text, Skizzen,...).
• Erfolgreiche Automatisierung: Generierung von ER-Modellen.
RE-22
Requirements Engineering - Erwerb
• Erwerb aus Beschreibungen in natürlicher Sprache:
• Kategorien von Ansätzen:
direkte nat. spr. Interaktion mit Benutzern;
Extraktion der Anforderungen aus nat. spr. Texten;
manuelle versus automatisierte Ansätze;
• Vorteile/Nachteile:
- reichhaltiges Vokabular: alles kann ausgedrückt werden;
- Informalität: nicht erwünscht für die endgültige Spezifikation,
jedoch nützlich für frühe Phasen, da durch Ungenauigkeit/
Unvollständigkeit die Komplexität reduziert wird.
• automatisierte Ansätze:
Erfolge nur mit stark eingeschränktem Ausschnitt d. nat. Sprache;
z. B.: spezielle Anwendung; eingeschränkte Konstruktionen;
RE-23
Requirements Engineering - Erwerb
• manuelle Ansätze:
höhere Flexibilität (Verständnis durch Menschen);
Basis: nat. spr. Beschreibungen werden durch
Anwendung von Daumenregeln auf Sprachkonstrukte
hin untersucht, die in die Konstrukte eines Formalismus
umgesetzt werden.
Beispiel: OO Analyse nach Wirfs-Brock, OMT, UML:
Konstruktion des Klassenmodells aus einer nat. spr.
Beschreibung des Systems:
- Substantive der nat. spr. Beschreibung führen zu
Klassenkandidaten;
- Adjektive werden als Attribute entspr. Objekten zugeordnet;
- Verben, Verb-Phrasen und Prädikate dienen der Bestimmung
von Operationen.
RE-24
Requirements Engineering - Erwerb
• Techniken zur Wiederverwendung von Requirements:
• grundlegende Idee: Anforderungen, die schon einmal für
eine Anwendung erfaßt wurden, können für die Spezifikation
einer weiteren, ähnlichen Anwendung wiederverwendet
werden.
• Wiederverwendung von Anforderungen ist attraktiv, da:
- der Erwerbsprozeß eine der aufwendigsten Aktivitäten bei
der SW-Entwicklung ist;
- SW-Systeme dessellben Bereichs weisen einen hohen Grad
an Ähnlichkeit auf. Nur ca. 15% der Anforderungen an ein
neues System sind spezifisch für das System. 85% stimmen
mit Anforderungen an existierende System überein.
RE-25
Requirements Engineering - Erwerb
• Voraussetzungen für die Wiederverwendung von R.:
– Anforderungen an existierende Systeme müssen
leicht zugänglich sein;
– Unterstützung ist erforderlich für das Selektieren
“alter” Anforderungen, das Testen der Eignung
“alter” Anforderungen im Kontext des neuen
Anforderungsmodells sowie Möglichkeiten der
Modifikation/Anpassung;
– all dies muss weniger Kosten als ein vollständig
neuer Erwerbsprozess.
RE-26
Requirements Engineering - Erwerb
• Kategorien von Ansätzen zur
Wiederverwendung von R.:
– Bibliotheken wiederverwendbarer
Anforderungen;
– Reverse Engineering: Techniken zur Erstellung
von Modellen auf höherem Abstraktionsniveau
(Designs, Requ.Spez.) aus Code;
– Domain Analyse (siehe unten);
RE-27
Requirements Engineering - Erwerb
• Domain Analyse für den Erwerb von Anforderungen:
• Domain Analyse (DA) ist der Prozess der Erkennung,
des Erwerbs und der Evolution von
wiederverwendbarer Information über einen
Anwendungsbereich (“domain”).
• Die DA benötigt einen geeigneten
Repräsentationsformalismus zur Darstellung der
wiederverwendbaren Information;
Objekt-orientierte Ansätze sind besonders gut
geeignet!
RE-28
Requirements Engineering - Erwerb
• Inputs der DA: technische Literatur, existierende
SW-Systeme, Expertenunterstützung, etc.
• Outputs: Taxonomie der Konzepte der entsprech.
Domäne, Standards, generische
Systemarchitekturen, Klassenbe-schreibungen,
etc.
• DA und RA haben die gleichen Ziele;
wesentlichster Unterschied: die DA berücksichtigt
Anforderungen von mehr als einer Anwendung;
RE-29
Requirements Engineering - Erwerb
• Schritte im Domain Analyse Prozess:
- Identifikation von Kategorien von Problembereichen, i.e.,
Herausfinden ähnlicher Applikationen;
- Identifikation und Formalisierung jener Konzepte, die
den verschiedenen Applikationen gemein sind;
- Organisation der Konzepte in Bibliotheken mit
wiederverwendbaren Komponenten sowie Unterstützung
des Auffindens und des Zugriffs.
• DA: vielversprechender Ansatz;
Grund: die Ergebnisse der DA vermögen die Effektivität als
auch die Qualität von SW-Projekten signifikant zu erhöhen.
RE-30
Requirements Engineering - Erwerb
• Erwerb mittels Task Analyse (TA):
Die Task Analyse umfasst Techniken zur Analyse und
Beschreibung der Art wie (künftige) Benutzer ihren Job
verrichten anhand von:
- Aktivitäten und deren Strukturierung;
- des zur Ausführung der Aktivitäten benötigten Wissens.
• besonders geeignet für Anforderungen zur Mensch-Maschine
Interaktion;
• Zwei komplementäre Techniken:
- Hierarchische Task Analyse:
– Konstruktion einer
Hierarchie von Tasks und Sub-Tasks und von
– Plänen zur
Beschreibung, in welcher Reihenfolge und unter welchen
Bedingungen Subtasks durchgeführt werden.
RE-31
Requirements Engineering - Erwerb
TASK: Buchentlehnung
0 Um ein Buch zu entlehnen:
1 Verlange den Berechtigungsausweis des Entlehners
1.1 Prüfe die Gültigkeit des Ausweises
1.2 Prüfe die Entlehndaten des Entlehners um
festzustellen, ob die max. Anzahl der zu einem Zeitpunkt zu entlehnenden Bücher nicht überschritten wir
2 Nehme das zu entlehnende Buch vom Entlehner
3 Nehme eine neue Entlehnkarte
3.1 Trage das aktuelle Datum auf der Karte ein
3.2 Trage den Namen des Entlehners auf der Karte ein
...
RE-32
Requirements Engineering - Erwerb
- Wissensbasierte Analyse (Knowledge-based Analysis):
Modellierung von Objekten, Beziehungen und Ereignissen
im Taskbereich;
analog zur Modellierung funktionaler Anforderungen, jedoch
wesentlicher Unterschied: Modellierung von Objekten der
realen Welt unabhängig von einem SW-System.
• - Die Task Analyse kann nicht unmittelbar Anforderungen an
ein SW-System liefern, da sie sich auf ein existierendes
System bezieht und reale, physische Konzepte modelliert
statt jener, die im künftigen SW-System vorkommen.
- Die Task Analyse liefert wertvollen Input für die R.Analyse,
indem sie Organisation/Strukt. von Anwendungswissen liefert.
RE-33
Requirements Engineering - Erwerb
• Der Erwerb von Anforderungen als sozialer
Prozess:
• wesentliche Aspekte:
– Organisationsform/Mitglieder des
Entwicklungsteams;
– Wessen Meinung/Wissen soll eingeholt werden?
“Sichten”;
– Ethnographie als Ansatz des Erwerbs von
Anforderungen;
RE-34
Requirements Engineering - Erwerb
• ad zu befragende Personen (“Stakeholders”):
–
–
–
–
Auftraggeber, Sponsor, Kunde; .. liefert u.a. Finanzen;
Auftragnehmer, Projektleiter & Projektteam, Experten;
Verantwortliche für die Einführung/Schulung;
künftige Benutzer des Systems: direkt Betroffene
häufige und seltene Benutzer;
– indirekt Betroffene: z.B. Kunden einer Firma, die das
zu erstellende SW-System verwendet;
• Veranstaltung von Workshops mit Mitgliedern
aller Gruppen zur kooperativen Erforschung der
Anforderungen.
RE-35
Requirements Engineering - Erwerb
• ad Ethnographie:
Ethnographie: von Anthropologen entwickelte
Methode zur Erforschung der sozialen Mechanismen
von Naturvölkern.
• Basis: Beobachtung des Verhaltens von
Gruppenmitgliedern;
• Übertragung auf die Anforderungsanalyse:
– statt (oder besser neben!) der Taskanalyse werden die Arbeitspraktiken
in einem Unternehmen sowie künftige Benutzer über längere Zeiträume
beobachtet;
dies liefert Verständnis für die zu erfüllenden Aufgaben und insbesonde
deren Zusammenwirken/Verteilung/Abfolge.
RE-36
Requirements Engineering - Erwerb
• Vorteil: es werden keine vorgefaßten Lösungen
auferlegt, sondern aus dem Funktionieren eines
Unternehmens abgeleitet. Folge: bessere
Verwendbarkeit und Akzeptanz, insbesondere bei
stark kooperativen Aufgabenstellungen.
• Nachteil: extrem zeitaufwendig; noch im
Forschungsstadium;
RE-37
Requirements Engineering - Spezifikation
2) Spezifikation von Anforderungen:
Ziel: Modell als Kernpunkt des SW-Vertrages als auch als
Ausgangspunkt für die weitere Entwicklung;
• Inputs:
- Wissen um die Anwendung;
- Wissen über den Unternehmenskontext;
- Resultate des Validierungsprozesses (zwecks
Aktualisierung); z.B.: Prototypen und deren Bewertung;
Informationen kommen in “Rohform” und müssen in
geeignete Repräsentationen umgesetzt werden.
• Aktivitäten:
- Analyse und Anpassung von Anforderungswissen;
- Synthese und Organisation des Wissens in einem
kohärenten, konzeptuellen Modell.
RE-38
Requirements Engineering - Spezifikation
• Outputs:
- Anwender-orientierte Modelle zwecks Kommunikation
zwischen Auftraggebern, Entwicklern und Benutzern;
- Entwickler-orientierte, formale Modelle als Vorlage für
die weitere SW-Entwicklung.
• traditionelle Sicht: Konzentration auf die Modellierung
funktionaler Anforderungen (Funktionen und Daten);
Genaueres siehe z.B. Software Engineering I, DB-Systeme;
Konzeptuelles Schema als Vorlage für den DB-Entwurf;
• breitere Sicht zur Verbesserung der R. Analyse umfaßt:
- Konzeptuelle Modellierung der “4 Welten” (vgl. Einführung);
- Modellierung von Unternehmen und deren Zielen sowie Ermöglichung der Rückverfolgung (tracing) von Anforderungen;
- “formale(re)” Modellierung nicht-funktionaler Anforderungen;
RE-39
Requirements Engineering - Spezifikation
• Konzeptuelle Modellierung:
- formale Beschreibung des “Universe of Discourse”
durch verschiedene graphische und textuelle Repräsentationen;
- Motivation: Kommunikation der Semantik der Applikation,
daher: kognitive Ausrichtung; i.a. implementationsunabhängig;
- allgemeine Formalismen (z.B. OO-Modellierung) eignen sich
für alle Welten;
Beispiel: OO-Modell der Anwendung (System World) und
OO-Modell der Notationselemente und des Prozesses (“MetaModell” der Development World) können mit derselben
Methode erstellt werden.
- spezielle Formalismen: für spezielle Aspekte; z.B. formales
Modell mit “Z”; Zielhierarchie; Benutzermodell; etc.
RE-40
Requirements Engineering - Spezifikation
• Modellierung von Unternehmen (Teil der Subject World);
• Motivation:
- breitere Sicht, z.B. durch Berücksichtigung der Sichten
verschiedener Rollen;
- tiefere Fundierung des Bedarfs am System und
- fundiertere Beurteilung von Alternativansätzen z.B.
durch Kenntnis der Unternehmentziele;
• typische Modellierungsaspekte eines Unternehmensmodells:
- Organisationsstrukturen (siehe “institutionelles PM”);
- Instanzen, Stellen, Aktoren (Rollen) (z.T. auch inst. PM);
- Unternehmensphilosophie und Ziele;
- Aktivitäten, Prozesse (Geschäftsabläufe), Produkte
RE-41
Requirements Engineering - Spezifikation
• Beispiel: verschieden Ansichten zur Aufgabe der
Kartenreservierung bei einem Flugliniensystem:
- Direktor:
“ Wenn ein Flug ausgebucht ist, sollen frei werdende
Plätze mit höchster Priorität an VIP’s vergeben werden;”
“Politiker sollen Vergünstigungen bekommen, da diese
Entscheidungen treffen, die die Fluglinie betreffen.”...
- Sicherheitsbeauftragter:
“ Die Anzahl der Gepäckstücke im Laderaum muß mit der
dafür vergebenen Anzahl der Etiketten übereinstimmen.”
“ Die Liste der Fluggäste soll nicht veröffentlicht werden.”...
- Verkaufsmanager:
“ Ein Ticket darf erst ausgehändigt werden, wenn der
Flugpreis bezahlt ist”; ...
• Anforderungen aus allen Sichten müssen integriert werden!
RE-42
Requirements Engineering - Spezifikation
• Modellierung der Unternehmensziele (siehe auch “Erwerb”)
• Hypothese:
Die Modellierung/Analyse von Unternehmenszielen führt
schrittweise zu besseren, d.h. fundierteren, vollständigeren,
passenderen funktionalen und nicht-funktionalen Anforderungen;
• weitere Motivation:
- Hilfestellung beim Erwerb von Anforderungen und bei Fällen
von Entwurfsentscheidungen, da der Zweck, dem das System
im Unternehmen dienen soll, explizit ersichtlich ist;
- Unterstützung der Konfliktresolution;
- Zielgraph ermöglicht “requirements traceability”;
allgem.: Verfolgung von R. zwischen Ursprung und Code;
hier: Rückverfolgung der Anforderungen bis zu ihrem Ursprung
zwecks Rechtfertigung der Inklusion von Systemkomponenten.
RE-43
Requirements Engineering - Spezifikation
• Modellierung nicht-funktionaler Anforderungen
(NFR):
• Charakteristika von NFR:
– NFR sind Bedingungen, die an die Dienste bzw.
Leistungen eines Systems gestellt werden.
– NFR beschreiben Systemeigenschaften und
Randbedingungen, unter welchen das System
arbeitet bzw. entwickelt/gewartet wird.
RE-44
Requirements Engineering - Spezifikation
• Funktionale- und NF Anforderungen stehen
miteinander in Beziehung, oft auch in Konflikt.
Bsp.: Festlegung der max. Antwortzeiten je
Transaktionsklasse;
• NFR können sich gegenseitig positiv oder negativ
beeinflussen, oder sie können neutral sein.
Beispiele:
– pos. Beziehung: Erweiterbarkeit, Änderbarkeit;
– neg. Beziehung: Speicher- versus Laufzeiteffizienz;
RE-45
Requirements Engineering - Spezifikation
• Richtlinien für die Spezifikation von NFR:
– NFR müssen so spezifiziert werden, dass sie überprüfbar
(testbar) sind;
Folgerung: NFR bedürfen einer Einordnung in eine Metrik!
– Spezifikation von NFR
• eigener Abschnitt der Requirements Spezifikation, oder
• begleitend zur Spezifikation entsprechender funktionaler
Anforderungen;
• empfehlenswert: Matrix zur Zuordnung von funktionalen- und NFR
– Formalisierungsansätze
• Metriken zur Evaluierung des Endprodukts (siehe umseitig) und
• Prozess-orientierte Ansätze (siehe Ende dieses Abschnitts).
RE-46
Requirements Engineering - Spezifikation
• Meßbarkeit/Testbarkeit von NFR:
Beispiele für Metriken:
Eigenschaft
Metrik
Geschwindigkeit
Anzahl der Transaktionen pro Sekunde
Antwortzeit bezüglich eines Ereignisses
Zeit für Auffrischung des Bildschirms
Größe
Kbytes
Anzahl der RAM Chips
Einfache Bedienbarkeit
Zeit für das Erlernen
Anzahl von Help-Frames
Zuverlässigkeit
mittlere Fehlerrate
Wahrscheinlichkeit des Systemstillstandes
Ausfallsrate
Betriebsbereitschaft
Robustheit
Zeit für das Hochfahren nach Ausfall
Prozent von Ausfall verursachenden
Ereignissen
Wahrscheinlichkeit des Datenverlustes bei
Ausfall
Portabilität
Prozent von zielabhängigen Zuständen
Anzahl der Zielsysteme
RE-47
Requirements Engineering - Spezifikation
Klassifikation von NFR ( in Anlehnung an Sommerville 1992):
NFR
Prozessbereich:
- Entwicklungsmethode
- Implementierungsumgebung
- Vorgehensmodell
- Prozeßdokumentation
- etc.
Produktbereich:
- Integration
- Performanz
- Kapazität
- Sicherheit
- Erweiterbarkeit
- etc.
Externe Faktoren:
- Soziale Faktoren
- Wirtschaftl. Faktoren
- Fakt. aus SW-Vertrag
- Politische Faktoren
- Gesetze
- etc.
RE-48
Requirements Engineering - Spezifikation
• Produkt Anforderungen:
beschreiben jene Eigenschaften, die das System oder ein
Subsystem besitzen muß;
Beispiel (für meßbare Formulierung): Die Kapazität des
Speichermediums zur Erfassung der Temparatur-Sensordaten
soll so hoch sein, daß Werte für eine Woche ohne manuellen
Eingriff (z.B. Bandwechsel) gespeichert werden.
• Prozess Anforderungen:
Randbedingungen bezüglich des Entwicklungsprozesses;
Beispiel: Verwendung von UML, Einhaltung aller relevanten
ISO-9000 Standards;
• Externe Anforderungen:
Randbedingungen bzgl. Produkt und/oder Prozeß,
resultierend aus der Produktumgebung;
Beispiel: Mietrechtsgesetz; Betriebsratsregelung;...
RE-49
Requirements Engineering - Spezifikation
• Formalisierung von NFR: Prozess-orientierter Ansatz:
• Grundlegende Idee: Entwurfsentscheidungen werden aufgrund
von NFR gefällt; NFR rechtfertigen Entscheidungen;
• grundlegende Überlegungen:
- Die Erfüllung eines NFR kann als Ziel gesehen werden.
- einzelnen Zielen werden Prioritäten zugeordnet;
- jede Entwurfsentscheidung begünstigt/benachteiligt
bestimmte NFR;
- Entwurfsentscheidungen werden so gefällt, daß die Ziele mit
hohen Prioritäten vorzüglich angestrebt werden.
• technische Grundlagen: Zielhierarchien, AND/OR Bäume,
Konfliktresolutionstechniken,...
• Vorteil: konstruktive Maßnahme
RE-50
Requirements Engineering – Spezifikation
Position im Unified Process
• Der Requirements Workflow wird in der Inception
und der Elaboration Phase am stärksten verfolgt.
• Inkrementelles, iteratives Hinzunehmen und
Spezifizieren von Anforderungen, in erster Linie
anhand von Use-Cases
• Streben nach erstem Architekturskelett
• Feature list mit “supplementary requirements“
• Spezielle Web-Features sind im UP nicht
berücksichtigt. zu diskutieren: Welche?
RE-51
Requirements Engineering – Spezifikation
Deliverables im UP - Inception
1.
2.
3.
Feature List
Business or Domain Model
First Cut of
a. Use-Case Model
b. Analysis Model
c. Design Model
4.
5.
optionally: Implementation/Test model
supplementary requirements
RE-52
Requirements Engineering – Spezifikation
Deliverables im UP - Inception
6.
7.
8.
9.
10.
11.
First draft of candidate architecture
description with views of individual models
Optional: proof-of -concept prototype
Initial risk list
Use-Case ranking list
Beginnings of a plan for the entire project
First draft of business case
RE-53
Requirements Engineering – Spezifikation
Deliverables im UP -Elaboration
1. Preferably a complete business (or domain)
model which describes the context of the
system
2. New version of all models (complete
between 10% - 80%):
- use-case
- analysis
- design
- deployment, implementation
3. executable architectural baseline
RE-54
Requirements Engineering – Spezifikation
Deliverables im UP - Elaboration
4. Architecture description
5. Updated risk list
6. Project plan for the construction and
transition phases
7. Completed business case
RE-55
Requirements Engineering - Validierung
• Manuelle und automatisierte (CASE-Tools) Überprüfungen
helfen, eine weitgehend korrekte R.Spezifikation zu produzieren.
• Verbleibende Problematik:
Ein korrektes Anforderungsmodell ist nicht notwendigerweise
das richtige Anforderungsmodell!
• Resultierende Fragestellung für die Validierung von R.:
Lösen wir das richtige Problem? denn:
- Es gibt nichts Greifbares, worauf sich die Überprüfung stützen
kann. Die Anforderungen stecken in den Köpfen div. Personen.
- Benutzer wissen oft nicht, was sie benötigen bzw. was
das Beste für sie wäre, bzw. was überhaupt möglich ist.
RE-56
Requirements Engineering - Validierung
• Folgerungen: Die Richtigkeit einer
R.Spezifikation kann formal nicht nachgewiesen
werden. Es werden Wege gesucht, wie man sich
über die Gültigkeit der R.Spezifikation
vergewissern kann.
• Web-basierte Systeme – vgl. Use-Case Storyboard,
Creative Design Techniken
• Grundsatz: Je länger die Validierung
hinausgeschoben wird, umso kostspieliger werden
Fehlerkorrekturen.
RE-57
Requirements Engineering - Validierung
• Mögliche Ansätze/Techniken für die Validierung von
Anforderungsmodellen:
- Überprüfung (manuell, CASE-Tool, Logik) auf eine Menge
erwünschter Eigenschaften des Modells;
- Reviews, gemeinsam mit Benutzern;
- Vergleich mit /Wiederverwendung von Modellen ähnlicher
Anwendungen;
- Erfahrungen aus früheren Projekten;
- Prototyping; Diskussion der Prototypen mit Benutzern;
- Animation, Simulation;
- “Natural language Paraphrasing”;
- Unterstützung durch Expertensysteme.
RE-58
Requirements Engineering - Validierung
• Requirementsmodelle (RM) sollten auf folgende
erwünschte Eigenschaften überprüft werden:
• Interne Konsistenz:
Ein RM ist intern konsistent, wenn keine widersprüchlichen Folgerungen daraus gezogen werden können.
• Eindeutigkeit:
Das RM darf keine Anforderung enthalten, die auf
verschiedene Arten interpretierbar ist.
Beispiel für Mehrdeutigkeit: IF x and y or z THEN ...
• Externe Konsistenz:
Aussagen des Anforderungsmodells müssen mit den
entsprechen Gegebenheiten der realen Welt (des
Problembereichs) übereinstimmen. (Vorsicht bei
Anwendungen mit rasch veränderlichen Sachverhalten.)
RE-59
Requirements Engineering - Validierung
• Minimalität:
es soll nur gerade das Notwendige ausgesagt werden;
insbesondere: Vermeiden von Überspezifikation, z.B. durch
Vorwegnahme von Entwurfsentscheidungen;
Beispiel zur Überspezifikation: Wenn die Temparatur von 200° C
überschritten ist, soll der Masterkontroller Modul eine Nachricht
an den Ventilkontroller senden, der eine FIFO-Queue zur
Speicherung solcher Nachrichten verwendet. ..
• Vollständigkeit:
RM muß alle Informationen über den Problembereich umfassen,
die zur Erfüllung der Bedürfnisse der Benutzer benötigt werden.
- automatisierte Checks von Aspekten wie fehlende Definitionen;
- schwer prüfbar: fehlende Ziele, Constraints, Fakten, etc.
wertvoll dazu: Prototyping;
RE-60