Planung und Analyse eines idealen Rechtsinformationssystems

Inhaltsverzeichnis

1 Einleitung

2 Requirements Engineering
2.1 Der Requirements Engineering Prozess
2.2 Erkennen und analysieren der Anforderungen
2.3 Das Anforderungsanalysedokument
2.4 Überprüfung der Anforderungen
2.5 Requirements Engineering Techniken

3 Das österreichische Recht
3.1 Struktur des Rechts
3.2 Entstehung des Rechts
3.3 EU-Recht

4 Planung der Vorgehensweise
4.1 Planung der Erhebung
4.2 Ergebnisse der Erhebung
4.3 Planung der Evaluierung

5 Aktuelle Rechtsinformationssysteme
5.1 Konzepte und Richtlinien
5.2 Konkrete Rechtsinformationssysteme
5.3 Beurteilung aktueller Rechtsinformationssysteme

6 Anforderungsanalyse
6.1 Systembeschreibung
6.2 Begriffserklärungen
6.3 Die wesentlichsten Anwendungsfälle und deren Beschreibung
6.4 Domänenmodell
6.5 Zentrale technische Anforderungen
6.6 Beschreibung der Architektur
6.7 Anforderungen an die Anwenderschnittstelle
6.8 Struktur der Datenbank

7 Evaluierung

8 Zusammenfassung und Ausblick

9 Quellenangaben
9.1 Literatur
9.2 Webressourcen

Abbildungsverzeichnis

Abbildung 1 - Schichten des V-Modells

Abbildung 2 - Input/Output of the Requirements engineering process

Abbildung 3 - Der Requirements Engineering Prozess

Abbildung 4 - Ein Beispiel für ein Anwendungsfalldiagramm

Abbildung 5 - Weitere Elemente der Anwendungsfalldiagramme

Abbildung 6 - Anwendungsfalldiagramm mit Beziehungen

Abbildung 7 - Beispiel für Klassen

Abbildung 8 - Beispiel für Vererbung

Abbildung 9 - Beispiele für Assoziationen

Abbildung 10 - Beispiel für eine Entität

Abbildung 11 - Beispiel für eine Generalisierung

Abbildung 12 - Beziehungen in einem EER

Abbildung 13 - Auflösen einer m:n-Beziehung

Abbildung 14 - Beispiel für ein EER

Abbildung 15 - Stufenaufbau vgl. [Maye1998]

Abbildung 16 - Instanzenzug (Strafrecht) vgl. [Maye1998]

Abbildung 17 - Instanzenzug (Zivilrecht) vgl. [Maye1998]

Abbildung 18 - Die drei Säulen der EU vgl. [Maye1998]

Abbildung 19 - Ergebnisliste im RIS

Abbildung 20 - Gesetzestext im RIS

Abbildung 21 - Suchmaske in RIDA

Abbildung 22 - Ergebnisliste in RIDA

Abbildung 23 - Ergebnisliste in SozDok

Abbildung 24 - Dokument aus CELEX

Abbildung 25 - Berechtigungsstruktur der Aktoren

Abbildung 26 - Anmelden und Abmelden

Abbildung 27 - Einstellungen

Abbildung 28 - Suche

Abbildung 29 - Ergebnisliste

Abbildung 30 - Dokumentansicht

Abbildung 31 - Domänenmodell-Überblick

Abbildung 32 - Domänenmodell-Benutzer

Abbildung 33 - Domänenmodell-Suche

Abbildung 34 - Domänenmodell-Dokumente und Verweise

Abbildung 35 - Architektur

Abbildung 36 - Anmelden

Abbildung 37 - Einstellungen

Abbildung 38 - Suche

Abbildung 39 - Ergebnisliste

Abbildung 40 - Suchbaum

Abbildung 41 - Dokumentansicht

Abbildung 42 - EER

Tabellenverzeichnis

Tabelle 1 - Entstehungsgeschichte des Signaturgesetzes [PAR]

Tabelle 2 - Interviewpartner

Tabelle 3 - Interviewleitfaden

Tabelle 4 - Kriterien/Interviewpartner

Tabelle 5 - Kriterien/Arbeitsbereiche

Tabelle 6 - Kriterien/Rechtsinformationssysteme

Tabelle 7 - Begriffsdefinitionen

Tabelle 8 - Synonyme

Tabelle 9 - Attribute der Anwendungsfälle

Tabelle 10 - Liste der Anwendungsfälle

Tabelle 11 - Evaluierung

1 Einleitung

Diese Arbeit setzt sich mit der Betrachtung verschiedener Rechtsinformationssysteme und dem Entwurf eines konkreten Rechtsinformationssystems auseinander. Dabei wird besonders auf die Planung und die Analyse, die in einem solchen Projekt stattfindet eingegangen, wobei jedoch vorher die wichtigsten technischen und juristischen Grundlagen aufbereitet werden.

Rechtsinformationssysteme fallen thematisch von juristischer Seite her gesehen in das Gebiet der Rechtsinformatik. Rechtsinformatik kann man als die Wissenschaft der Anwendung von informatischen Methoden in rechtswissenschaftlichen Bereichen verstehen. Von informatischer Seite her betrachtet handelt es sich bei Rechtsinformationssystemen um webbasierte oder Client/Server-basierte Datenbanksysteme und im weiteren Sinne um Softwareprodukte.

Diese Arbeit richtet sich in erster Linie an einen am Thema interessierten Leser, der nicht unbedingt über juristisches Fachwissen oder eine technische Ausbildung verfügen muss, er sollte jedoch an diesen Materien interessiert sein. Die Arbeit ist so aufgebaut, dass der juristisch oder technisch vorgebildete Leser die ersten Kapitel überspringen kann. Jedes Kapitel lässt sich mit dem notwendigen Vorwissen auch einzeln lesen, wobei in der jeweiligen Einleitung auf diese Voraussetzungen eingegangen wird.

Die Arbeit hat drei Teile, der erste Teil erarbeitet die informatische und juristische Theorie, die für das Verständnis der Arbeit notwendig ist, in den Kapiteln Requirements Engineering und Recht in Österreich. Der zweite Teil umfasst die Kapitel Planung der Vorgehensweise und aktuelle Rechtsinformationssysteme, und somit die Recherchen. Die konkreten Ergebnisse der Arbeit und deren Evaluierung werden dann im dritten Teil dargestellt.

Im zweiten Kapitel dieser Arbeit geht es darum, dem Leser die Theorie und die grundlegenden Konzepte und Ideen des Requirements Engineering näher zu bringen. Es handelt sich dabei um eine Einführung in die Thematik der Anforderungsanalyse, welche vor allem auf die für das Verständnis der Arbeit wichtigen Aspekte eingeht und somit keinen Anspruch auf Vollständigkeit erhebt. Dieser Teil gibt dem Leser einen adäquaten Hintergrund für das Lesen und Verstehen eines Anforderungsdokumentes und somit des Hauptteiles dieser Arbeit mit.

