RE-1

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
  REErfolgreiches 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 RESoftware
  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 SpezifikationDa
  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
  Prozesseswesentliche Einflußbereiche

Unternehmenskontext
Anwendungsbereich
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 Subprozesse1)
  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/international
  e 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.ErwerbsprozessesF
  olge 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 Benutzernintuitivster Ansatz, da
  Benutzer wissen sollten, was sie vom geplanten
  SW-System haben wollenin 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

• ZielanalyseAusgangspunkt teleologische Sicht
  eines SystemsJedes System besitzt Ziele. Das
  Verhalten eines Systems läßt sich daraus
  erklären, daß das System bestrebt ist, seine
  Ziele zu erreichen.
• Ziel der ZielanalyseVersuch, 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
  KonkretheitFolge Anordnung in einer
  Zielhierarchie mit abstrakten Zielen
  (objectives) an der Spitze und konkreteren
  Subzielen weiter unten. Beispiel einer
  ZielhierarchieZerlegung in Subziele AND oder
  OR VerknüpfungBeziehungen innerhalb einer
  EbeneKonflikt, VerstärkungRandbedingungen
  Constraintslimitieren volle Zielerreichung

Z1
Z2
Z3
Z4
Z6
Z5
Z10
Z9
Z8
Z7
Z11
Z12
Z14
Z13
15
Requirements Engineering - Erwerb

• Beispiel Kontext (Unternehmen)
  Universität Projekt Verwaltung von
  Lehrveranstaltungenabstrakte Ziele Z1..verbesser
  e Studentenservice Z2..erleichtere
  OrganisationSubziele Z3..verkürze
  Wartezeiten Z4..verbessere Zeugniswesen Z5..ve
  reinfache Anmeldungen Z6..biete weniger
  PrüfungenZielkonflikt zwischen Z3, Z6
  Verstärkung von Z3 durch Z5Beispiel für weitere
  Zerlegung in SubzieleZ7..verkürze Wartezeiten
  bei Anmeldungen ANDZ9.. verkürze Wartezeiten auf
  ZeugnisseZ13..verlängere Anmeldefrist OR
  Z14..biete www-AnmeldungDiskutiere Ersetze Z6
  durch vereinfache PrüfungsorganisationConstrain
  t 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 ErwerbSzenario beschreibt
  eine typische Instanz der Interaktionen mit dem
  gewünschten System zur Lösung einer
  Aufgabeeigentlich 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 PrototypenPrototyp
  eingeschränkte Version des künftigen SW-Systems,
  die allgemeine Funktionalität bietetSzenario
  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
  ErwerbKontext Universitätsbibliothek Szenario
  zur Buchentlehnunggt Studentin kommt mit Buch
  in der Hand zum Bibliothekar und ersucht um
  Entlehnunggt Bibliothekar verlangt
  Studentenausweis und gibt die Matrikelnummer
  eingt Der Bibliothekar sieht nach, ob die
  Studentin uneingeschränkte Entlehnrechte hat.
  Falls ja, kann die Inventarnummer des Buches
  eingegeben werden.gt Daraufhin erscheint der
  Buchtitel/Autor und das Fälligkeitsdatum für die
  Entlehnung.gt 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 FormularanalyseAusgangspunkt
  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ätzendirekte nat. spr.
  Interaktion mit BenutzernExtraktion der
  Anforderungen aus nat. spr. Textenmanuelle
  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. Sprachez.
  B. spezielle Anwendung eingeschränkte
  Konstruktionen

24
Requirements Engineering - Erwerb

• manuelle Ansätzehö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, UMLKonstruktion 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 InformationObjekt-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 AnsatzGrund 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 EthnographieEthnographie 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
  beobachtetdies 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 AnforderungenZiel 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 BewertungInformatione
  n 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-orientiert
  e, 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-SystemeKonzeptuelles
  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
  VIPs vergeben werdenPolitiker 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 NFRBeispiele 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 Anforderungenbeschreiben 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 AnforderungenRandbedingungen bezüglich
  des EntwicklungsprozessesBeispiel Verwendung
  von UML, Einhaltung aller relevanten ISO-9000
  Standards
• Externe AnforderungenRandbedingungen bzgl.
  Produkt und/oder Prozeß, resultierend aus der
  ProduktumgebungBeispiel 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

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?

52
Requirements Engineering SpezifikationDeliverab
les 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

53
Requirements Engineering SpezifikationDeliverab
les 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

54
Requirements Engineering SpezifikationDeliverab
les 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

55
Requirements Engineering SpezifikationDeliverab
les im UP - Elaboration

• 4.   Architecture description
• 5.   Updated risk list
• 6.   Project plan for the construction and
  transition phases
• 7.   Completed business case

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.

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

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

59
Requirements Engineering - Validierung

• Requirementsmodelle (RM) sollten auf folgende
  erwünschte Eigenschaften überprüft werden
• Interne KonsistenzEin RM ist intern konsistent,
  wenn keine wider-sprüchlichen Folgerungen daraus
  gezogen werden können.
• EindeutigkeitDas RM darf keine Anforderung
  enthalten, die auf verschiedene Arten
  interpretierbar ist.Beispiel für Mehrdeutigkeit
  IF x and y or z THEN ...
• Externe KonsistenzAussagen des
  Anforderungsmodells müssen mit den entsprechen
  Gegebenheiten der realen Welt (des
  Problembereichs) übereinstimmen. (Vorsicht bei
  Anwendungen mit rasch veränderlichen
  Sachverhalten.)

60
Requirements Engineering - Validierung

• Minimalitätes soll nur gerade das Notwendige
  ausgesagt werdeninsbesondere Vermeiden von
  Überspezifikation, z.B. durch Vorwegnahme von
  EntwurfsentscheidungenBeispiel 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ändigkeitRM 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