Ausgewählte Gebiete des Software Engineering Requirements ...

Seminar WS 99/2000
Ausgewählte Gebiete des Software Engineering
durchgeführt am
Institut für Wirtschaftsinformatik
der Johannes Kepler Universität Linz
Arbeitsgruppe Software Engineering
Altenberger Str. 69, A-4040 Linz, Austria
Tel: +43-70-2468-9432
Fax: +43-70-2468-9430
Email: office@swe.uni-linz.ac.at
Leitung: Prof. Dr. Gustav Pomberger
Mohsen Rezagholi
Mitwirkend: Rainer Weinreich
Requirements Engineering
T1
Regina Reder 9455801/175
Klemens Brandtner 9655169/175
Markus Bürgstein 9455973/151
17. November 1999

Requirements Engineering 1
Inhaltsverzeichnis
1 Kurzfassung.....................................................................................................2
2 Einleitung ........................................................................................................2
3 Requirements Engineering...............................................................................3
3.1 Definition......................................................................................................3
3.2 Requirements Engineering als Teil des Software-Life-Cycles........................3
3.3 Zielsetzung Softwarequalität und Kundenzufriedenheit .................................4
3.4 Mehrdeutigkeiten als Hauptproblem von Anforderungen...............................5
3.5 Vermeidung von Mehrdeutigkeiten ...............................................................6
4 Der Prozeß des Requirements Engineering.......................................................6
4.1 Wichtige Inhalte des Prozesses......................................................................7
4.2 Problemanalyse .............................................................................................8
4.3 Durchführbarkeitsstudie ................................................................................9
4.4 Anforderungen ............................................................................................10
4.4.1 Grundlagen und Motivation.................................................................10
4.4.2 Merkmale einer guten Spezifikation.....................................................12
4.4.3 Der Spezifikationsprozeß.....................................................................13
4.4.4 Dokumentation von Anforderungen.....................................................14
4.4.5 Gewinnung von Anforderungen...........................................................15
4.4.6 Prüfung von Anforderungen ................................................................18
4.5 Dokumentation............................................................................................19
4.5.1 Aufgaben der Dokumentation..............................................................19
4.5.2 Wirtschaftlichkeit der Dokumentation .................................................20
4.5.3 Dokumentverwaltung ..........................................................................21
4.5.4 Dokumenterstellung.............................................................................21
4.5.5 Anforderung an die Dokumentation.....................................................22
4.5.6 Prüfverfahren.......................................................................................22
4.6 Methoden und Techniken ............................................................................23
4.6.1 Datenfluß - Diagramme .......................................................................23
4.6.2 SADT – Structured Analysis and Design Technique ............................25
4.6.3 Anforderungen an Methoden und Techniken .......................................27
4.6.4 Modell erstellen...................................................................................27
5 Abbildungsverzeichnis...................................................................................31
6 Literaturverzeichnis .......................................................................................32
7 Internetquellen...............................................................................................33

Requirements Engineering 2
1 Kurzfassung
Diese Seminararbeit enthält eine Abhandlung über das Requirements Engineering.
Im besonderen werden die Einsatzarten und Auswirkungen in der
Softwareentwicklung betrachtet. Die Arbeit beginnt mit der allgemeinen
Beschreibung des Requirements Engineering. Im Zuge dessen wird vor allem der
Einfluß auf die Softwarequalität und die Kundenzufriedenheit betrachtet. In der
Folge wird der Prozeß des Requirements Engineering betrachtet. Hierbei wird
besonders auf die einzelnen Phasen des Prozesses und die für einen erfolgreichen
Einsatz notwendigen Anforderungen eingegangen. Es werden auch die im Zuge des
Requirements Engineering zu erstellenden Dokumente und deren Auswirkungen auf
den Prozeß und das Verständnis betrachtet. Nachfolgend werden beispielhaft
Methoden und Werkzeuge vorgestellt, um anschließend die Anforderung an
Methoden und Techniken zu erläutern. Abschließend wird als Ergebnis der
Methoden und Techniken die Modellerstellung und Modellbeschreibung betrachtet.
2 Einleitung
Die Softwareentwicklung ist jenes Teilgebiet der Informatik, das die Herstellung
großer Programmsysteme behandelt. Die dazu wissenschaftlichen Methoden werden
erforscht und es werden Werkzeuge entwickelt, die die Herstellung, Dokumentation
und Wartung solcher Programmsysteme unterstützen oder überhaupt erst möglich
machen. 1
Eine immer größere Auswahl von Anwendern und immer spezialisiertere
Programmsysteme rücken nun den Faktor Qualität vermehrt in den Mittelpunkt der
Softwareentwicklung. Damit ist einerseits die Qualität des Herstellungsprozesses
gemeint und andererseits auch die Qualität des Softwareproduktes selbst. Um die
verlangte Qualität zu erreichen und die Kundenzufriedenheit zu fördern wurde im
Rahmen des Requirements Engineering auf die Problematik der "richtigen"
Anforderungsdefinition eingegangen.
1 [Pomberger und Blaschek 1996 Vorwort]

Requirements Engineering 3
3 Requirements Engineering
3.1 Definition
Definition lt. [Sommerville 1997]
3.2 Requirements Engineering als Teil des Software-Life-Cycles
Das Requirements Engineering beschäftigt sich mit der Anforderungsdefintion von
Projekten. Wir werden uns im Zuge dieser Arbeit auf die Softwareentwicklung
beziehen. Somit kann das Requirements Engineering als Teil des Software – Life -
Cycles gesehen werden.
Abbildung 1: Software-Life-Cycle 2
2 [Pomberger und Blaschek 1996 S. 18 ff]

Requirements Engineering 4
Zielsetzung des Requirements Engineering ist es eine möglichst exakte
Anforderungsdefinition zu erstellen. Es soll durch eine inhaltlich umfangreiche und
eindeutige Beschreibung eines gewünschten Produktes erreicht werden, daß das
Produkt am Ende den Wünschen entspricht.
Im Zuge des Requirements Engineering Prozesses werden drei Teilbereiche
abgedeckt. Am Anfang steht die Analyse der Problematik - in unserem Falle meist
eines zu erstellenden Produktes -, die als Basis zur Erstellung eines
Anforderungsprofils dient. Abschließend werden die Anforderung analysiert und
bewertet.
Durch die Erstellung von Dokumenten versucht man dem Ziel nahe zu kommen. Oft
wird aber nicht die Dokumente selbst, sondern durch den Prozeß der Erstellung der
größte Nutzen erzielt. Grund dafür ist, daß die Erstellung eine genaue
Auseinandersetzung mit der Problemstellung bedingt. Es ist nötig, daß alle mit der
Problematik in Zusammenhang stehenden Personen auf eine Gesprächsbasis
zurückgreifen können. Die Basis ist der Schlüssel zum Erfolg, denn es ist nötig, daß
allen bewußt ist, wovon gesprochen wird.
Es können die schwerwiegendsten Fehler entstehen, wenn Personen unter einem
Begriff verschiedene Dinge verstehen. Somit ist das erstellte Dokument nichts, wenn
nicht durch das Dokumentieren eine eindeutige Basis geschaffen wurde.
Im Zuge des Dokumentationsprozesses werden die beteiligten Personen zu einem
Team, das die Anforderungen versteht.
Grundsätzlich gilt, daß wenn ein Ziel nicht genau bekannt und definiert ist, sowie
von allen verstanden und gleich interpretiert wird, nicht erreicht werden kann. In der
Folge kann ein Softwareprodukt den Anwender nicht zufrieden stellen.
3.3 Zielsetzung Softwarequalität und Kundenzufriedenheit
Die Kriterien Softwarequalität und Kundenzufriedenheit sind oft für den Erfolg eines
Unternehmens ausschlaggebend. Je höher die Softwarequalität ist, desto geringer
können die Wartungskosten für ein Produkt gehalten werden. Um auch noch ein
hohes Maß an Kundenzufriedenheit zu errechnen, müssen Anforderungen,
Erwartungen und Wünsche der Kunden erfüllt werden.
Der Softwareentwicklungsprozeß kann nur dann erfolgreich verlaufen, wenn am
Anfang die Anforderungen an das Endprodukt in eindeutiger Form vorliegen.