Das dritte Kapitel behandelt die Materie des Rechts. Es handelt sich dabei um ein rein juristisches Kapitel, das es dem Nicht-Juristen ermöglichen soll die wichtigsten Grundbegriffe und Zusammenhänge die es im österreichischen Recht gibt kennenzulernen. Auch hier wurden besonders jene Aspekte hervorgehoben, die für das Verstehen der restlichen Arbeit notwendig sind. Teilweise werden Zusammenhänge nur vereinfacht erklärt oder auf einzelne Punkte überhaupt nicht eingegangen. Es soll sich bei diesem Text allerdings auch nicht um eine vollständige Einführung in das österreichische Recht handeln, sondern es sollen nur einige Grundlagen vermittelt werden um dem Leser einen Bezug zu der juristischen Materie zu vermitteln.

Im vierten Kapitel sollen die Recherchen die im Rahmen der Planung und Analyse durchgeführt wurden dokumentiert werden. So wurden unter Verwendung des Internet umfassende Recherchen nach themenbezogenem Material durchgeführt. Außerdem wurden Interviews mit verschiedenen Juristen durchgeführt, deren Ergebnisse hier präsentiert werden sollen. Auch die Vorgehensweise bei der Planung und Durchführung dieser Interviews soll hier beschrieben werden. Des weiteren wird hier die Grundlage für die Evaluierung des Systems geschaffen.

Der Betrachtung von mehreren unterschiedlichen Rechtsinformationssystemen ist das fünfte Kapitel gewidmet. Hier werden die Ergebnisse umfassender Recherchen zusammengefasst und präsentiert. Einige konkrete Rechtsinformationssysteme werden kurz beschrieben und in ihren Möglichkeiten und Anwendungen skizziert. Dieses Kapitel zeigt welche Systeme es zur Zeit gibt um einen Überblick über den Stand der Technisierung auf diesem Gebiet und auch über das Potential der Technikentwicklung zu geben. Weiters dient die Betrachtung konkreter Rechtsinformationssysteme der Erkenntnis von positiven sowie negativen Eigenschaften und Merkmalen die natürlich in die Planung und Analyse eines neuen Systems einfließen sollen. Außerdem wird in diesem Kapitel auf die Rahmenbedingungen und Voraussetzungen von Rechtsinformationssystemen eingegangen.

Beim sechsten Kapitel handelt es sich um das eigentliche Anforderungsanalysedokument, welches auf den Vorarbeiten aufbauend entstanden ist. Es werden mit Hilfe verschiedener Requirements Engineering Methoden die Anforderungen an ein zeitgemäßes Rechtsinformationssystem definiert und einige technische Rahmenbedingungen für ein solches Projekt festgelegt. Bei diesem Kapitel handelt es sich also um das eigentliche Ergebnis der Arbeit. Dieses Anforderungsanalysedokument wird dann im siebenten Kapitel evaluiert.

Im achten Kapitel werden die wichtigsten Punkte und das Fazit dieser Arbeit noch einmal kurz herausgestrichen was dazu dienen soll die Arbeit etwas abzurunden. Die Quellenangaben sind im neunten Kapitel zu finden.

Zunächst wird jedoch noch geklärt worum es sich bei Software Engineering und bei einem Software Engineering Prozess eigentlich handelt, um die Herangehensweise bei diesem Projekt zu begründen und theoretisch zu fundieren.

Die Herstellung dieser Softwareprodukte wird als Software Engineering bezeichnet. Dabei handelt es sich um einen Namen der bewusst gewählt wurde um auch die Erstellung von Software als Ingenieursdisziplin zu etablieren. Es gibt zur Zeit keine allgemein gültige und anerkannte Definition von Software Engineering, deshalb sollen hier gleich einige angeboten werden.

„Software Engineering ist die praktische Anwendung wissenschaftlicher Erkenntnisse auf den Entwurf und die Konstruktion von Computerprogrammen, verbunden mit der Dokumentation, die zur Entwicklung, Benutzung und Wartung der Programme erforderlich ist.

Software Engineering ist die Anwendung von Prinzipien, Fähigkeiten und Kunstfertigkeiten auf den Entwurf und die Konstruktion von Programmsystemen.

Software Engineering ist die Programmierung unter mindestens einer der zwei Bedingungen:

(1) Mehr als eine Person schreibt und benutzt das Programm.
(2) Mehr als eine Fassung des Programms wird erzeugt.

Software Engineering ist die technische und organisatorische Disziplin zur systematischen Herstellung und Wartung von Softwareprodukten, die zeitgerecht und innerhalb vorgegebener Kostenschranken hergestellt und modifiziert werden.

Software Engineering befasst sich mit dem Bau von Softwaresystemen, die nicht von einem Entwickler alleine hergestellt werden können. Software Engineering beruht auf der Anwendung ingenieurmäßiger Prinzipien und umfasst sowohl technische als auch nicht-technische Aspekte.

Das Ziel der Softwaretechnik ist die wirtschaftliche Herstellung zuverlässiger und effizienter Software. [vgl. Pomb1993]“

Diese Definitionen zeigen die Bedeutung des Begriffes Software Engineering schon recht gut. Besonders interessant ist auch der chronologische Wandel der Begriffsbedeutung, der in den Definitionen erkennbar ist. Hier werden nun diese Definitionen zu einer neuen, aktuelleren Definition zusammengefasst.

„Die Herstellung großer Programmsysteme bringt neue, anders geartete Probleme mit sich als die Herstellung kleiner Programme und weist viele Ähnlichkeiten mit der Herstellung anderer technischer Produkte auf. Die Hauptprobleme dabei sind:

- Spezifikation der Anforderungen
- Beherrschung der Komplexität
- Zerlegung eines Systems in Teilsysteme
- Spezifikation der Schnittstellen zwischen den Teilsystemen
- Wiederverwendbarkeit von Bausteinen, Entwicklung von Halbfabrikaten
- Projektorganisation, vor allem in Hinblick auf Arbeitsteilige Systementwicklung
- Effizienz
- Dokumentation und Wartbarkeit der Gesamtlösung
- Änderbarkeit und Erweiterbarkeit
- Übertragbarkeit auf und Anpassbarkeit an verschiedene Hardwaresysteme

Der gesunde Menschenverstand allein reicht nicht aus, um all diese Probleme zu lösen. Es ist vielmehr notwendig, den gesamten Komplex wissenschaftlich zu untersuchen, um die Voraussetzungen zur Entwicklung von Methoden und Werkzeugen zur Unterstützung der Softwareherstellung zu schaffen. Von der Disziplin Software Engineering wird daher erwartet, dass sie Methoden, Werkzeuge, Normen und Hilfsmittel bereitstellt, die es ermöglichen, die technischen Probleme (wie Spezifikation, Entwurf, Implementierung, Test, Effizienz, Wiederverwendbarkeit, Dokumentation, Wartung) und die organisatorischen Probleme (Projektorganisation, Schnittstellendefinition), die bei der Herstellung von Software auftreten, in den Griff zu bekommen und dadurch qualitativ akzeptable Software mit wirtschaftlich vertretbarem Aufwand zu produzieren und einzusetzen.

