Wissen > 6. Requirements Engineering
6. Requirements Engineering
Einleitung
Requirements Engineering ist die Methode, die Anforderungen, besser
gesagt die Kundenwünsche, an ein zu entwickelndes System herauszufinden.
Hierbei geht es jedoch nicht um die Implementierung, sondern lediglich
um Kundenwünsche und Machbarkeit. RE ist ein spezieller und eigenstängier
Bereich im Software-Life-Cycle des Software Engineering.
|
|
Abbildung 1:Problematik der Anforderungsanalyse
[HOM83] |
Begriffsdefinition
Die Bezeichnung "Reqirements Engineering" hat zwei, wenn auch deutlich
verwandte, so doch wohl zu unterscheidende Bedeutungsvarianten. Der Begriff
steht einmal für alle konkreten Aktivitäten am Beginn eines Softwareprojektes,
die auf eine Präzisierung der Problemstellung abzielen, aber ebenso
auch für eine ganze Teildisziplin der Informatik. Die beiden Definitionen
dazu lauten wie folgt:
- Das Requirements-Engineering ist eine methodische Komponente
des Software-Engineering zur Ermittlung der Anforderungen an ein zu entwickelndes
System. Es umfasst das Zusammenstellen, Gliedern und Abgleichen aller Anforderungen,
sowie das Erstellen von Erklärungsmodellen mit denen die Anforderungen
definiert und präzisiert werden.[HOF00]
- Requirements Engineering ist die ingenieurmäßige Ermittlung
der Anforderungen an die Automatisierung eines Systems und ihrer Aufarbeitung
zur Realisierung in Hardware und Software.[HOM83]
Um die Definitionen besser verstehen zu können, definieren wir
zusätzlich den Begriff Requirements:
Requirements (deut.: Anforderungen) sind funktionale und qualitative
Eigenschaften, die ein zu entwickelndes System erfüllen soll. Man teilt
sie häufig in Muss- und Wunschanforderungen. Sie beschreiben in ihrer
Gesamtheit einen technisch funktionalen Rahmen und Qualitätskriterien
dem ein entwickeltes System genügen muss.[HOF00]
Geschichtlicher Hintergrund
RE ist schon seit den Anfängen des SE eine Teildisziplin desselbigen.
Jedoch wurde Mitte der 70-er Jahre RE aus dem Softwareprozess ausgegliedert
und als ein eigenes Aufgabengebiet unter einem eigenen Namen definiert.
Grund dieser Ausgliederung war die damals herrschende Softwarekrise.
Man musste feststellen, das Wichtigste bei der Softwareherstellung war
die Spezifizierung der Frage "Was macht man?", und die Interaktion zwischen
Hersteller und Kunde. Man merkte, dass unvollständige oder inkonsistente
Anforderungen in sehr hohem Maße die Qualität der Software beeinträchtigte.
Das Ändern der Anforderungen am Ende eines Projektes nahm ca. 200 mal
mehr Zeit in Anspruch, als während des nun sogenannten RE. Folgende
zu dieser Zeit durchgeführten Studien beweisen dies noch deutlicher:
Zum Beispiel fand man heraus, dass die Sicherheitsfehler bei den Nasa-Programmen
Voyager und Galileo auf die schlechte Spezifizierung der Anforderungen zurückzuführen
waren. Oder laut einer Umfrage, die in Europa in 17 Ländern an 3800
Firmen durchgeführt wurde, lagen die größten Probleme bei
der Softwareentwicklung in den Bereichen Requirements-Specification (>50%)
und Requirements-Management (50%).[LAM00]
Während der gesamten Zeit hat man nun versucht, einerseits verschiedene
Techniken zu erfinden, andererseits Techniken aus anderen Gebieten der
Informatik zu verwenden, die den RE-Prozeß vereinfachen könnten.
Anfänglich verwendete man sog. SADT-Diagramme (Structured Analysis
and Design Technique), um den Prozeß formal zu beschreiben. In weiterer
Folge hielten dann verschiedene Verfahren, wie ISDOS (Information System
Design and Optimization System) oder GIST (deut. das Wesentliche, die Essenz)
Einzug im RE-Prozeß. In Ahnlehnung an die Entwicklung der unterschiedlichen
Prograammierkonzepte, wurden auch beim RE ab Mitte der 80-er Jahre das Hauptaugenmerk
auf objekt-orientierte Techniken gelegt. So fanden Beschreibungssprachen,
wie RML (Requirements Modeling Language) oder OMT (Object Modeling Technique)
ihre Anwendung in der Anforderungsanalyse. In den letzten Jahren wurde hauptsächlich
UML (Unified Modeling Language) [UML] verwendet.
Im Zuge dieser Entwicklung haben viele Firmen eigene Techniken entwickelt,
die sie (nur) in ihrem Unternehmen einsetzen. Deshalb gibt es eine Vielzahl
an unterschiedlichen Methoden der Modellierung des RE-Prozesses, von denen
man jedoch nicht sagen kann, dass eine besser oder schlechter als eine
andere ist. Jede hat im Speziellen ihre Vor- und Nachteile.
Dadurch, dass RE eine sehr junge Disziplin ist, werden laufend neue
Techniken und Methoden entwickelt, sogar die genaue Begriffsdefinition
und Abgrenzung des RE-Prozesses ist noch nicht abgeschlossen.
Konzepte
Der RE-Prozess um eine Spezifikation für ein Problem zu erhalten,
besteht grundsätzlich aus drei Phasen: Elicitation, Modeling und Validation
bzw. Verification.
- Elicitation (deut. Hervorhebung) beschäftigt sich mit dem
Verstehen des Problems und seines Umfeldes, durch Erfassen bzw. Herausfiltern
der relevanten Informationen, die notwendig sind um das Problem zu spezifizieren.
- Modeling (deut. Modellierung) strukturiert die Daten, die während
der 1. Phase herausgefunden wurden.
- Validation/Verification (deut. Validierung/Verifikation): Bei
der Validierung wird überprüft, ob das zuvor erstellte Model
die Anforderungen des Kunden erfüllt. Die Verifikation untersucht
die Spezifikation auf Konsistenz, d. h. ob Widersprüche auftreten.
Hat man nun bei der letzten Phase festgestellt, dass Inkonsistenzen auftreten,
oder dass Anforderungen des Kunden falsch aufgefasst wurden, beginnt der
ganze Prozess wieder von vorne. Man ändert nun die Daten, die für
die Elicitation relevant sind, beginnt neu zu modellieren, und überprüft
diese dann neuerdings. Diese Schritte werden solange durchgeführt,
bis ein Konsens zwischen Kundenanforderungen und erstelltem Modell erreicht
wird. Abbildung 1 zeigt dies grafisch:
Für jede Phase wurden spezielle Techniken entwickelt, die im folgenden
vorgestellt werden.
Techniken
Techniken für Elicitation
Es gibt dutzende Techniken, um Informationen vom Kunden über die
Problemstellung zu erhalten. Um den Rahmen nicht zu sprengen, stellen wir
nun die wichtigsten und bekanntesten Techniken vor:
Interview
Beim Interview werden gezielt Fragen an den Kunden gestellt, um dessen
Vorstellungen vom fertigen Produkt herauszufinden. Hier kann man speziell
auf die Antworten des Kunden eingehen, und somit die Wünsche ganz
genau spezifizieren. Das Interview ist die am meisten genutzte Technik,
da sie nicht starr (wie zum Beispiel ein Fragebogen) ist, sondern Dynamik
zulässt. Man kann ad hoc die Fragen an den Kunden anpassen.
Fragebogen
Ein Fragebogen ist starr mit fix vorgegebenen Fragen. Man kann bei speziellen
Wünschen des Kunden oft nicht darauf eingehen, jedoch erlaubt er statistische
Auswertungen. Es wird ermöglicht, dass viele Personen exakt dieselbe
Fragestellung erhalten, und so können die Antworten miteinander verglichen
werden. Zum Beispiel wenn verschiedene Abteilungen eines Betriebes die
neue Software verwenden, so haben sie wahrscheinlich verschiedene Vorstellungen,
welche Funktionen das Programm haben soll.
Brainstorming
Jeder sagt das, was ihm zum vorgegebebenen Thema einfällt, ohne
lange darüber nachzudenken. Somit entstehen verschiedene Auffassungen
und Meinungen zu bestimmten Teilgebieten. Durch diese Methode kommen oft
unerwartete und eigentlich für manche Beteiligten nebensächliche
Dinge zu Sprache, die jedoch neue nicht wegzudenkende Ideen hervorbringen.
Jede der hier genannten Techniken hat ihre Vor- und Nachteile. Die Wahl
der richtigen Techniken liegt haupsächlich an der Problemstellung, und
ist für jedes Projekt individuell.
Techniken für Modeling
Hier stellen wir verschiedene Modelle, unterschieden durch ihre Art, vor,
und geben zu jedem Modell eine bekannte Technik an.
Funktionales Model
Bei der funktionalen Modellierung liegt der Schwerpunkt auf der Spezifikation
der Funktionen, die die Software zur Verfügung stellen muss. Diese
Art der Modellierung stellt die Software als Hierarchie der einzelnen Funktionen
dar. An der Wurzel befinden sich die allgemeinen Funktionen; je weiter man
in die Blätter vordringt, desto detailliertere Funktionen werden dargestellt.
Eine konkrete Technik auf diesem Gebiet ist SADT (Structured Analysis and
Design Technique), welche sehr früh (ca. in den 70er Jahren) entwickelt
wurde.
SADT war eine der ersten grafischen Modellierungsmethoden und sehr leicht
und einfach handzuhaben. Aufgrund dieser Tatsachen wurde sie auch von vielen
verwendet, und hielt sich ziemlich lange (fast über 2 Jahrzehnte) im
RE-Prozess.
Dynamisches Model
Bei der dynamischen Modellierung werden die Zustände und deren Änderungen
mithilfe der Zeit dargestellt, um das Verhalten der Software klar aufzuzeigen.
Die wichtigsten Konzepte sind einerseits Ereignisse, welche die äußeren
Einflüsse berücksichtigen, und andererseits Zustände, welche
die Werte von Objekten und deren Beziehungen zueinander darstellen.
Ein Biespiel dafür sind Petri Netze, die Anfang der 80er Jahre das
erste Mal Verwendung fanden.
Objekt-orientiertes Model
Der Zentralbestandteil bei der objekt-orientierten Modellierung ist das
Objekt. Es besteht aus Eigenschaften und Methoden. Die Objekte werden durch
Vererbung in Beziehung zueinander gesetzt.
Eine der bekanntesten Methoden ist OMT (Object Modeling Technique), die
etwa um 1990 zum ersten Mal verwendet wurde.
Techniken für Validation/Verification
Reviews
Review (deut. Überprüfung) ist eine Tätigkeit, um eine Spezifikation
zu validieren. Ein Experte, der nicht am Projekt beteiligt ist, überprüft,
ob die Dokumentstruktur und die definierten Anforderungen mit den definierten
Standards konsistent sind.
Audits
Audit (deut. Audit, Prüfung) ist ähnlich einer Review, jedoch
wird sie verwendet, um eine Spezifikation zu verifizieren. Eine Gruppe von
Personen , die die Spezifikation gelesen und analysiert haben, zeigen gefundene
Probleme auf und diskutieren darüber. Sie bestimmen auch mögliche
Aktionen und Reaktionen, um diese Probleme zu beseitigen.
Konzeptionelle Entwicklung
Da die Methoden und Techniken anfänglich sehr stark an die Programmiertechniken
angelehnt wurden - wie bereits oben erwähnt, wurden zu Beginn die Techniken
von anderen Gebieten der Informatik verwendet -, war auch die Entwicklung
und Weiterentwicklung der RE-Techniken stark von der Entwicklung der Programmiersprachen
abhängig.
Mit dem Aufkommen der funktionalen Programmierung wurden auch im RE funktionale
Modelle verwendet, um Anforderungen an Softwaresysteme zu beschreiben (vgl.
SADT-Diagramme). Im Weiteren bediente man sich an Konzepten verschiedener
Programmiersprachen, die im Laufe der Jahre entwickelt wurden. So kam man
über modulare und dynamische Methoden hin zur Objektorientierung (vgl.
OMT).
Oft ist kein genauer Schnitt zwischen den einzelnen Modellen zu finden,
das heißt Modellierungstechniken beinhalten zwei oder mehrere Methoden.
Techniken vermischen verschiedene Arbeitsweisen, genau wie bei Programmiersprachen.
Die reale Praxis
In der heutigen Zeit ist RE ein sehr wichtiger Bestandteil in der Softwareentwicklung
und wird von vielen Firmen angewandt. Die Firmen haben erkannt, dass die Interaktion
zwischen Hersteller und Kunde und das genaue Definieren der Anforderungen
an ein System wesentlich zum Gelingen eines Softwareprojektes beitragen. Aus
diesem Grund wurden auch Tools entwickelt, die die Definition der Anforderungen
im RE-Prozess mittels Computer unterstützen. So entstanden eine Vielzahl
von Produkten, die die unterschiedlichsten Methoden und Techniken verwenden.
Im Weiteren werden zwei verschieden Produkte betrachtet:
Real-time Studio professional von Artisan Software
Dieses Produkt verwendet UML, und unterstützt Firmen bei der Anforderungsdefiniton
für Echtzeitsysteme [Artisan-Info].
Einige Firmen hatten schon Erfolg mit dem Einsatz dieser Software. Sie sind
unter [Artisan-Success] angeführt.
Rational Rose
Rational Rose unterstützt Softwareentwickler mit einer Fülle von
visuellen Modellierungstools für die Erzeugung robuster und effizienter
Businesssoftware. Diese Produkt verwendet auch UML. Näheres unter
[Rose-Info].
Unter [Rose-Success] finden sich auch ein paar Firmen,
die dieses Produkt erfolgreich einsetzten.
Abschließend ist noch zu sagen, dass die meisten Firmen schon erkannt
haben, dass RE maßgeblich am Erfolg eines Softwareprojektes beteiligt
ist, und RE auch durchführen. Es wurden und werden auch immer neue Tools
und Produkte für RE entwickelt, die hauptsächlich auf UML basieren.
Jedoch ist RE noch stark in der Entwicklung, und wer weiß, wo diese
hinführt.
Quellen
HOF00 Hofmann, H. F.: Requirements Engineering - A Situated Discovery
Process. Gabler Edition Wissenschaft,
Deutscher Universitäts-Verlag
2000
HOM83 Hommel, G., Krönig, D. (Hrsg.): Requirements Engineering.
Informatik-Fachberichte 74,
Berlin-Heidelberg-New York:
Springer 1983
LAM00 Lamsweerde, A. van.: Requirements Engineering in the Year 00 -
A Research Perspective. Departement
d'Ingenierie Informatique,
Universite catholique de Louvain (Belgium), IEEE Datenbank
UML http://www.uml.org
Artisan-Info http://www.artisansw.com/products/products.asp
Artisan-Success
http://www.artisansw.com/successStories/successStories.asp
Rose-Info http://www.rational.com/products/rose/
Rose-Success http://programs.rational.com/success/
Verweise auf Arbeiten anderer Gruppen:
Wasserfallmodell - Konzept
http://cartoon.iguw.tuwien.ac.at:16080/fit/fit01/wasserfall/konzepte.html
Requirements Engineering
http://cartoon.iguw.tuwien.ac.at:16080/fit/fit07/konzept_reqeng.html
Spiralmodell - Konzept
http://cartoon.iguw.tuwien.ac.at:16080/fit/fit01/spiral/konzepte.html
Knowledge Engineering - Techniken
http://cartoon.iguw.tuwien.ac.at:16080/fit/fit08/team7/techniken.html
Objektorientierte Programmiersprachen - Entstehung
http://cartoon.iguw.tuwien.ac.at:16080/fit/fit04/ents/ents_objektorientiert.html