Anforderungen
Requirements Engineering 5
Die Aufgabe des Requirements Engineering liegt nun darin, ein Verständnis für die
Problematik des Produktes und eine unmißverständliche Definition der
Anforderungen zu liefern.
3.4 Mehrdeutigkeiten als Hauptproblem von Anforderungen
Das größte Problem im Zuge der Anforderungsdefinition ist, wie bereits eingangs
erwähnt, die Vermeidung von Mehrdeutigkeiten. Beispiele für Mehrdeutigkeiten
sind folgende:
• Fehlende Anforderungen
• Mehrdeutige Wörter
• Eingeführte Elemente
Fehlende Anforderungen liegen vor, sobald Grundvoraussetzungen nicht behandelt
werden. Meist geschieht dies, wenn Personen von einer unterschiedlichen
Wissensbasis ausgehen und deshalb Dinge als selbstverständlich angenommen
werden. In der Folge werden diese Annahmen aber nicht von allen
Gruppenmitgliedern geteilt. Aber selbst wenn Anforderungen klar dar gelegt werden,
kann deren Bedeutung nicht für alle gleich sein. Es ist immer von Bedeutung in
welcher Relation Wörter und Begriffe verwendet werden.
Für ein Unternehmen bringt ein gut eingesetztes Requirements Engineering auch den
entscheidenden Vorteil, daß in der Designphase entdeckte Fehler minimale Kosten
verursacht, im Gegensatz zu Fehlern, die erst im Echtbetrieb gefunden wurden.
Entwurf
Abbildung 2: Fehlerstrom und Fehlerkosten in Relation 3
3 [Möller 1992]
Implementierung
10% 40%
50%
3% 5%
7%
25%
50% 10%
Anforderungsreview
Entwurfsreview
Fehlerstrom
Codereview
Entwicklungstest
Systemtest
Feldeinsatz
15% 15%
15%
30%
60% 100%
Entstehung
Entdeckung
Fehlerkosten

Requirements Engineering 6
3.5 Vermeidung von Mehrdeutigkeiten
Wie wir bereits gesehen haben, ist eine Möglichkeit um Mehrdeutigen weitgehend
zu vermeiden, dafür zu sorgen, dass alle beteiligten Personen eine Gesprächsbasis
haben. Oft ist dies mit einer, die Problemstellung betreffenden, gemeinsamen
Wissensbasis verbunden.
Wichtig ist auch, daß die Gruppenmitglieder ein Bild der Anforderungen haben. Im
Konkreten bedeutet dies, daß Einigkeit darüber existiert, was an Wünschen und
Anforderungen besteht. Ein Weg dies zu erreichen, liegt in Definieren der Nicht-
Anforderungen. Damit werden in vielen Fällen auch Mehrdeutigkeiten beseitigt, die
aufgrund einer unterschiedlichen Ausgangslage zu Stande kommen.
Die unterschiedliche Ausgangslage und Wissensbasis darf jedoch nicht als negativ
gesehen werden. Ganz im Gegenteil, denn erst dadurch wird eine vielseitige und
innovative Lösung der Problematik ermöglicht.
Es ist in diesem Zusammenhang wichtig, dass sowohl die Entwickler als auch die
tatsächlichen Anwender am Prozeß beteiligt werden. Von Bedeutung ist jedoch die
unterschiedlichen Personengruppen, die am Requirements Engineering beteiligt sind,
durch Wissensaustausch und Methoden und Werkzeuge des Requirements
Engineering zu koordinieren.
Erst durch eine erfolgreiche Kombination kann das Endprodukt sowohl das
Kriterium der Kundenzufriedenheit als auch ein gutes Maß an Softwarequalität
erfüllen.
4 Der Prozeß des Requirements Engineering
„A requirements engineering process is a structured set of activities which are
followed to derive, validate and maintain a systems requirements document“
(Sommerville 1997, Seite 9)
Das obige Zitat trifft die wesentliche Inhalte eines Requirements Engineering
Prozesses sehr gut, dennoch wird in der deutschsprachigen Literatur wird meist von
folgenden Prozeßteile gesprochen:
• Analyse der Problematik
• Aufstellen der Anforderungen
• Analyse und Bewertung der Anforderungen

Requirements Engineering 7
Als Ziel wird in jedem Fall die Dokumentation gesehen.
4.1 Wichtige Inhalte des Prozesses
Für den eigentlichen Prozeß des RE lassen sich auch Anforderungen festlegen bzw.
sollten mindestens folgende Punkte durch den Prozeß unterstützt werden:
• Problemanalyse
• Durchführbarkeitsstudie
• Anforderungen
• Anforderungsanalyse
• Anforderungsdefinition
• Anforderungsspezifikation
• Unterschiedliche Bewertungsverfahren / Methodiken
• Erstellung einer Dokumentation
Von besonderer Bedeutung ist, daß ein schrittweises Vorgehen wird für einen
Requiremets-Engineering-Prozeß vorausgesetzt wird.
Bei der Durchführbarkeitsstudie bzw. Machbarkeitsstudie stellt man sich primär die
Frage, ob die vorliegenden Ziele mit der verfügbaren Technologie erreicht werden
können. Die erfolgt unter der Auflage, daß die Budgetkosten nicht überschritten
werden.
Bei der Anforderungsanalyse erörtert man sämtliche Anforderungen an das System,
wobei spezielles Augenmerk auf die Anforderungen gelegt wird, welche von den
sog. Stakeholdern an das System gestellt werden.
Bei der Anforderungsdefinition geht man auf die endgültigen Anforderungen ein,
und versucht diese in eine allgemeinverständliche Form zu bringen, sodaß auch
eventuelle Kunden keine Probleme mit der Verständlichkeit haben.
Zuletzt werden die Anforderungen endgültig festgesetzt und in jedem Fall in einer
Dokumentation ausgefertigt.
Das ganze könnte dann in einer derartigen Form graphisch ausgefertigt sein.

Requirements Engineering 8
Durchführbarkeitsstudie
Anforderungsanalyse
Systemmodelle
Anforderungsdokument
Anforderungsdefinition
Definition von
Anforderungen
Abbildung 3: Beispiel für einen Requirements - Engineering - Prozeß
Anforderungsspezifikation
Spezifikation von
Anforderungen
In weiterer Folge werden nun die wesentlichen Punkte des Requirements
Engineering behandeln.
4.2 Problemanalyse
Ursachen Prozeß
Fehlerhafter
(Vorgehensmodell)
Management
Entwicklungsprozeß
(Organisation v. Personen u. Ressourcen)
Kommunikation
(Qualität → Wissen, Umfang, Weiterleitung)
Dokumentation
(fehlerhaft, unvollständig, ungenau)
Wissen und Verständnis
(konkretes, abstraktes?)
(Zeit-, Budget-
Vorgaben)
X
X
Interaktion
(geringer
Nutzen)
Erwartungen
(nicht erfüllt)
X X X
X X
X X