Davon ausgehend wollen wir den Begriff Software Engineering folgendermaßen definieren:

Software Engineering ist die praktische Anwendung wissenschaftlicher Erkenntnisse für die wirtschaftliche Herstellung und den wirtschaftlichen Einsatz qualitativ hochwertiger Software. [Pomb1993]„

Nachdem nun der Begriff Software Engineering beschrieben wurde soll auf den Software Engineering Prozess eingegangen werden. Dazu soll zuerst einmal geklärt werden warum ein Software Engineering Prozess überhaupt sinnvoll ist.

„Wenn man mit einer komplexen Aufgabe konfrontiert ist, versucht man, den Lösungsprozess systematisch zu gliedern, d.h. ein Vorgehensmodell zu definieren. Ein solches Vorgehensmodell regelt den Ablauf des Lösungsprozesses. Es unterteilt ihn in überschaubare Abschnitte und soll dadurch eine schrittweise Planung, Durchführung, Entscheidung und Kontrolle ermöglichen.

Es ist naheliegend, diese Grundidee der Systemtechnik auch auf die Vorgangsweise bei der Entwicklung von Software anzuwenden. Wie andere Projekte unterteilt man auch Softwareprojekte in einzelne Phasen. Die Phasen zusammengenommen und die Ordnung ihrer zeitlichen Abfolge bezeichnet man als Software-Life-Cycle. [Pomb1993]“

Jetzt werden die allgemeinen Voraussetzungen, Rahmenbedingungen und Ziele eines Softwareprozesses umrissen um auf konkrete, praktische Software Engineering Prozesse vorzubereiten.

„Phasenmodelle postulieren im wesentlichen folgende Phasen des Software-Entwicklungsprozesses:

- Problemanalyse und Planung,
- Systemspezifikation,
- System- und Komponentenentwurf,
- Implementierung und Komponententest
- Systemtest,
- Betrieb und Wartung.

Die dem Phasenmodell zugrunde liegende Vorgehensweise bei der Software-Entwicklung beruht auf dem Prinzip, dass für jede der Phasen klar zu definieren ist, welche Ergebnisse erzielt werden müssen und dass eine Phase erst dann in Angriff genommen werden darf, wenn die vorhergehende vollständig abgeschlossen ist. Die Anwendung dieser streng sequenziellen Vorgangsweise soll dazu führen, dass Softwareprojekte besser planbar, organisierbar und kontrollierbar werden. die Realität zeigte jedoch, dass eine rein sequentielle Vorgehensweise in den seltensten Fällen durchführbar ist. Dies führte dazu, dass Modellvarianten entwickelt wurden, in denen diese streng sequenzielle Vorgangsweise aufgeweicht wurde. Außerdem wurden neue Methoden und Techniken zur Verbesserung des Software-Entwicklungsprozesses entwickelt (z.B. Prototyping zur Verbesserung des Spezifikationsprozesses oder die objektorientierte Programmierung zur Verbesserung des Entwurfs- und Implementierungsprozesses), die ihrerseits auf die Vorgehensweise im Software-Entwicklungsprozess Auswirkungen hatten und eine Abweichung vom klassischen Phasenmodell erforderten. Obwohl es in der Praxis kaum möglich sein wird, ein Phasenmodell in seiner reinen Form durchgängig anzuwenden, ist ein Softwareprojekt ohne systematische Vorgehensweise kaum erfolgreich durchzuführen. [vgl. Pomb1993]„

Nun wird noch anhand des V-Modells ein konkretes Beispiel für einen Software Engineering Prozess vorgestellt.

„Das V-Modell gliedert den Softwareentwicklungsprozess in sechs Phasen: Anforderungsanalyse, Systementwurf, Entwurf und Implementierung der Module, Modultest, Systemintegration und Systemabnahme. Letztere drei Phasen bilden die Tests für die Produkte aus den ersten drei Phasen. Der Modultest testet die Module, welche aus Entwurf und Implementierung hervorgegangen sind und den höchsten Detaillierungsgrad aller im Laufe der Softwareentwicklung entstandenen Produkte aufweisen. Die Systemintegration überprüft die Korrektheit des Systementwurfs. Die Systemabnahme zeigt die Richtigkeit der anfangs erstellten Anforderungen. Die Abbildung zeigt die grafische Darstellung der Phasen und ihre Zusammenhänge. Den Produkten und ihren Tests entsprechen die Schichten im Modell, aus deren Anordnung sich das für diese Modell namensgebende „V“ ergibt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 - Schichten des V-Modells

Die Produkte der ersten drei Phasen zusammen mit den Tests, welche diese überprüfen, werden als Modell bezeichnet:

- Anwendermodell: besteht aus Anforderungsanalyse, Systemspezifikation und abgenommenen System.
- Architekturmodell: besteht aus technischer Spezifikation, Teilsystem-Spezifikation, getestetem Teilsystem und getestetem System.
- Implementierungsmodell: besteht aus Modul-Spezifikation und getesteten Modulen

Das V-Model strukturiert den Softwareentwicklungsprozess in einer sequenziellen Abfolge von Phasen. Als wesentlichen Fortschritt betont es die Zusammengehörigkeit von Produkten und die überprüfenden Tests. Anfällig ist es jedoch für Fehler in frühen Phasen, welche bei später Entdeckung zu einem beträchtlichen Aufwand für deren Korrektur führen können. [vgl. Zuse2000]“

I. Theorie

2 Requirements Engineering

Die Entwicklung von Software macht erst dann Sinn, wenn geklärt und genau definiert ist wo, für welche Zwecke und von welchen Benutzern diese Software eingesetzt werden wird. Werden diese Anforderungen nicht oder unzureichend überprüft ist es möglich, dass unvollständige oder unbrauchbare Software entwickelt wird. Um das zu vermeiden werden am Beginn eines Softwareprojektes die Anforderungen an die neue Software in Erfahrung gebracht und Dokumentiert. Auf dieser Dokumentation aufbauen wird dann anschließend die Entwicklung aufgebaut.

Zunächst soll einmal geklärt werden um was es sich bei Anforderungen handelt. “Requirements are definded during the early stages of a system development as a specification of what should be implemented. They are descriptions of how the system should behave, application domain information, constraints on the system’s operation, or specifications of a system property or attribute. Sometimes they are constraints on the development process of the system. [Koto1998]” Anforderungen sind also Angaben die ein System in seiner Funktion und seinen Eigenschaften möglichst genau beschreiben.

