RE-1 Requirements Engineering Ziele dieses Abschnitts: - Kennenlernen von Requirements Engineering (RE) Aspekten, die über die rein SW-technische Sicht

RE-1

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


• 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-3


• 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-4


• 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-5


• 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-6


• Requirements Spezifikation: Ergebnis des RE Prozesses;wesentliche Einflußbereiche:

RequirementsSpezifikation

FunktionaleAnforderungen

Nicht-funktionaleAnforderungen

UnternehmenskontextAnwendungsbereich

RE-7


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

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

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


• 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-11


* 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) SW- System 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-12


• 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-13


• 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-14


• 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 Z2

Z3 Z4 Z6Z5

Z10Z9Z8Z7 Z11 Z12

Z14Z13

RE-15


• Beispiel: Kontext (“Unternehmen”): UniversitätProjekt: Verwaltung von Lehrveranstaltungen

abstrakte Ziele: Z1..verbessere StudentenserviceZ2..erleichtere Organisation

Subziele: Z3..verkürze WartezeitenZ4..verbessere ZeugniswesenZ5..vereinfache AnmeldungenZ6..biete weniger Prüfungen

Zielkonflikt zwischen Z3, Z6; Verstärkung von Z3 durch Z5Beispiel für weitere Zerlegung in Subziele:Z7..verkürze Wartezeiten bei Anmeldungen ANDZ9.. 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-16


• 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-17


• 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-18


• 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-19


• 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-20


• 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-21


• 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-22

Requirements Engineering - Erwerb• Erwerb mittels Formularanalyse:

Ausgangspunkt: Formular: formattierte Kollektion vonVariablen 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-23


• 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-24

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


• 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-26


• 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-27


• 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-28


• 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-29


• 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-30


• 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-31


• 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-32


TASK: Buchentlehnung

0 Um ein Buch zu entlehnen:

1 Verlange den Berechtigungsausweis des Entlehners1.1 Prüfe die Gültigkeit des Ausweises1.2 Prüfe die Entlehndaten des Entlehners um

festzustellen, ob die max. Anzahl der zu einem Zeit-punkt zu entlehnenden Bücher nicht überschritten wir

2 Nehme das zu entlehnende Buch vom Entlehner

3 Nehme eine neue Entlehnkarte3.1 Trage das aktuelle Datum auf der Karte ein3.2 Trage den Namen des Entlehners auf der Karte ein...

RE-33


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


• 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-35


• 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-36


• 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-37


• 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-38

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

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 Er- möglichung der Rückverfolgung (tracing) von Anforderungen;- “formale(re)” Modellierung nicht-funktionaler Anforderungen;

RE-40


• 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 (“Meta- Modell” 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-41


• 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-42


• 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-43


• 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-44


• 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-45


• 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-46


• 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-47


• Meßbarkeit/Testbarkeit von NFR:Beispiele für Metriken:

Eigenschaft Metrik

Geschwindigkeit Anzahl der Transaktionen pro SekundeAntwortzeit bezüglich eines EreignissesZeit für Auffrischung des Bildschirms

Größe KbytesAnzahl der RAM Chips

Einfache Bedienbarkeit Zeit für das ErlernenAnzahl von Help-Frames

Zuverlässigkeit mittlere FehlerrateWahrscheinlichkeit des SystemstillstandesAusfallsrateBetriebsbereitschaft

RobustheitZeit für das Hochfahren nach AusfallProzent von Ausfall verursachendenEreignissenWahrscheinlichkeit des Datenverlustes beiAusfall

Portabilität Prozent von zielabhängigen ZuständenAnzahl der Zielsysteme

RE-48


Klassifikation von NFR ( in Anlehnung an Sommerville 1992):

Prozessbereich: Produktbereich: Externe Faktoren:

- Entwicklungsmethode - Integration - Soziale Faktoren

- Implementierungs- - Performanz - Wirtschaftl. Faktoren

umgebung - Kapazität - Fakt. aus SW-Vertrag

- Vorgehensmodell - Sicherheit - Politische Faktoren

- Prozeßdokumentation - Erweiterbarkeit - Gesetze

- etc. - etc. - etc.

NFR

RE-49


• 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-50


• 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-51

Requirements Engineering – SpezifikationPosition 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-52

Requirements Engineering – SpezifikationDeliverables im UP - Inception

1. Feature List2. Business or Domain Model3. First Cut of

a. Use-Case Modelb. Analysis Modelc. Design Model

4. optionally: Implementation/Test model5. supplementary requirements

RE-53

Requirements Engineering – SpezifikationDeliverables im UP - Inception

6. First draft of candidate architecture description with views of individual models

7. Optional: proof-of -concept prototype

8. Initial risk list

9. Use-Case ranking list

10. Beginnings of a plan for the entire project

11. First draft of business case

RE-54

Requirements Engineering – SpezifikationDeliverables 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-55

Requirements Engineering – SpezifikationDeliverables im UP - Elaboration

4. Architecture description

5. Updated risk list

6. Project plan for the construction and transition phases

7. Completed business case

RE-56

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


• 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-58


• 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-59

Requirements Engineering - Validierung• Requirementsmodelle (RM) sollten auf folgende erwünschte

Eigenschaften überprüft werden:• Interne Konsistenz:

Ein RM ist intern konsistent, wenn keine wider-sprü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-60


• 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;

Documents

RE-1 Requirements Engineering Ziele dieses Abschnitts: - Kennenlernen von Requirements Engineering (RE) Aspekten, die über die rein SW-technische Sicht