Requirements Engineering 9
Zur Erklärung:
Ein Softwaresystem kann aus verschiedenen Gründen unbrauchbar sein. Dieses
Versagen kann unterschiedlich kategorisiert werden:
Prozeß: Der Entwicklungsprozeß selbst ist fehlerhaft, so daß z.B. Budgets,
Zeitvorgaben u.¨ a. nicht eingehalten werden können
Interaktion: Das Softwaresystem arbeitet zwar korrekt, stellt aber nur einen
geringen Nutzen für die Anwender dar
Erwartungen: Die Erwartungen mindestens einer Interessengruppe (außer den
Anwendern) konnten nicht erfüllt werden
Zum ersten Punkt gilt, wenn man sich an die Modelle und Vorgehensweisen hält,
kann nur mehr sehr wenig falsch laufen.
Für das Management werden zur Lösung bzw. Verhinderung von Problemen
folgende Anforderungen gestellt:
• Planung von Kosten-, Zeit- und anderen Restriktionen
• Kopplung mit der generellen IT-Strategie des Unternehmens
• Aufrechterhaltung der Kommunikation
In dem nachfolgenden Kapitel der Dokumentation finden sich die Anreize wie man
Fehler und damit verbundene Probleme in Softwareprodukten vermeidet.
Speziell für die Bereiche Kommunikation und Wissen & Verständnis sind die
Beteiligten Personen relevant. Gerade der Übergang des Wissens über Information
und Daten ist ein großes Problem und benötigt sehr viel Aufmerksamkeit und
Geschick, vorallem wenn es darum geht, das implizite Wissen des Anwenders und
des Entwicklers zu vereinigen.
4.3 Durchführbarkeitsstudie
Die Studie zur Durchführbarkeit dient primär zur Feststellung, ob das System sowohl
in technischer, personeller und ökonomischer Sicht überhaupt realisierbar ist.
Zusätzlich kann man bereits eine erste Einschätzung des Risikos vorgenommen
werden.

Requirements Engineering 10
4.4 Anforderungen
4.4.1 Grundlagen und Motivation
An dieser Stelle bringen wir zur Wiederholung noch einmal kurz einige Definition.
DEFINITION 1: Anforderung (requirement). Eine Bedingung oder Fähigkeit, die
von einer Person zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt
wird. Eine Bedingung oder Fähigkeit, die eine Software erfüllen oder besitzen muß,
um einen Vertrag, eine Norm oder ein anderes, formell bestimmtes Dokument zu
erfüllen.
DEFINITION 2: Anforderungspezifikation. Die Zusammenstellung aller
Anforderungen an eine Software. Synonyme: Anforderungsdokument, Software
Requirements Spezifikation.
Im Alltag ist die Sprechweise nicht immer ganz eindeutig: mit ,,die Spezifikation“ ist
häufig je nach Kontext das resultierende Dokument oder der Spezifikationsprozeß
(das heißt der Prozeß des Erfassens, Beschreibens und Prüfens von Anforderungen)
gemeint.
Werden die Aufgaben im Bereich der Spezifikation und des Spezifizierens
systematisch und gezielt angegangen, spricht man auch von Requirements
Engineering (Anforderungstechnik).
DEFINITION 3: Requirements Engineering (Anforderungstechnik). 1. Das
systematische, disziplinierte und quantitativ erfaßbare Vorgehen beim Spezifizieren,
dt. Erfassen, Beschreiben und Prüfen von Anforderungen an Software. 2. Verstehen
und Beschreiben, was die Kunden wünschen oder brauchen.
Im deutschen Sprachraum ist im Zusammenhang mit Anforderungen auch der Name
Pflichtenheft gebräuchlich. Mit diesem Namen werden jedoch häufig verschiedene
Begriffe verbunden. Manche Leute verstehen Pflichtenheft als ein Synonym zu
Anforderungsspezifikation, andere verlangen eine grobe Beschreibung der gewählten
Lösung als Bestandteil, wiederum andere sehen auch Elemente der
Projektabwicklung (Kosten, Termine) als Bestandteil des Pflichtenhefts. Bei der
Verwendung des Namens ,,Pflichtenheft“ ist daher Vorsicht geboten und das jeweils
damit Gemeinte im Einzelfall zu klären.