In diesem Kapitel soll zuerst der Prozess, den eine Anforderungsanalyse durchläuft, beschrieben werden. Dabei wird auf die einzelnen Phasen eingegangen denen es bedarf um auf ein gutes und vor allem vollständiges Anforderungsanalysedokument zu kommen, das dann von Entwicklern aber auch von Kunden und Anwendern gelesen werden soll. Aus diesem Grund ist es besonders wichtig in der Ausführung eines Anforderungsanalysedokuments nicht zu technisch zu werden, da man das Dokument auch für den Kunden und den Anwender lesbar gestalten und es dem technischen Entwurf des Systems nicht vorgreifen sollte, indem man technische Entscheidungen trifft, die den Designer später einschränken könnten.

Weiters soll auf die Art und Weise eingegangen werden, wie man Anforderungen an ein System bestimmt, analysiert und strukturiert. Es werden Methoden vorgestellt die für diese Tätigkeiten verwendet werden können. Es soll auch beschrieben werden was das Anforderungsanalysedokument als Produkt des Requirements Engineering Prozesses ausmacht und worauf man bei der Erstellung dieses Dokumentes achten sollte. Die Überprüfung dieses Anforderungsanalysedokuments stellt eine wichtige qualitätssichernde Maßnahme dar, um die Korrektheit und Vollständigkeit desselben zu gewährleisten. Es gibt einige Methoden die bei diesem Vorgang helfen können und auf die jeweils kurz eingegangen wird. Abschließend wird noch UML (Unified Modeling Language), eine Sprache die zur grafischen Darstellung von Anforderungen und Anwendungsfällen in der Anforderungsanalyse verwendet wird, vorgestellt.

2.1 Der Requirements Engineering Prozess

Zuerst soll einmal geklärt werden was unter einem Requirements Engineering Prozess zu verstehen ist. “A requirements engineering process is a structured set of activities which are followed to derive, validate and maintain a systems requirements document. Process activities include requirements elicitation, requirements analysis and negotiation and requirements validation. A complete process description should include what activities are carried out, the structuring or schedule of these activities, who is responsible for each activity, the inputs and outputs to/from the activity and the tools used to support requirements engineering. Very few organisations have an explicitly-defined and standardised requirements engineering process. The people involved in the process are responsible for deciding what to do and when to do it, what information they need, what tools they should use, etc. However, we anticipate that this situation will change over the lifetime of this book and that organisations will pay more attention to defining and improving requirements engineering processes. [Koto1998]”

Ein wichtiger Punkt ist, dass es keinen Requirements Engineering Prozess gibt, der für die Verwendung in jeder Organisation akzeptabel ist. Ein Prozess mag für das eine Unternehmen perfekt geeignet sein, wenn man dasselbe Verfahren aber bei einem anderen Unternehmen anwendet funktioniert es dort überhaupt nicht. Das heißt, dass sich jede Organisation selbst einen Prozess, der genau für das Unternehmen konzipiert ist, entwerfen muss, und nur schwer ein bei einem anderen funktionierendes Konzept übernehmen kann.

Ein Beispiel für eine solche Inkompatibilität wäre der Versuch die sehr umfassende und formelle Standard-Systementwicklungsmethode, die bei der Siemens AG in der Programm- und Systementwicklung entwickelt wurde und auch verwendet wird, für die Umsetzung von Softwareprojekten in einem Ein-Mann-Unternehmen zu verwenden. Der große Aufwand, der durch die Administration der damit verbundenen Formalitäten entsteht, würde eine effiziente Entwicklung unmöglich machen.

Ein viel fundamentaleres Problem ist allerdings, dass in vielen Organisationen überhaupt kein Verständnis dafür vorhanden ist solchen Prozessen überhaupt eine Existenzberechtigung einzugestehen. Obwohl schon in vielen Studien gezeigt wurde das strukturierte Softwareentwicklung in allen Phasen eines Projektes durchgeführt bessere Ergebnisse erzielt und auch wirtschaftlicher und effizienter ist wird in der Praxis nach wie vor desorganisiert gearbeitet. Erst langsam setzt in der Industrie ein Umdenken ein, was in einigen, vor allem größeren, Unternehmen schon in strukturierten, phasenorientierten Entwicklungsprozessen erkennbar ist.

Der Requirements Engineering Prozess kann als Black-Box mit Eingabe- und Ausgabeparametern gesehen werden. Eingabeparameter wären dabei Informationen über ein zu ersetzendes System oder über Systeme die mit dem neuen System interagieren sollen, eine Beschreibung der Anforderungen der zukünftigen Benutzer, unternehmensspezifische Standards, externe Einflussfaktoren und allgemeine Domänenwissen über den Kontext des Systems. Ausgabeparameter sind konsistente Anforderungen, über die Auftraggeber, Auftragnehmern und die zukünftigen Anwender übereinstimmen, eine detaillierte Spezifikation und Modelle welche das System aus unterschiedlichen Perspektiven zeigen und charakterisieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 - Input/Output of the Requirements engineering process

Es gibt unterschiedliche Modelle, nach denen der Requirements Engineering Prozess gestaltet sein kann, allen gemeinsam ist jedoch die grobe Aufteilung in folgende wichtige Phasen:

- Requirements elicitation and analysis: Durch Gespräche mit dem Auftraggeber und durch spezielle Methoden werden möglichst alle Anforderungen, die an das System gestellt werden sondiert, beschrieben und dokumentiert. Diese Anforderungen werden strukturiert, analysiert und bewertet. Oft werden diese Tätigkeiten auch in eigenen Phasen dargestellt, sie stehen aber miteinander in einem sehr engen Zusammenhang.
- Requirements documentation: Das Anforderungsanalysedokument ist nicht nur ein Endprodukt des Requirements Engineering Prozesses, sondern auch ein Zwischenprodukt, welches sich in jedem Durchlauf der Phasen des Prozesses verbessern sollte und welches in jedem Durchlauf der Phasen immer vollständiger und konsistenter wird.
- Requirements validation: Die gefundenen und dokumentierten Anforderungen werde auf ihre Richtigkeit, Konsistenz und vor allem Vollständigkeit hin überprüft. Diese Phase dient zur Bewertung der Qualität der bisher verwerteten Anforderungen. Deshalb wird regelmäßig an dieser Stelle des Requirements Engineering Prozesses entschieden, ob die Phasen noch einmal durchlaufen werden sollen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 - Der Requirements Engineering Prozess

Der Requirements Engineering Prozess wird sehr stark durch die individuellen Ziele der an dem Prozess aktiv oder passiv beteiligten Personen bewusst und auch unbewusst beeinflusst. Die beteiligten Personengruppen sind Domänenexperten, die Domänenwissen besitzen und dieses zur Verfügung stellen, die zukünftigen Benutzer, die Analytiker, welche das Requirements Engineering durchführen, die Systementwickler, welche das System später entwickeln sollen sowie der Projektmanager, der für die Planung und den Erfolg des Projektes verantwortlich ist. Nicht nur zwischen sondern auch innerhalb dieser Personengruppen kann es zu divergenten Zielen kommen. Aus diesen Gründen kann sich eine negative Einstellung von einem oder mehreren Beteiligten auch negativ auf den Requirements Engineering Prozess und somit auf das ganze Projekt auswirken, wenn man solche Situationen ignoriert oder nicht darauf vorbereitet ist.

