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

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.

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.

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.

Requirements Spezifikation: Ergebnis des RE Prozesses; wesentliche Einflußbereiche: Anwendungsbereich Unternehmenskontext Requirements Spezifikation Funktionale Anforderungen Nicht-funktionale Anforderungen

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.

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)

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.

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)

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.

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;

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.

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 Z5 Z6 Z7 Z8 Z9 Z10 Z11 Z12 Z13 Z14

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

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.

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;

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

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;

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.

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.

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.

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;

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.

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.

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.

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

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!

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;

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.

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.

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 Zeit- punkt 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 ...

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

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;

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.

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.

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;

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.

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;

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.

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

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!

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.

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.

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;

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

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

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

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

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

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?

2. Business or Domain Model 3. First Cut of
Requirements Engineering – Spezifikation Deliverables im UP - Inception 1. Feature List 2. Business or Domain Model 3. First Cut of a. Use-Case Model b. Analysis Model c. Design Model 4. optionally: Implementation/Test model 5. supplementary requirements

Requirements Engineering – Spezifikation Deliverables 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

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

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

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.

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.

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.

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

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;

Requirements Engineering

Ähnliche Präsentationen

Präsentation zum Thema: "Requirements Engineering"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Requirements Engineering

Ähnliche Präsentationen

Präsentation zum Thema: "Requirements Engineering"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback