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.

RE-Problematik
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: 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.

  1. 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.
  2. Modeling (deut. Modellierung) strukturiert die Daten, die während der 1. Phase herausgefunden wurden.
  3. 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:
RE Phasen
Abbildung 2: RE Phasen [HOF00]

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