Es gibt Softwareprodukte, welche den Systemanalytiker bei der Verwaltung des Requirements Engineering Prozesses unterstützen können. Es handelt sich dabei allerdings nicht um speziell für diesen Zweck entwickelte Programme sondern über allgemeine Projektmanagement-Tools, die aber für den Zweck des Requirements Engineering angepasst werden können. Wichtig für solche Programme ist die Möglichkeit alle relevanten Dokumente verwalten zu können und das Vorhandensein von Schnittstellen zur Textverarbeitung, Tabellenkalkulation und anderen Anwendungen.

Es gibt besonders in letzter Zeit immer mehr Bemühungen alle möglichen in der Praxis vorkommenden Prozesse, und somit auch Requirements Engineering Prozesse, zu optimieren und zu standardisieren. Bei diesen Vorhaben sollte immer darauf geachtet werden im Auge zu behalten was man sich von diesen Veränderungen erwartet und wie man diese am besten durchführt. Beispiele für solche Verfahren zur Prozessoptimierung und Standardisierung sind CMM (Capability Maturity Model), SPICE und Bootstrap.

2.2 Erkennen und analysieren der Anforderungen

Das richtige und vollständige Erkennen von Anforderungen ist die zentrale Grundlage für eine gute Analyse eines Systems. Erst auf diesen Anforderungen aufbauend kann man sich ein Bild vom Umfang und den potentiellen Schwierigkeiten eines Projektes machen. Aus diesem Grund steht die Erkennung und Analyse der Anforderungen am Beginn des Requirements Engineering Prozesses.

„Requirements elicitation is the usual name given to activities involved in discovering what requirements the system should provide. Technical software development staff work with customers and system end-users to find out about the application domain, the system services, the required performance of the system, hardware constraints, and so on. This process does not just involve asking people what they want; it requires a careful analysis of the organisation, the application domain and how the system is likely to be used. [Somm1997]“

Das die Anforderungen welche an das System gestellt werden vollständig und richtig erkannt werden ist von sehr großer Bedeutung. So kann ein neu entwickeltes System für den Anwender unbrauchbar sein, wenn es nicht genau den gestellten Anforderungen des Kunden und somit den Geschäftsabläufen entspricht. Allgemein ist die Akzeptanz der Anwender gegenüber einem System das genau den gestellten Anforderungen entspricht größer, da diese Anwendung die Arbeitsabläufe unterstützt und nicht bestimmt.

Ein Hauptproblem bei der Erkennung von Anforderungen ist, dass es dem Kunden und den zukünftigen Anwendern schwer fällt ihre Anforderungen genau zu beschreiben. Teilweise liegt das daran, dass sie falsche Vorstellungen von den technischen Möglichkeiten haben und den Analytiker nicht mit vermeintlich nicht so wichtigen Abläufen überfordern wollen. Um dem zu begegnen und die Kreativität des Gesprächspartners nicht zu bremsen empfiehlt es sich vor dem Gespräch zu klären, dass keinerlei Rücksicht auf etwaige technische Probleme bei der Umsetzung genommen wird und zu diesem Zeitpunkt im Projekt alles möglich ist.

Ein weiteres häufiges Szenario ist, dass in den Ausführungen teilweise Domänenwissen vorausgesetzt wird, oder für den Kunden selbstverständliche Annahmen einfach weggelassen werden. Da kann sich der Analytiker nur durch die tatsächliche Aneignung eben dieses Domänenwissens helfen, das für ihn notwendig ist um die Geschäftsabläufe zu verstehen und um einen Überblick über das System und sein Umfeld als Ganzes zu gewinnen. In einigen Fällen kann dies einen großen Zeitaufwand bedeuten, der sich allerdings in den meisten Fällen durch Fehler die nicht gemacht werden bezahlt machen wird.

Auch kann es vorkommen, dass ein Kunde oder Anwender nicht klar artikulieren kann, was genau er sich vom System erwartet und welche Anforderungen er stellen würde. Dann liegt es beim Analytiker die benötigten Informationen durch gezielte Fragen herauszuarbeiten.

Weiters kann es vorkommen, dass sich verschiedene Personen des Kunden oder einige der zukünftigen Anwender in ihren Aussagen widersprechen. In so einem Fall muss der Analytiker nicht nur herausfinden was denn die tatsächlichen Anforderungen sind, sondern er sollte auch erforschen wie es zu diesen divergenten Aussagen gekommen ist und ob diese vielleicht den Ursprung in der Organisation des Kunden haben. In diesem Fall werden einige Gespräche notwendig sein um sich ein Bild von den abzubildenden Abläufen im Unternehmen zu machen. So können es vielleicht firmenpolitische, wirtschaftliche oder andere höhere Einflüsse sein welche die Anforderungen in eine gewisse Richtung hin beeinflussen, was im Rahmen der Analyse geklärt werden sollte.

In der Praxis werden je nach Bedarf unterschiedliche Methoden verwendet um die Anforderungen an ein System zu bestimmen und zu kategorisieren. Diese Methoden unterscheiden sich in ihrer Zielsetzung, in ihren Kosten und ihrem Aufwand, haben jeweils Vorteile und Nachteile gegenüber anderen Methoden und lassen sich teilweise parallel zueinander anwenden, was auch zu besseren Ergebnissen führen kann. Die wichtigsten Methoden werden hier kurz beschrieben:

