Requirements Engineering

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.

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

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

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

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

6. Requirements Engineering • Requirements Spezifikation: Ergebnis des RE Prozesses;wesentliche Einflußbereiche: Anwendungsbereich Unternehmenskontext RequirementsSpezifikation FunktionaleAnforderungen Nicht-funktionaleAnforderungen

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

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)

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.

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

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

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

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

14. 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 Z2 Z3 Z4 Z5 Z6 Z7 Z8 Z9 Z10 Z11 Z12 Z13 Z14

15. Requirements Engineering - Erwerb • Beispiel: Kontext (“Unternehmen”): Universität Projekt: Verwaltung von Lehrveranstaltungenabstrakte Ziele: Z1..verbessere Studentenservice Z2..erleichtere OrganisationSubziele: Z3..verkürze Wartezeiten Z4..verbessere Zeugniswesen Z5..vereinfache Anmeldungen Z6..biete weniger PrüfungenZielkonflikt 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

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

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

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

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

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

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

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.

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

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.

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

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

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

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

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

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

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

32. Requirements Engineering - Erwerb 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...

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

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

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

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

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

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.

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;

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

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

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

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

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

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

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

47. Requirements Engineering - Spezifikation • Meßbarkeit/Testbarkeit von NFR:Beispiele für Metriken:

48. Requirements Engineering - Spezifikation 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

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

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