Requirements Engineering 11
Wozu eine Anforderungsspezifikation erstellen?
Die Erstellung einer Anforderungsspezifikation kostet Geld, ohne daß diesem
Aufwand ein unmittelbar sichtbarer Ertrag in Form von Programmen gegenübersteht.
Das Spezifizieren von Anforderungen ist also nur dann wirtschaftlich, wenn dem
dafür zu treibenden Aufwand entsprechende Einsparungen gegenüberstehen.
Requirements Engineering, das systematische Spezifizieren von Anforderungen, hat
daher das klare Ziel, Kosten zu senken.
Daß dieses Ziel realistisch ist, zeigt folgende Überlegung: Fehlerkosten, d.h. die
Kosten für die Lokalisierung und Behebung von Fehlern, machen einen wesentlichen
Teil der Gesamtkosten einer Systementwicklung aus. Anforderungsfehler sind dabei
die teuersten Fehler, weil sie beim Fehlen einer Anforderungsspezifikation typisch
erst bei der Abnahme oder im Betrieb gefunden werden und die Fehlerkosten
exponentiell mit der Verweildauer der Fehler im System wachsen. Wenn man
Requirements Engineering vernünftig betreibt, sind die Einsparungen bei den
Fehlerkosten höher als der dafür notwendige Aufwand. Das heißt, das Spezifizieren
von Anforderungen ist wirtschaftlich.
Abbildung 4: Kosten der Fehlerbehebung
[Quelle: http://nestroy.wi-inf.uni-essen.de/Lv/mod1/folien/10.html]

Requirements Engineering 12
Abbildung 5: Wirtschaftlichkeit der Anforderungsspezifikation
[Quelle: http://nestroy.wi-inf.uni-essen.de/Lv/mod1/folien/10.html]
4.4.2 Merkmale einer guten Spezifikation
Um die Fehlerkosten zu senken, müssen wir folglich erreichen, daß (a) wenig
Anforderungsfehler gemacht werden und (b) möglichst viele der dennoch gemachten
Fehler möglichst früh gefunden werden. Dafür brauchen wir sowohl eine gute
Anforderungsspezifikation als auch einen guten Spezifikationsprozeß.
Eine gute Spezifikation zeichnet sich durch folgende Eigenschaften aus:
• Adäquatheit
das beschreiben, was der Kunde will bzw. braucht
• Vollständigkeit
alles beschreiben, was der Kunde will bzw. braucht
• Widerspruchsfreiheit
sonst ist die Spezifikation nicht realisierbar
• Verständlichkeit
für den Kunden und für die Informatiker
• Eindeutigkeit
damit Fehler durch Fehlinterpretationen vermieden werden

Requirements Engineering 13
• Prüfbarkeit
damit feststellbar ist, ob das realisierte System die Anforderungen erfüllt.
Ein guter Spezifikationsprozeß ist charakterisiert durch
• Kundenorientierung
• Methodisches und zielgerichtetes Vorgehen
• Verwendung geeigneter Mittel
• Integration von Erstellung und Prüfung von Anforderungen.
4.4.3 Der Spezifikationsprozeß
Der Prozeß des Spezifizierens von Anforderungen umfaßt im Wesentlichen drei
Aufgaben:
die Gewinnung, die Darstellung und die Prüfung der Anforderungen. Der Prozeß
kann jedoch nicht einfach sequentiell in drei entsprechende Schritte gegliedert
werden. Vielmehr muß der Prozeß iterativ in enger und ständiger Interaktion
zwischen Vertretern des Kunden und den die Spezifikation erstellenden Analytikern
ablaufen.
Abbildung 6: Möglicher Ablauf eines Spezifikationsprozesses unter Interaktion der
Beteiligten [Quelle: http://nestroy.wi-inf.uni-essen.de/Lv/mod1/folien/7.html]

Requirements Engineering 14
4.4.4 Dokumentation von Anforderungen
4.4.4.1 Klassifikation von Anforderungen
Es gibt verschiedene Arten von Anforderungen. Zunächst einmal wird zwischen
Projekt- und Produktanforderungen unterschieden. In diesem Kapitel betrachten wir
nur letztere. Die Produktanforderungen wiederum gliedern sich in funktionale
Anforderungen und Attribute. Unter funktionalen Anforderungen verstehen wir alle
Anforderungen, die sich auf die Funktionalität eines Systems beziehen, das heißt,
welche Ergebnisse aufgrund welcher Eingaben zu berechnen und / oder zu liefern
sind. Die Attribute spezifizieren die Art und Weise, in der diese Funktionalität zu
erbringen ist. Leistungsanforderungen sind Forderungen bezüglich Zeiten, Mengen,
Geschwindigkeiten, Raten, etc. Besondere Qualitätsanforderungen sind Forderungen
beispielsweise an Zuverlässigkeit oder Benutzerfreundlichkeit. Randbedingungen
schließlich sind alle Forderungen, welche die Menge der möglichen Lösungen
zusätzlich beschränken, z.B. Gesetze und Normen. Leistungsanforderungen,
besondere Qualitätsanforderungen und Randbedingungen werden auch nicht -
funktionale Anforderungen genannt.
Zusätzlich müssen die Anforderungen oft nach ihrer Wichtigkeit klassifiziert
werden, z.B. in
• Muß - Anforderungen — sind unverzichtbar und müssen in jedem Fall erfüllt
werden
• Soll - Anforderungen — sollten erfüllt werden, sind aber bei zu hohen Kosten
verzichtbar
• Wunsch - Anforderungen — werden nur erfüllt, wenn dies mit vertretbaren
Kosten möglich ist.
Eine solche Klassifikation nach Wichtigkeit ist vor allem in zwei Situationen nötig:
• wenn die Entwicklungskosten eine harte Randbedingung darstellen. Dies ist
unter anderem dann der Fall, wenn Software für den Markt entwickelt wird.
• wenn die Anforderungsspezifikation als Grundlage für die Beschaffung eines
Systems dient, weil dann die Lösung nicht nach Maß auf die Bedürfnisse
zugeschnitten werden kann.
Inhalt und Aufbau einer Anforderungsspezifikation
Eine Anforderungsspezifikation muß inhaltlich die folgenden Aspekte abdecken:

Requirements Engineering 15
• Funktionaler Aspekt
- Daten: Struktur, Verwendung, Erzeugung, Speicherung, Übertragung,
Veränderung
- Funktionen: Ausgabe, Verarbeitung, Eingabe von Daten
- Verhalten: Sichtbares dynamisches Systemverhalten, Zusammenspiel der
Funktionen
- Fehler: Normalfall und Fehlerfälle
• Leistungsaspekt
- Datenmengen (durchschnittlich/im Extremfall)
- Verarbeitungs- /Reaktionsgeschwindigkeit (durchschnittlich / im Extremfall)
- Verarbeitungszeiten und -intervalle
- wo immer möglich: meßbare Angaben!
• Qualitätsaspekt
- geforderte Qualitäten (z.B. Benutzerfreundlichkeit, Zuverlässigkeit)
• Randbedingungsaspekt
- einzuhaltende / zu verwendende Schnittstellen
- Normen und Gesetze
- Datenschutz, Datensicherung
- Explizite Vorgaben des Auftraggebers.
Die Gliederung des Dokuments und die Art der Darstellung hängen stark von den
verwendeten Methoden und Sprachen ab. Teilweise sind sie auch durch Richtlinien
des Kunden oder des entwickelnden Unternehmens oder durch die Anwendung
internationaler Normen (z.B. IEEE 830-1993) bestimmt.
Bei der Wahl der Gliederung ist dem Qualitätsmerkmal der Verständlichkeit
besonderes Augenmerk zu widmen. Schlechte oder gar nicht vorhandene
Gliederungen behindern die Verständlichkeit unter Umständen massiv.
4.4.5 Gewinnung von Anforderungen
Es stellt sich das Problem, daß bei der Gewinnung von Anforderungen meist
folgende Schwierigkeiten auftreten:
• Unterschiedliche Vertreter des Kunden haben unterschiedliche Vorstellungen
über das zu spezifizierende System. Häufig sind schon die Auffassungen und

Requirements Engineering 16
die Begriffsbildung im Anwendungsbereich nicht einheitlich. Requirements
Engineering beinhaltet daher auch Konsensbildung zwischen divergierenden
Vorstellungen der beteiligten Personen.
• Die Kundenvertreter haben zwar eine Vorstellung, was sie wollen, aber sie
können ihre Vorstellung nicht formulieren. Manchmal ,,lösen“ sie dieses
Problem, indem sie anstelle ihrer eigentlichen Anforderungen bestehende
Lösungen mit vergleichbaren Eigenschaften beschreiben.
• Die Kundenvertreter wissen nicht oder nur sehr vage, was sie eigentlich
wollen.
Es haben sich folgende vier Vorgehensweisen als mögliche Techniken zur
erfolgreichen Anforderungsgewinnung entwickelt. Je nach Situation wird eine
einzelne Technik oder eine Kombination von Techniken gewählt.
• Begriffe klären und ein Glossar mit Definitionen der wichtigen Begriffe des
Anwendungsbereichs erstellen. Damit wird eine begriffliche Grundlage
geschaffen, die sicherstellt, daß alle das Gleiche meinen, wenn sie vom
Gleichen reden. Ein solches Glossar ist insbesondere dann wichtig, wenn schon
die Kundenvertreter untereinander keine klare und einheitliche Begriffswelt
haben.
• Soll-Prozeßabläufe untersuchen. Feststellen, welche äußeren Ereignisse auf das
zu spezifizierende System einwirken können und erfragen, wie das System auf
welches dieser Ereignisse reagieren soll.
• Anwendungsszenarien bilden und durchspielen. Alle Interaktionen der
Umgebung (seien dies Menschen oder Sensoren und Steliglieder) mit dem zu
spezifizierenden System werden in Form von Szenarien aufgeschrieben und
durchgespielt. Szenarien eignen sich besonders gut zur interaktiven
Gewinnung und Diskussion von Anforderungen mit den Kunden.
• Den Anwendungsbereich modellieren. Feststellen, welche Gegenstände der
Anwendung für das zu spezifizierende System relevant sind. (Relevant sind
diejenigen Gegenstände, über die das System Information speichern muß,
damit es seine Aufgaben erfüllen kann.) Herausfinden, welche Eigenschaften
der relevanten Gegenstände und welche Beziehungen der Gegenstände
untereinander dem zu spezifizierenden System bekannt sein müssen.
Um die gewünschten Informationen von den Vertretern des Kunden zu erhalten,
können verschiedene Techniken eingesetzt werden.
• In Interviews werden die Vertreter des Kunden einzeln oder in Gruppen zu
höchstens drei Leuten befragt.

Requirements Engineering 17
• Mit Fragebogen können Begriffswelt und Bedürfnisse einer größeren Gruppe
von Kundenvertretern erfaßt werden.
• In gemeinsamen Arbeitstagungen (manchmal auch Joint Application
Development-Sitzungen genannt) kann eine Gruppe ausgewählter
Kundenvertreter und Informatiker gemeinsam die Anforderungen an ein
geplantes System erarbeiten.
Die Ergebnisse der Analyse werden mittels geeigneter Methoden und Notationen
dargestellt und bilden dann die Anforderungsspezifikation. Anforderungsanalyse und
- darstellung laufen iterativ und zeitlich verzahnt ab.
Die Rolle der IST - Analyse
Meist wird verlangt, daß der Spezifikationsprozeß mit einer Analyse des IST -
Zustands beginnt. Dabei wird folgendes Vorgehen empfohlen:
1 Analyse des IST - Systems; erstellen eines Modells der gegenwärtigen
Implementierung des IST – Systems.
2 Analysieren der dieser Implementierung zugrundeliegenden Konzepte;
erstellen des sogenannten essentiellen Modells des IST - Systems. Dabei wird
von allen implementierungsspezifischen Eigenschaften des IST - Systems
abstrahiert.
Ableiten der Anforderungen an das neue System; erstellen des essentiellen
Modells des SOLL -Systems. Dieses Modell beschreibt die Anforderungen und
ist im Idealfall frei von Entwurfs- und Implementierungsüberlegungen.
Entwurfs des SOLL - Systems; Erstellen des Implemenherungsmodells des
SOLL - Systems.
Der dritte Schritt in diesem Vorgehen ist der eigentliche Prozeß der
Anforderungsspezifikation. Dieses Vorgehen hält jedoch in vielen Fällen einer
Wirtschaftlichkeitsprüfung nicht stand.
Die Beschäftigung mit dem IST - Zustand ist nur dann gerechtfertigt, wenn
• die Informatiker/Analytiker die IST - Aufgaben und die IST - Arbeitsweise der
Benutzer erst kennenlernen und verstehen müssen, damit sinnvolle Gespräche
über das SOLL geführt werden können
• die Stärken und Schwächen des IST - Systems nicht bekannt sind
• Teile des IST - Systems übernommen werden sollen und festgestellt werden
muss, welche Teile das sind

Requirements Engineering 18
• das IST - System eins zu eins übernommen werden soll, beispielsweise, wenn
ein System auf eine andere Rechnerplattform übertragen werden muß.
Hierzu ist es in der Regel nicht erforderlich, je ein vollständiges
Implementierungsmodell und essentielles Modell zu erstellen. Jede über das
Notwendige hinausgehende Beschäftigung mit dem IST - System verursacht Kosten,
denen kein Nutzen gegenübersteht.
Ferner besteht bei der Ableitung der Anforderungen aus dem IST - System immer
die Gefahr, daß alter Wein in neue Schläuche abgefüllt wird und mögliche neue,
innovative Wege nicht erkannt werden.
4.4.6 Prüfung von Anforderungen
Worum es geht
Beim Prüfen einer Anforderungsspezifikation geht es darum, Abweichungen von der
geforderten Qualität der Spezifikation festzustellen. Mit anderen Worten, bei der
Prüfung sollen möglichst viele Fehler, Lücken, Unklarheiten, Mehrdeutigkeiten, etc.
gefunden (und anschließend behoben) werden.
Dabei haben nicht alle Qualitätsmerkmale das gleiche Gewicht. In erster Priorität
sollte auf Adäquatheit, Vollständigkeit, Widerspruchsfreiheit und Verständlichkeit
geprüft werden, in zweiter Priorität auf Prüfbarkeit und Eindeutigkeit und in dritter
Priorität auf alle übrigen Merkmale.
Die Prüfung einer Spezifikation auf Adäquatheit, Vollständigkeit und
Widerspruchsfreiheit wird auch Validierung genannt.
Beteiligte
Die Prüfung erfolgt sinnvollerweise unter Federführung von IT - Mitarbeitern, die
insbesondere die verwendete Darstellung ohne fremde Hilfe interpretieren können.
Zusätzlich müssen aber die Vertreter des Kunden zwingend in den Prüfprozeß
einbezogen werden, denn nur sie können schlußendlich die Adäquatheit und
Vollständigkeit der Spezifikation beurteilen.
Zeitpunkt der Prüfung
Die abschließende Prüfung einer Spezifikation erfolgt zu einem Zeitpunkt, wo
• die Spezifikation fertig ist

Requirements Engineering 19
• aber noch genug Zeit bleibt, die gefundenen Mängel zu beheben.
Bei umfangreichen Spezifikationen sind zusätzlich Zwischenprüfungen begleitend
zur Erstellung der Spezifikation erforderlich.
4.5 Dokumentation
4.5.1 Aufgaben der Dokumentation
Dokumentation hat die folgenden drei Hauptaufgaben.
• Wissenssicherung: Die Information aus den Köpfen holen
• Kommunikation: Reden miteinander genügt nicht
• Sichtbarmachen des Fortschritts:
Dokumente sind greifbare Resultate
Das Wissen (Know - How) über ein System macht einen beträchtlichen Teil des
Werts eines Systems aus. Die Produktdokumentation hat die Aufgabe, dieses Wissen
schriftlich oder auf Datenträgern festzuhalten. damit es nicht verloren geht. Die
Projektdokumentation sichert die Erfahrungen in der Abwicklung von Projekten.
Eine geordnete Systementwicklung und -pflege ist ohne Kommunikation nicht
möglich. Dies gilt sogar für Ein – Personen - Projekte, wenn daß Produkt länger als
ein paar Wochen leben sah.
Mündliche Kommunikation ist bei Arbeiten in einem kleinen Personenkreis sehr
effizient Ausschließlich mündliche Kommunikation verursacht jedoch erhöhte
Kosten (und wird letztlich ineffizient), wenn der Personenkreis sich ändert oder die
Systembetreuung auf einen anderen Personenkreis übergeht. Letzteres ist typisch der
Fall beim Übergang von der Entwicklung zur Nutzung.
Daher müssen auch in Kleinprojekten alle für ein System wichtigen mündlichen
Informationen und Absprachen in Dokumenten festgehalten werden. Mündliche
Kommunikation genügt nicht, da Erzeugung und Benutzung von Informationen unter
Umstände um Jahre auseinander liegen können.
Der Abschluß jeder Phase der Entwicklung wird nachprüfbar (!), markiert durch die
Fertigstellung und Freigabe von Dokumenten.

Requirements Engineering 20
4.5.2 Wirtschaftlichkeit der Dokumentation
Dokumentation kostet Entwicklungszeit und - geld, darum wird sie - vorallem unter
Termindruck - oft nicht oder nur fragmentarisch erstellt. Außer bei sehr kurzlebigen
Systemen geht die Rechnung mit der Kosteneinsparung jedoch nicht auf.
Wird in einem Unternehmen, das seine Software - Entwicklung bisher nicht oder nur
rudimentär dokumentiert hat, sorgfältiges Dokumentieren eingeführt so ist folglich
zu erwarten. daß die Produktivität in den frühen Phasen der Entwicklung absinkt und
dafür in den späten Phasen sowie in der Nutzung steigt. Ferner darf eine
Verbesserung der Produktqualität erwartet werden.
Abbildung 7: Vergleich Kosten/Nutzen der Dokumentation
[Quelle: http://nestroy.wi-inf.uni-essen.de/Lv/mod1/folien/7.html]
Dokumentation ist nicht Selbstzweck. Es darf daher nur soviel wie unbedingt
notwendig dokumentiert werden, dies aber sorgfältig und konsequent. Außerdem ist
das notwendige Minimum schon recht viel. In der Regel wird nicht zuviel sondern
zuwenig dokumentiert.

Requirements Engineering 21
4.5.3 Dokumentverwaltung
Dokumente, die man nicht findet, wenn man sie braucht, oder solche, die nicht mehr
aktuell sind, sind von zweifelhaftem Wert. Dokumente müssen daher der
Konfigurationsverwaltung unterworfen werden. Vor allem die folgenden drei Dinge
sind wichtig.
Klassifikation: Leichtes Finden durch geordnetes Ablegen
- Jedes Dokument hat einen eindeutigen Namen.
- Alle Dokumente haben einheitlich gestaltete Deckblätter
- Jedes Blatt jedes Dokuments hat eine Kopfzeile mit folgenden Angaben:
Projekt, Dokumentname (evtl. Kurzname), Versionsnummer /
Änderungsindex, evtl. Datum, Kapitelnummer, Seitenzahl. Bei Dokumenten
auf Datenträgern oder in Informationssystemen wird so verfahren, daß diese
Informationen abrufbar sind, bzw. bei der Ausgabe auf Papier generiert
werden.
Freigabewesen: Nur Freigegebenes gilt
Fertiggestellte Dokumente werden geprüft, gefundene Mängel werden behoben.
Dann erst wird das Dokument freigegeben und verteilt. Von diesem Zeitpunkt an ist
ein Dokument dem Zugriff seiner Ersteller entzogen. Änderungen sind nur noch über
das Änderungswesen möglich.
Änderungswesen: Nur Aktuelles ist hilfreich
Das Änderungswesen hat zwei Ziele:
- Dokumente immer aktuell zu halten
- wildes, unkontrolliertes Andern von Dokumenten zu verhindern.
Hierzu wird ein Prozeß definiert, nach dem Änderungen ablaufen. In der Regel
enthält er die Schritte: Antrag - Entscheid - Durchführung - Freigabe.
4.5.4 Dokumenterstellung
Dokumente entstehen schritthaltend mit der Entwicklung und sind ein Bestandteil
des Projektes. Ohne Dokumente sind weder eine vernünftige Projektführung noch
eine geordnete Prüfung und Qualitätssicherung möglich. Das heute immer noch
verbreitete „hinterher“ - Dokumentieren, welches dann oft dem Zeitmangel zum
Opfer fällt, sollte endgültig der Vergangenheit angehören.

Requirements Engineering 22
Hingegen kann es sinnvoll sein, zum Schluß einer Entwicklung Dokumente
nochmals zu überarbeiten. Die Klarheit und die Konsistenz der Darstellung läßt sich
im Nachhinein oft noch massiv verbessern. Der Aufwand für diese Verbesserungen
lohnt sich, da ein guter Dokumentensatz die Pflege verbilligt.
4.5.5 Anforderung an die Dokumentation
An die Dokumentation werden primär folgende Anforderungen gestellt:
• Eindeutig
• Vollständig
• Überprüfbar
• Konsistent
• nachvollziehbar
4.5.6 Prüfverfahren
Für die Prüfung einer Anforderungsspezifikation kommen vier Verfahren in Betracht
• Reviews
• Prüf - und Analysemittel in Werkzeugen
• Simulation
• Prototypen
Ein Review ist eine formell organisierte Zusammenkunft von Personen zur
inhaltlichen oder formellen Überprüfung eines Produktteils (Dokument,
Programmstück, etc.) nach vorgegebenen Prüfkriterien. Reviews sind das Mittel zur
Prüfung von Dokumenten.
Prüf - und Analysemittel in Werkzeugen werden immer dann eingesetzt, wenn eine
Spezifikation mit Hilfe von Werkzeugen erstellt wurde. Insbesondere Lücken und
Widersprüche in der Spezifikation lassen sich mit solchen Prüfverfahren finden.
Beispielsweise kann ein Werkzeug prüfen, ob jeder verwendete Datenname auch
irgendwo definiert ist.
Mit einer Simulation kann die Adäquatheit des Verhaltens des spezifizierten Systems
in bestimmten Situationen untersucht werden.
Ein Prototyp ist ein lauffähiges Stück Software, welches Teile eines zu
entwickelnden Systems vorab realisiert. Er dient als Modell für die weitere
Entwicklung oder für das zu schaffende Produkt. Ein Prototyp ist das mächtigste
verfügbare Mittel für die Beurteilung der Ädäquatheit einer Spezifikation durch die

Requirements Engineering 23
zukünftigen Benutzer. Er ermöglicht in beschränktem Rahmen eine Erprobung des
gewünschten Systems in seiner geplanten Einsatzumgebung. Aufgrund der im
Vergleich zu anderen Prüfverfahren hohen Kosten für einen Prototyp muß in jedem
Einzelfall entschieden werden, wie weit die Entwicklung von Prototypen für die
Prüfung von Anforderungen aufgrund des Entwicklungsrisikos notwendig ist.
4.6 Methoden und Techniken
Die klassischen Methoden und Techniken des Requirements Engineering dienen
hauptsächlich der Ansammlung von abstraktem Wissen. Zu diesen Methoden
gehören:
• _
• _
• _
Datenfluß - und ER - Diagramme
Objektorientierte Analyse
Ereignisorientierte Analyse
Im folgenden wollen wir nun einige Modelle erklären.
4.6.1 Datenfluß - Diagramme
4.6.1.1 Einleitung
Zweck eines Datenflußdiagrammes ist die Abbildung der als Prozesse aufgefaßten
Komponenten eines Systems mit den Datenbeziehungen, die zwischen den Prozessen
bestehen. Bei der Systemabbildung wird primär die Sicht auf die Daten und nicht auf
die der Prozesse von Interesse sein. Die Schnittstellen zwischen den Prozessen sind
die, als Datenflüsse bezeichneten, Datenbeziehungen. Wegen des hohen
Darstellungsaufwandes ist die Anwendung der Datenflußdiagramme erst mit der
Entwicklung von Werkzeugen zum vorherrschenden grafischen Darstellungsmittel
geworden.
4.6.1.2 Verwendung von Datenflußdiagrammen
Die grundsätzliche Verwendung von Datenflußdiagrammen ist die Erfassung und
Analyse des Istzustands und dem Systementwurf. Dabei kann zwischen logischen
und physischen Datenflußdiagrammen unterschieden werden. Aus diesem Grund
kann man folgende Anwendungsgebiete näher präzisieren:

Requirements Engineering 24
• Istzustandserfassung: physisch orientierte Abbildung des Istzustands
• Istzustandsanalyse : Entfernung der physischen Attribute und entwickeln des
logischen Modell des Istzustands (von der Implementierung unabhängig)
• Systementwurf: logisches Modell des Sollzustandes
• Implementierung: den logischen Modell des Sollzustandes werden durch
physische Attribute ergänzt.
Nachdem wir nun die Anwendungsgebiete der Datenflußdiagramme kennen gelernt
haben, wenden wir uns der Darstellungsform der Datenflußdiagramme zu. Die
nachfolgende Notation verwendet folgende Elemente und Symbole:
• Pfeil zur Darstellung von Datenobjekten
• Kreis zur Darstellung von Prozessen
• parallele Linien zur Darstellung von Datenbasen (nicht im Kontextdiagramm)
• Rechteck zur Darstellung von Datenquellen und –senken (nur im
Kontextdiagramm)
Die Abbildung unten zeigt uns den Aufbau eines Datenflußdiagramms mit den
wichtigsten Elementen. Die folgende Darstellung kann wie folgt gelesen werden. Die
Datenquelle Q stellt dem Prozeß P1, der einen Zugriff auf die Datenbasis D hat,
Datenobjekt x zur Verfügung. Ergebnis der Verarbeitung im Prozeß P1 ist
Datenobjekt y, dieses wird von Prozeß P2 verwendet und zu Datenobjekt z
verarbeitet, das in die Datensenke S eingeht.
Abbildung 8: Wichtigsten Symbole eines Datenflußdiagramms (Heinrich 1997, Seite 366)
Bereits die Modellierung kleiner Systeme kann zu unübersichtlichen
Abbildungsgrößen führen und deshalb wird eine geeignete Zerlegung von
Datenflußdiagrammen vorgenommen. Durch die Zerlegung entsteht eine Hierarchie
von Datenflußdiagrammen auf mehreren Abstraktionsebenen.

Requirements Engineering 25
Die oberste Ebene wird als Kontextdiagramm und die unterste Ebene, die nicht mehr
sinnvoll zerlegt werden kann, wird als Grundfunktion bezeichnet. Zwischen den
einzelnen Ebenen besteht von oben nach unten eine Vater - Sohn Beziehung.
Jedes Sohn - Diagramm ist eine detailliertere Systemabbildung als das ihm
zugehörige Vater - Diagramm, doch handelt es sich immer um genau das gleiche
System. Diese Tatsache wird als Gleichgewicht zwischen den Datenflußdiagrammen
benachbarter Ebenen bezeichnet.
4.6.1.3 Arbeitsschritte zur Modellierung
Beim Modellieren eines Datenflußdiagramms kann nach folgenden Arbeitsschritten
vorgegangen werden:
1. Festlegen der Systemgrenzen (Eingabe- oder Ausgabedaten)
2. Bestimmen der Datenobjekte innerhalb der Systemgrenzen
(progressiv oder retrograd)
3. Bezeichnen der Datenobjekte in eindeutiger und übersichtlicher Weise
4. Beschreiben der Prozesse auf der untersten Darstellungsebene (Grundfunktion)
5. Überarbeiten des Datenflußdiagramms
6. Dokumentation der Datenobjekte und der Prozesse
4.6.2 SADT – Structured Analysis and Design Technique
SADT ist eine graphische Beschreibungsmethode, wobei ein System mit zwei sich
ergänzenden Modellkonzepten abgebildet wird:
1. Aktivitätenmodell: zur Abbildung von Aktivitäten, die durch Menschen,
Maschinen oder Algorithmen ausgeführt werden.

Requirements Engineering 26
Abbildung 9. Aktivitätsmodell (Heinrich 1997, Seite 357)
Im Aktivitätenmodell wird jede Aktivität durch ein Rechteck modelliert. Die
Datenobjekte, welche die Aktivitäten auslösen bzw. die durch die Aktivität erzeugt
werden, werden als Pfeile dargestellt.
2. Datenmodell: jedes Datenobjekt wird als Rechteck und jede Aktivität als Pfeil
modelliert.
Abbildung 10: Datenmodell (Heinrich 1997, Seite 357)

Requirements Engineering 27
4.6.2.1 Eigenschaften der SADT
• Jede Seite eines Aktivitäten- und eines Datenkastens hat eine spezielle
Bedeutung:
linke Seite: Input
obere Seite: Controls
rechte Seite: Outputs
untere Seite: Mechanismus
• Bei der Modellierung beginnt man auf der höchsten Abstraktionsebene und führt
dann eine schrittweise Verfeinerung durch.
• Ein System kann von mehreren Sichten modelliert werden. (z.B eine Bibliothek
aus der Sicht des Bibliotheksbenutzers und der Bibliotheksverwaltung)
Um konkrete Erfahrungen mit dem Arbeitsbereich des Anwenders zu erhalten,
müssen jedoch weitere Techniken eingesetzt werden:
• Beobachtungen
• Befragungen
• Teilnahme des Entwicklers an der Arbeit des Anwenders
• Experimente
• ...
4.6.3 Anforderungen an Methoden und Techniken
Die verwendeten Methoden und Techniken sollten folgende Eigenschaften besitzen:
• Darstellung aktueller und zukünftiger Systeme sowie technologischer Optionen
• Entwicklung abstrakten und konkreten Wissens
• Betrachtung auch von Randgebieten
• Unterstützung von Kommunikation zwischen Anwendern und Entwicklern
4.6.4 Modell erstellen
Ziel der Modellierung ist es, diejenigen Aufgaben zu erheben, die mittels Software
unterstützt werden können. Hierzu werden zunächst die für die Untersuchung
relevanten Organisationseinheiten entlang einer Darstellung der Aufbauorganisation
ermittelt.

Requirements Engineering 28
In strukturierten Interviews mit den späteren Anwendern aus diesen Abteilungen
werden die dort anfallenden Aufgaben und die zur Aufgabenerledigung benötigten
bzw. bei der Aufgabenerledigung erzeugten Daten erhoben.
Sowohl zur Erhebung wie auch zur Dokumentation der
Organisationszusammenhänge und zur Modellvalidierung mit den Anwendern bieten
sich graphische Beschreibungsmittel an. Insgesamt liegt der Softwareevaluation
eine Modellierung des Anwendungsbereichs der Software aus Aufbau -, Ablauf-,
Aufgaben- und Objektsicht zugrunde. Die Art der Modellierung sowie die
verwendeten Beschreibungsmittel werden in Abschnitt 2 näher dargestellt.
4.6.4.1 Beschreibung der Modelle
In diesem Modell wird der Anwendungsbereich aus verschiedenen Sichten der
Organisationsmodellierung betrachtet. Zentral für die Softwareevaluation ist die
Aufgabensicht. Hier werden die Aufgaben, für die eine Softwareunterstützung
gesucht ist, näher beschrieben. Die zeitliche und logische Reihenfolge der
Aufgabenbearbeitung wird aus der Ablaufsicht untersucht.
In der Aufbausicht steht die Betrachtung der organisatorischen Einheiten, die mit der
Aufgabenerledigung betraut sind, im Vordergrund. In der Objektsicht werden
Objekte, wie Daten, Dokumente oder Werkstücke, die im Anwendungsbereich
bearbeitet werden, näher untersucht.
Zur jeder dieser Organisationssichten sowie zur sichtenübergreifenden
Organisationsbeschreibung können verschiedene Beschreibungsmittel eingesetzt
werden.
Die Aufbausicht wird hierbei durch ein Organigramm dargestellt, welches die
Leitungsbeziehungen zwischen einzelnen Organisationseinheiten beschreibt. Zur
Darstellung aus Ablaufsicht werden Datenflußdiagramme verwendet.
Diese beschreiben einerseits Beziehungen zwischen Aufgaben und Objekten,
unterstützen den Modellierer aber auch bei der Aufgabenzerlegung. Dokumentiert
wird diese Zerlegung in der Aufgabensicht durch einen
Aufgabengliederungsplan.Eine Ergänzung der Aufgabengliederungspläne bietet die
Software - Anforderungsliste, in der jeder Aufgabe Unterstützungsmöglichkeiten
durch Software zugeordnet ist. Mit Hilfe erweiterter Entity-Relationship-
Diagramme werden schließlich die zu bearbeitenden Objekte beschrieben.

Requirements Engineering 29
Alternativ zu den hier skizzierten Beschreibungsmitteln lassen sich auch andere
verwenden. So können anstelle der Datenflußdiagramme z.B. auch SADT-
Aktivitätendiagramme verwendet werden. In diesen Diagrammen kann zu jeder
Aufgabe auch ein Aufgabenträger zugeordnet werden, wodurch ein Bezug zwischen
Ablauf- und Aufbausicht hergestellt wird. Ist neben der Betrachtung der einzelnen
Aufgaben und der bearbeiteten Objekte auch eine Betrachtung von Kontrollflüssen
wesentlich, bietet sich eine sichtenübergreifende Darstellung durch
Vorgangskettendiagramme an, durch die zusätzlich auch ein Bezug zur Aufbausicht
hergestellt werden kann.
4.6.4.2 Erhebung der Modelle
Ausgangspunkt zur Erstellung des anwendungsabhängigen Modells ist die
Aufbauorganisation des betrachteten Unternehmens, die zumeist in Form von
Organigrammen dokumentiert ist.
Diese Darstellungen sind jedoch auf ihre Aktualität hin zu überprüfen und
gegebenenfalls zu überarbeiten. Zur Softwareevaluation reicht es häufig aus,
lediglich die Unterstützung für zentrale Organisationseinheiten und für
Repräsentanten gleichartiger Abteilungen zu untersuchen.
Als Auswahlkriterium können hierzu die Informationsbeziehungen zwischen den
Abteilungen dienen. Entlang von Darstellungen, die Organisationseinheiten mit
ähnlichem Kommunikationsverhalten zusammenfassen, kann diese Auswahl
erfolgen.
Sowohl Erhebung als auch Dokumentation der Aufgaben- und Ablaufmodellierung
für diese ausgewählten Abteilungen erfolgt mit Datenflußdiagrammen. Hierzu wird
in Interviews erhoben und interaktiv in Kontextdiagrammen notiert, welche
Informationen mit anderen Abteilungen oder externen Partnern ausgetauscht werden.
Ausgehend von diesen ein- und ausgehenden Datenflüssen werden Unteraufgaben
mit eher administrativem, kontrollierendem, planendem, entscheidendem oder
ausführendem Charakter erfragt. Dieses Vorgehen ermöglicht eine vollständige
Erfassung aller zu erledigenden Aufgaben.
Dieses wird auch dadurch erreicht, daß es zu jedem ein- bzw. ausgehenden
Datenfluß eine diese Informationen verarbeitende Aufgabe geben muß. Die
ermittelten Aufgaben können analog entlang der ein- und ausgehenden Datenflüsse
weiterverfeinert werden.

Requirements Engineering 30
Die gewonnene Verfeinerungshierarchie wird anschließend in
Aufgabengliederungspläne übertragen. Die Gestalt der Datenflüsse kann sowohl aus
den Interviews wie auch aus verwendeten Formularen abgeleitet werden.
Dokumentiert werden diese Zusammenhänge aus Objektsicht mittels Entity-
Relationship-Diagrammen oder Datenlexika.
Zur Kommunikationsunterstützung während der Modellerhebung bieten sich in
erster Linie Kontextdiagramme an, die gemeinsam mit den Interviewpartnern erstellt
werden. Entlang der hierbei erhaltenen Informationen können dann Unteraufgaben
strukturiert erfragt werden.
Diese Aufgaben werden von den Befragten i.a. kontrollflußartig durch Folgen
weiterer Aufgaben und Unteraufgaben erklärt, so daß hieraus eine erste
Aufgabengliederung abgeleitet werden kann, die später zu einer vollständigen
Datenflußmodellierung ergänzt wird. Ebenso unterstützen graphische Darstellungen
die Modellvalidierung. Entlang der Datenflußdiagramme können die Befragten ihre
Arbeitsabläufe gut verfolgen und gleichzeitig überprüfen, ob alle benötigten bzw.
erstellten Informationen berücksichtigt sind.
Um die Kommunikation mittels Datenflußdiagrammen zu erleichtern, sollten
gewisse Layout-Richtlinien berücksichtigt werden. Insbesondere die Anordnung von
Prozessen und Datenspeichern trägt zum intuitiven Modellverstehen bei. Da
Aufgaben vielfach in der zeitlichen Folge ihrer Erledigung erklärt werden, sollte
dieser Ablauf in den Darstellungen – auch wenn Kontrollfluß in
Datenflußdiagrammen nicht explizit modelliert ist – erkennbar sein. Dieses wird
dadurch erreicht, daß man sich eine Zeitachse vom linken oberen zum rechten
unteren Bildrand denkt und Aufgaben, die zeitlich oder logisch später ausgeführt
werden, weiter rechts im Diagramm notiert. Parallel bearbeitbare Aufgaben können
übereinander notiert werden. Querbezüge zwischen einer verfeinerten Aufgabe und
ihrer Verfeinerung lassen sich leichter herstellen, wenn ein- und ausgehende
Datenflüsse auf beiden Modellierungsebenen leicht identifizierbar sind.
Hierzu empfiehlt es sich, in die Verfeinerung ein- und ausgehende Datenflüsse am
Bildrand beginnen bzw. enden zu lassen. Daneben sollten auch einfache
Gestaltungsregeln beachtet werden. So sollte ein Diagramm i.a. 3-7 Aufgaben
beschreiben und jede Aufgabe nicht zu mehr als sieben Datenflüssen inzident sein.

Requirements Engineering 31
5 Abbildungsverzeichnis
Abbildung 1: Software-Life-Cycle .......................................................................3
Abbildung 2: Fehlerstrom und Fehlerkosten in Relation .......................................5
Abbildung 3: Beispiel für einen RE - Prozeß ........................................................8
Abbildung 4: Kosten der Fehlerbehebung ...........................................................11
Abbildung 5: Wirtschaftlichkeit der Anforderungsspezifikation .........................12
Abbildung 6: Möglicher Ablauf eines Spezifikationsprozesses unter
Interaktion der Beteiligten .............................................................13
Abbildung 7: Vergleich Kosten/Nutzen der Dokumentation ...............................20
Abbildung 8: Wichtigsten Symbole eines Datenflußdiagramms ..........................24
Abbildung 9. Aktivitätsmodell ...........................................................................26
Abbildung 10: Datenmodell .................................................................................26

Requirements Engineering 32
6 Literaturverzeichnis
[Gause 1993] Donald C. Gause: Software Requirements:
Anforderungen erkennen, verstehen und erfüllen; 1.
Auflage, Carl Hanser Verlag München Wien 1993.
[Heinrich 1997] Heinrich, Lutz J.: Management von
Informatikprojekten, Oldenbourg Verlag, 1997
[IEEE 94] IEEE Software, March 1994
[IEEE 96] IEEE Software, March 1996
[Möller 1992] Karl-Heinrich Möller: Metrikeinsatz in der
Softwareentwicklung; in HMD - Theorie und Praxis
der WIN 163/92, S. 17-30.
[Partsch 1991] Helmuth Partsch: Requirements Engineering –
Handbuch der Informatik, Oldenbourg München. 1991.
[Pomberger / Blaschek 1981]Gustav Pomberger und Günther Blaschek: Software
Engineering – Prototyping und objektorientierte
Softwareentwicklung; 2. Auflage, Carl Hanser Verlag
München Wien 1996.
[Sommerville 1997] Sommerville, Ian; Sawyer, Pete: Requirements
Engineering. A Good Practice Guide, John Wiley &
Sons Verlag 1997.

Requirements Engineering 33
7 Internetquellen
V - Modell nach Böhm
http://www.baer.rwth-aachen.de/~marcel/studium/pig/projektmanagment.htm
Requirements Engineering Research Group at University of Zurich
http://www.ifi.unizh.ch/groups/req/
Theoretische und praktische Ansätze im Requirements Engineering für
Standardsoftware und Anlagenbau
http://hpbib3.informatik.tu-
muenchen.de/Dienst/UI/2.0/Describe/ncstrl.tu.munich_cs/TUM-I9832
Requirements Engineering - Einführung
http://nestroy.wi-inf.uni-essen.de/Lv/mod1/folien/10.html
http://nestroy.wi-inf.uni-essen.de/Lv/mod1/folien/7.html
Requirements Engineering - Einführung
http://www.kbs.uni-hannover.de/se/vorlesung/root2/root2.html
Requirements Engineering – research group
http://www-comp.mpce.mq.edu.au/~didar/seweb/requirements.html
Requirements Engineering
http://www.pri.univie.ac.at/scripts/scripts.html
Requirements Engineering
http://www.uni-koblenz.de/~ist/abstracts/FraWin1995.html
Requirements Engineering
http://www-stud.uni-essen.de/~sw0136/Lernzettel/Lern_SWT.html
Alle Internetquellen datieren mit 14. November 1999 und waren zu diesem Zeitpunkt
voll funktionsfähig.