- Machbarkeitsstudie: Bevor man viel Geld in die Entwicklung eines neuen Systems investiert wird man zumeist überprüfen ob die Durchführung dieses Projektes technisch überhaupt möglich bzw. realistisch ist. So eine Machbarkeitsstudie wird von Personen mit dem nötigen technischen Hintergrundwissen durchgeführt werden, die sich dafür mit der jeweiligen Domäne auseinandersetzen müssen. Die Kosten für eine Machbarkeitsstudie sind genauso wie der Aufwand einer solchen Studie relativ gering. Im Rahmen einer Machbarkeitsstudie kann man auch gleich die wirtschaftliche Machbarkeit überprüfen indem man herausfindet ob sich die Entwicklung des betrachteten Systems finanziell überhaupt rechnen kann bzw. zu welchem Zeitpunkt das System die eigenen Kosten wieder eingebracht hat (Return of Investment). Die Friktionspunkte dieses Verfahrens sind die Bestimmung der kritischen Bereiche des Systems sowie eine realistische Einschätzung der technischen und wirtschaftlichen Machbarkeit des Projektes in der konkreten Situation. Bei einem Projekt, das neue Problemstellungen aufweist, zu denen es bis jetzt keine Referenzlösungen gibt, empfiehlt es sich wahrscheinlich eine Machbarkeitsstudie durchzuführen, während bei einem relativ einfachen und wenig innovativen Projekt ruhig darauf verzichtet werden kann.
- Sondierungsgespräche: Schon zu Beginn des Projekts sollte geklärt werden von welchen Personen man welche Art von Information bekommen kann und welchen Wert diese Information haben wird. Die unterschiedlichen Personengruppen die mit dem Projekt zu tun haben werden oft unterschiedliche Anforderungen stellen die auch unterschiedlich zu bewerten sein werden. Auch sollte man auf etwaige firmenpolitische oder andere externe Einflüsse auf die Anforderungen achten um sich ein genaues Bild vom jeweiligen Unternehmen zu machen. Wahrscheinlich kann man nur dann ein geeignetes System entwickeln, wenn man die Vorstellungen und die Situation des Kunden und die der zukünftigen Anwender gut genug kennen gelernt hat. Kosten und Aufwand für solche Gespräche werden sehr unterschiedlich, in der Regel jedoch relativ gering sein.
- Technische Voraussetzungen: Ebenfalls möglichst früh im Projekt sollten die technischen Voraussetzungen überprüft werden, da sich diese Rahmenbedingungen vor allem was den Aufwand angeht auswirken können. Dazu gehört zu überprüfen auf welchem System die Software verwendet werden wird und mit welchen anderen Systemen sie zusammenarbeiten soll. Diese Überprüfungen verursachen geringe Kosten und Aufwand.
- Perspektivenanalyse: Die Anforderungen werden aus möglichst vielen verschiedenen Perspektiven erhoben. Mögliche Perspektiven sind zum Beispiel die zukünftigen Anwender und der Kunde, der die Software kaufen soll. Jede dieser Gruppen kann Anforderungen an dieses System stellen, die sich vielleicht wiedersprechen oder unter Umständen anders gewichtet werden. In solchen Fällen können diese strittigen Punkte noch im Rahmen der Anforderungsanalyse ausgeräumt werden, was hohe Kosten oder vielleicht sogar das Scheitern des Projektes verhindern kann. Die Kosten und der Aufwand für solche Erhebungen können relativ hoch werden, da dieses Verfahren recht komplex ist und bei größeren Projekten ohne Softwareunterstützung zu unübersichtlich werden kann. Ein entscheidender Punkt bei diesem Verfahren ist die Vorerfahrung des Systemanalytikers.
- Prototyping: Hier werden schon während dem Requirements Engineering Prozess teilweise oder nicht funktionale Prototypen erstellt, die dabei helfen sollen zu evaluieren ob die Analyse in die richtige Richtung geht. Diese Prototypen werden dann dem Kunden und den zukünftigen Anwendern präsentiert. Diese Methode ist sowohl finanziell als auch zeitlich sehr aufwendig. Wichtig dabei ist gegenüber dem Kunden darauf hinzuweisen, dass es sich bei dem Prototypen keineswegs um ein fertiges Produkt oder ein unveränderliches Teilstück handelt, und dass somit Kritik nötig und erwünscht ist.
- Anwendungsfälle: Bei diesem Verfahren werden gemeinsam mit den zukünftigen Benutzern Anwendungsfälle durchgespielt und besprochen, um das System gemäß den realen Geschäftsfällen entwerfen zu können. Wichtig dabei ist, dass keine vielleicht unbedeutenden Details außer acht gelassen werden. Besonders bei großen Projekten kann die Anzahl dieser Anwendungsfälle sehr groß und diese sehr komplex sein. Dadurch entsteht bei diesem Verfahren ein hoher Aufwand.

Der Grund für die Wichtigkeit der genauen Erfassung aller Anforderungen liegt darin, dass es immer das Ziel sein muss, ein System zu entwerfen, das die Geschäftsabläufe des Kunden abbildet und die Anwender unterstützt, und nicht ein System, das die Abläufe im Unternehmen diktiert und den Anwender determiniert. Sollten die tatsächlichen Geschäftsabläufe in einem Unternehmen unstrukturiert und ineffizient sein, so hilft es dem Kunden nicht ein System zu bauen, das klare und strukturierte Abläufe voraussetzt, denn mit so einem System werden die Anwender nicht arbeiten können. Auch wird es in den meisten Fällen nicht sinnvoll sein die schlechten Strukturen und Prozesse eines Kunden in die Software zu übernehmen, was aber wahrscheinlich in der Praxis der häufigste Fall sein wird. Die beste Herangehensweise wäre, dem Kunden die organisatorischen Probleme in seinem Unternehmen aufzuzeigen und ihm deren Verbesserung nahe zu legen, um dann diese verbesserten Geschäftsabläufe des Kunden in der Software abzubilden. So eine grundlegende Diskussion mit einem Kunden wird jedoch in der Praxis vielleicht im Bereich des EDV-Consulting nicht aber im Bereich der Softwareentwicklung gangbar sein.

2.3 Das Anforderungsanalysedokument

“The requirements document is an official statement of the system requirements for customers, end-users and software developers. Depending on the organisation, the requirements document may have different names such as the ‘functional specification’, the ‘requirements definition’, the ‘software requirements specification (SRS)’, the ‘safety/quality plan’, etc. These documents are all basically similar. They specify what services the system should provide, system properties such as reliability, efficiency, etc. and the constraints on the operation and (sometimes) the development of the system. [Somm1997]”

Das Anforderungsanalysedokument ist gleichzeitig ein Produkt und ein Zwischenprodukt des Requirements Engineering Prozesses, das sich immer mehr verbessern und vervollständigen soll, bis es der Überprüfung der Anforderungen gerecht wird. Oft müssen dafür die einzelnen Phasen des Requirements Engineering Prozesses mehrmals durchlaufen werden.

Bei der Erstellung eines guten Anforderungsanalysedokuments gibt es einige Kriterien die man unbedingt beachten sollte:

- Die Anforderungen sollten strukturiert, eindeutig und genau beschrieben werden. Die strukturierte Aufnahme der Anforderungen in das Anforderungsanalysedokument macht es besser lesbar und bringt die einzelnen Anforderungen besser zur Geltung. Es wird klar zwischen den einzelnen Anforderungen und Anwendungsfällen unterschieden, wodurch Unklarheiten bei den Lesern des Dokumentes vermieden werden. Eine eindeutige Beschreibung der Anforderungen soll dafür sorgen dass jeder Leser des Anforderungsanalysedokuments den Inhalt auf die gleiche Art und Weise interpretiert und sich somit ein zu den anderen Lesern konsistentes Bild des Systems macht. Durch die genau Beschreibung wird erreicht, dass der Leser möglichst wenige Annahmen selber treffen muss und viele Fragen des Lesers schon im Dokument beantwortet werden.
- Es sollte beim Schreiben eines Anforderungsanalysedokuments darauf geachtet werden eine möglichst einfach Sprache zu verwenden um unnötige Komplexität und Missverständnisse zu vermeiden. Weiters sollten Begriffe und vor allem Fachvokabel konsistent eingesetzt werden, da es sonst zu Fehlern in der weiteren Entwicklung des Projektes kommen kann. Außerdem ist auf eine exakte Ausdrucksweise Wert zu legen.
- Um das Verständnis des Textes zu erleichtern sollten beschriebene Abläufe und Anforderungen durch Grafiken und Diagramme unterstützt werden. Dabei sollte man auf eine konsistente Darstellung achten und nach Möglichkeit auf vorhandene Beschreibungssprachen zurückgreifen. Dieses visualisierten Inhalte dürfen jedoch nicht zu unübersichtlich aufgebaut sein. Bei komplexeren Zusammenhängen lassen sich solche Diagramme aufteilen bzw. abstrahieren. Ein Beispiel für einen solchen Standard ist UML (Unified Modeling Language).
- Anforderungen sollten nicht nur relativ zueinander sondern gegebenenfalls auch durch konkrete Werte angegeben sein. Zum Beispiel wird man eine Liste der Werte akzeptabler Antwortzeiten eines Systems für die verschiedenen Aktionen angeben oder die Zuverlässigkeit des Systems über MTBF (Mean Time Between Failure) und MTTR (Mean Time To Repair) definieren. Diese Angaben lassen sich für Entscheidungen in der Entwicklung und später für Akzeptanztests nutzen. Wichtig ist, dass diese Werte objektiv messbar sein müssen.

2.4 Überprüfung der Anforderungen

„The objectives of requirements validation are to check the set of requirements which have been defined and to discover possible problems with these requirements. The process should involve system stakeholders, requirements engineers and system designers.

Requirements problems might be:

- lack of conformance to quality standards
- poorly worded requirements which are ambiguous
- requirements conflicts which were not detected during the analysis process.

These problems must be solved before the requirements document is approved. To fix these problems, you usually have to re-enter the earlier process stages of requirements elicitation, analysis and negotiation. [Somm1997]“

Der Grund für die genaue Überprüfung des Anforderungsanalysedokumentes liegt darin, dass Inkonsistenzen oder Fehler, die in diesem Dokument verbleiben, das restliche Projekt sehr strak negativ beeinflussen können. Weil aber nicht entdeckte Fehler mit dem Fortschreiten des Projektes immer teuerer werden, unter anderem da sie im System implementiert werden, und die Phase der Analyse am Anfang eines Projektes steht, besteht von diesen Fehlern her die größte potentielle Gefahr da sie sich, wenn sie nicht gefunden werden konnten, später durch das ganze Projekt ziehen.

Die Überprüfung der Anforderungen besteht vor allem darin die Qualität des Anforderungsanalysedokumentes sicherzustellen. Ein Problem dabei ist, dass man nicht die Möglichkeit hat das Dokument mit der Realität zu vergleichen. Als Grundlagen der Überprüfung verwendet man deshalb zumeist die Spezifikationen. Außerdem kann man nie zeigen, dass das Anforderungsanalysedokument tatsächlich korrekt ist. Durch die Überprüfung kann man nur das eigene Vertrauen darin, dass das Dokument vollständig und korrekt ist, steigern. In der Praxis läuft dieser Prozess so ab, dass mehrere Leute das Dokument lesen werden und sich dabei überlegen ob es in sich schlüssig ist. Ist das nicht der Fall werden sie diese Punkte aufzeigen. Da dieser Vorgang kein sichtbares Ergebnis liefert und außerdem schwer in seiner Effizienz zu bewerten ist wird er in vielen Projekten vernachlässigt oder einfach ausgelassen, was jedoch oft zu Problemen bei der Entwicklung oder, was noch schlimmer ist, erst bei den Akzeptanztests führt.

Es gibt einige Methoden die in der Praxis verwendet werden um ein Anforderungsanalysedokument zu überprüfen. Einige davon sollen hier kurz beschrieben werden:

- Standards: Es werden Standards bezüglich des Dokuments im allgemeinen und den Anforderungen definiert, an die sich der Autor halten sollte. Sobald das Anforderungsanalysedokument fertiggestellt wurde, wird es auf diese Standards hin überprüft. Solche Standards betreffen allerdings nur die Struktur des Dokuments oder andere Formalismen und man wird damit Fehler bei weitem nicht ausschließen können. In der Praxis wird sich bei dieser Methode eine Person das Dokument durchlesen. Vorteile dieser Methode sind die geringen Kosten und der geringe Aufwand in der Durchführung.
- Inspektion: Das Dokument wird von einer Gruppe von Personen, die am besten nicht am Projekt beteiligt sind und möglichst unterschiedliches Hintergrundwissen haben, formal inspiziert und anschließend besprochen. Dieser Prozess lässt sich beliebig oft wiederholen, wobei bei jeder Re-Inspektion die Anzahl der gefundenen Fehler geringer sein wird. Die Inspektoren sollen das Dokument formal gemäß einer speziellen Lesetechnik durcharbeiten. Hier gibt es checklistenbasierte und perspektivenorientierte Lesetechniken. Beim checklistenbasierten Lesen arbeitet der Inspektor einige Fragen über das Dokument ab. Beim Perspektivenlesen soll er das Dokument zum Beispiel aus dem Blickwinkel eines Anwenders, eines Designers oder eines Testers sehen und dahingehend lesen und auf Fehler hin überprüfen. Die Kosten und der Aufwand für das Abhalten einer formalen Inspektion sind relativ hoch.
- Multi-Disciplinary: Bei diesem Verfahren wird das Dokument von einer Gruppe von Personen mit unterschiedlichem Fachwissen geprüft. Dadurch, dass jede Person das eigene Fachwissen mitbringt und das Dokument aus der eigenen Perspektive liest, soll die Anzahl der gefundenen Fehler vergrößert werden. Ein Problem dieser Methode ist vor allem geeignete Personen zu finden und auszuwählen. Vorteile dieser Methode sind die relativ geringen Kosten der Durchführung.
- Benutzerhandbuch: Diese Methode schlägt vor anhand des Anforderungsanalysedokuments ein provisorisches Benutzerhandbuch zu verfassen, welches alle Funktionen und Eigenschaften des Systems abdecken soll. Wenn das nicht möglich ist sind geeignete Annahmen zu treffen, das Handbuch sollte aber unbedingt vollständig sein. Durch diesen Vorgang wird man dazu gezwungen die Anforderungen erneut genau zu analysieren, wodurch man dann die Fehler aus dem Dokument herausarbeiten kann. Vorteile dieser Methode sind, dass dieses Benutzerhandbuch den Anwendern die den Prototypen testen für ihre Arbeit zur Verfügung gestellt und später als Grundlage für den Entwurf des richtigen Benutzerhandbuches verwendet werden kann.
- Testfälle: Bei diesem Verfahren sollen für die einzelnen Anforderungen Testfälle modelliert werden, welche überprüfen sollen ob das System den Anforderungen entspricht. Mit dem Durchspielen dieser Testfälle können Fehler und Inkonsistenzen im Anforderungsanalysedokument gefunden werden. Die gefundenen Testfälle können im weiteren Verlauf des Projektes in die Planung des Systemtests einfließen.
- Ausformulierung: Die systematische Ausformulierung von formalen Notationen, Grafiken und Diagrammen in natürliche Sprache kann zur Überprüfung dieser Elemente des Dokumentes dienen. Dadurch lassen sich Fehler und Ungereimtheiten finden und das Modell kann auf seine Vollständigkeit hin überprüft werden. Einige Personen, die mit dem Projekt zu tun haben, werden sich vielleicht nicht mit den Notationen auseinandergesetzt haben, die den Diagrammen und Grafiken zugrunde liegen. Durch die Ausformulierung dieser Elemente können diese Personen dann auch die modellierten Darstellungen überprüfen. Ein Nachteil dieser Methode ist der relativ hohe Aufwand dieses Verfahrens.

Diese Methoden oder Variationen davon können einzeln oder in Kombination miteinander angewandt werden. Je intensiver das Anforderungsanalysedokument überprüft worden ist, desto größer wird die Wahrscheinlichkeit sein, dass man das Projekt auf einer korrekten und vollständigen Beschreibung der Anforderungen basierend weiter entwickeln kann. Oft wird allerdings der Nutzen dieser Methoden vom Kunden bzw. Geldgeber unterschätzt und somit wenig in die Überprüfung der Dokumente investiert. Dadurch nimmt man aber in Kauf, das es zu einem späteren Zeitpunkt im Projekt zu Problemen kommen kann, die durch eine gründliche Überprüfung der Dokumente vermieden hätten werden können.

2.5 Requirements Engineering Techniken

Beim Verfassen von Anforderungsanalysedokumenten und anderen Dokumenten die im Rahmen eines Softwareprojektes entstehen wird oft auf verschiedene Notationen und Standards zurückgegriffen um Anforderungen und Anwendungsfälle grafisch in Form eines Diagramms darzustellen. Dadurch soll die Anschaulichkeit der Beschreibung verbessert und dem Leser der Überblick über das System erleichtert werden.

Unified Modeling Language: An dieser Stelle wird UML (Unified Modeling Language) als eine der aktuell bedeutendsten Standards stellvertretend für andere Notationen und Modellierungsstandards vorgestellt und auf ihre Bedeutung im Hinblick auf die Verwendung bei der Anforderungsanalyse beschrieben.

„The Unified Modeling Language (UML) is al language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems. [OMG2000]“

Der UML-Standard besteht aus folgenden Teilen, wobei hier nur auf die wichtigsten Aspekte der Anwendungsfalldiagramme und der Klassendiagramme eingegangen werden soll:

Das Anwendungsfalldiagramm besteht regelmäßig aus jeweils einem oder mehreren Aktoren, Kommunikationslinien und Anwendungsfällen und kann durch weitere Elemente ergänzt werden.

Ein Anwendungsfall ist eine abgeschlossene, zusammenhängende Einheit, welche einen Teil der Funktionalität des Systems repräsentiert. ein Anwendungsfall sollte eine logisch zusammengehörige, wiederkehrende Anwendung innerhalb des Systems darstellen.

Ein Aktor ist ein bestimmter Benutzer des Systems, der genau definierte Recht und Aufgaben innerhalb des Systems hat. ein Aktor hat genau dann eine Beziehung zu einem Anwendungsfall, falls er ermächtigt ist, diesen durchzuführen.

Eine Kommunikationsbeziehung ist die einzige mögliche Beziehung zwischen einem Aktor und einem Anwendungsfall.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 - Ein Beispiel für ein Anwendungsfalldiagramm

Eine Generalisierungsbeziehung kann zwischen zwei Aktoren oder zwischen zwei Anwendungsfällen bestehen. Das Objekt auf das die Pfeilspitze zeigt ist dann als das allgemeinere Objekt zu verstehen, das Objekt am Pfeilschaft als eine speziellere Form des Objektes.

Die erweiternde Beziehung kann zwischen zwei Anwendungsfällen gesetzt werden und bedeutet, dass der Anwendungsfall am Pfeilschaft den Anwendungsfall an der Pfeilspitze optional erweitern kann.

Die einschließende Beziehung kommt auch nur zwischen zwei Anwendungsfällen vor und sagt aus, dass der Anwendungsfall am Pfeilschaft den Anwendungsfall an der Pfeilspitze benutzt. Die Beschriftung des Pfeils mit „<<include>>“ wird der Übersicht halber zumeist weggelassen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 - Weitere Elemente der Anwendungsfalldiagramme

Der folgende Anwendungsfall enthält einige Beziehungen und soll das Verständnis deren Bedeutung erleichtern. Die Generalisierung zwischen Mensch und Urlauber sagt aus, dass ein Urlauber ein spezieller Typ von Mensch ist und man einen Urlauber allgemeiner als Mensch bezeichnen kann. Es fällt auf, dass der Aktor Mensch keinen Anwendungsfall ausführen kann. Er wurde hier nur eingeführt um die Generalisierungsbeziehung zu erklären, in der Praxis jedoch sollten keine Aktoren notiert werden, die keine Anwendungsfälle ausführen können. Die beiden einschließenden Bedingungen sagen aus, dass man, wenn man eine Flugreise macht mit dem Auto zum Flughafen fahren und mit einem Flugzeug fliegen muss. Die erweiternde Beziehung steht dafür, dass man mit einem Flugzeug fliegen kann wenn man zuvor mit einem Auto gefahren ist, aber dies nicht muss. Natürlich handelt es sich hierbei um ein relativ einfaches Beispiel, das die Wirklichkeit nicht unbedingt realistisch abbilden wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 - Anwendungsfalldiagramm mit Beziehungen

Jeder Anwendungsfall soll nicht nur dargestellt sondern auch exakt beschrieben werden. Zuerst muss der Anwendungsfall durch eine eindeutige Nummer identifizierbar sein, um auf ihn referenzieren zu können. Weiters sollte der Anwendungsfall durch einen Titel, eine Kurzbeschreibung und Vorbedingungen, die erfüllt sein müssen damit der Anwendungsfall ausgeführt werden kann, beschrieben werden. Dann wird der genaue Ablauf der Ereignisse und die Reaktionen des Systems festgelegt. Ereignisse werden durch „E“ und eine eindeutige Nummer, Antworten des Systems durch „A“ und diese Nummer identifiziert. Alternative Ereignisse werden mit „AE“ und der Nummer bezeichnet. Alle weiteren Informationen zu dem jeweiligen Anwendungsfall werden dann unter Anmerkungen zusammengefasst.

Klassendiagramme bestehen aus Klassen und aus Beziehungen zwischen diesen Klassen. Klassen bestehen aus einer eindeutigen Bezeichnung und können über Attribute und Methoden verfügen. Klassen können entweder nur mit der Bezeichnung, mit Bezeichnung und Attributen oder mit Bezeichnung, Attributen und Methoden dargestellt werden. Abstrakte Klassen werden mit „{abstract}“ gekennzeichnet.

[...]