Anforderungen

Anforderungen (requirements) legen fest, was man von einem Softwaresystem erwartet. Gibt es einen bestimmten Auftraggeber, dann wird dieser die wichtigsten Anforderungen bestimmen. Wird ein Produkt für den anonymen Markt entwickelt, dann werden die Marketingabteilung und der Vertrieb die wesentlichen Anforderungen festlegen. Alle Personen und Organisationen, die ein Interesse an einer Softwareentwicklung haben oder vom Einsatz des Softwaresystems betroffen sind, werden mit dem englischen Begriff Stakeholder (dt. i. e. Teilhaber, Akteur, Interessenvertreter) bezeichnet.

Der IEEE Standard 830 (Software Requirements Specification) unterscheidet funktionale Anforderungen (functional requirements) von nichtfunktionalen Anforderungen (non-functional requirements). Eine funktionale Anforderung legt eine vom Softwaresystem oder einer seiner Komponenten bereitzustellende Funktion oder bereitzustellenden Service fest. Funktionale Anforderungen lassen sich gliedern in

• Anforderungen, die die Statik des Systems beschreiben,
• Anforderungen, die die Dynamik des Systems beschreiben und
• Anforderungen, die die Logik des Systems beschreiben.

Nichtfunktionale Anforderungen, auch Technische Anforderungen oder „Quality of Service“ (kurz QoS) genannt, meinen Aspekte wie Zuverlässigkeit, Verfügbarkeit, Nebenläufigkeit, Konsumierbarkeit, Internationalisierung, Informationssicherheit, Service-Anforderungen und Support. Nichtfunktionale Anforderungen haben großen Einfluss auf die Softwarearchitektur. Außerdem können sie zueinander im Konflikt stehen: So ist beispielsweise Sicherheit häufig im Widerspruch zu Benutzbarkeit, Speichereffizienz ist meist gegenläufig zu Laufzeiteffizienz.

In Anlehnung an IEEE 830 nennt Balzert eine Reihe von Kriterien, die jede einzelne Anforderung erfüllen soll:

• Korrekt (correct): Die Anforderung ist korrekt, wenn das zu erstellende Softwaresystem sie erfüllt.
• Eindeutig (unambiguous): Die Anforderung wird von allen Stakeholdern gleich interpretiert.
• Vollständig (complete): Die Anforderung muss die geforderte Funktionalität vollständig beschreiben.
• Konsistent (consistent): Die Anforderung muss in sich widerspruchsfrei sein.
• Klassifizierbar nach Wichtigkeit (ranked for importance): Der Anforderung kann eine Wichtigkeitsstufe zugeordnet werden. Einige Anforderungen können essenziell sein, z. B. bei lebenskritischen Anwendungen, während andere nur wünschenswert sind. Mögliche Klassen sind: „Essenziell“ (essential), „Bedingt“ (conditional) oder „Optional“ (optional).
• Klassifizierbar nach Stabilität (ranked for stability): Unter Stabilität wird hierbei die Anzahl der erwarteten Änderungen bei einer Anforderung verstanden.
• Überprüfbar (verifiable): Die Anforderung muss so beschrieben sein, dass sie nach der Realisierung überprüfbar bzw. testbar ist.
• Verfolgbar (traceable): Die Anforderung muss sich eindeutig identifizieren lassen, z. B. durch eine eindeutige Anforderungsnummer, die unverändert bleibt.

Aufgabe des Requirements Engineers ist es, in Zusammenarbeit mit den Stakeholdern diese Qualitätskriterien an Anforderungen so gut wie möglich zu erreichen. In der Praxis ist man jedoch oft weit davon entfernt, diese zu erreichen: „Diese Problematik entsteht dadurch, dass die Gesprächspartner kein vollständiges Modell des zu entwickelnden Systems ‚im Kopf‘ haben.“

Lasten- und Pflichtenheft

Nach der DIN 69901 ist ein Lastenheft eine „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines (Projekt-)Auftrags“: Das Lastenheft ist somit die Grundlage zur Lösungsfindung im Projektverlauf. Im Wesentlichen werden dabei folgende Ziele verfolgt

• Die Beschreibung der Ausgangslage zum Projekt (Ist-Situation, Ziel und Zweck, Geltungsbereich etc.),
• die Beschreibung der Anforderungen an das zu realisierende Projekt,
• die Sicherstellung, dass wichtige Themenkreise nicht vergessen werden,
• die klare Abgrenzung zum Umfang des zu erstellenden Projekts und
• die Übereinstimmung über Art und Umfang der Projektaufgabe hinsichtlich der Vorstellungen des Auftraggebers und des Auftragnehmers.

Nach der DIN 69901 enthält ein Pflichtenheft „vom Auftragnehmer erarbeitete Realisierungsvorgaben auf der Basis des vom Auftraggeber vorgegebenen Lastenhefts“. Aus der Sicht des Auftragnehmers stellt das Pflichtenheft die formelle und detaillierte Antwort auf die Anforderungen des Auftraggebers dar, die zuvor im Lastenheft beschrieben wurden. Die zu erbringenden Ergebnisse des Auftragnehmers werden dadurch in erforderliche Tätigkeiten (Pflichten) umgesetzt.

Lasten- und Pflichtenheft sollen den Systemanalytiker also in die Lage versetzen, das OOA-Modell zu erstellen. Sie besitzen jedoch ein niedrigeres Detaillierungsniveau als das OOA-Modell.

Klassendiagramm

In der UML-Notation werden Klassen als dreigeteilte Rechtecke angegeben, deren Bestandteile der Klassenname, eine Liste über alle Attribute und eine Liste über alle Operationen und Eigenschaften sind. Dabei werden diese drei Rubriken jeweils durch eine horizontale Linie getrennt. Wenn die Klasse keine Eigenschaften oder Operationen besitzt, kann die unterste horizontale Linie entfallen. Klassennamen beginnen mit einem Großbuchstaben und sind Substantive im Singular. Attribute werden mindestens mit ihrem Namen notiert und können zusätzlich Angaben zu ihrem Typ (d. h. Klasse), einen Initialwert, Eigenschaftswerte und Zusicherungen enthalten. Operationen werden ebenfalls mindestens mit ihrem Namen aufgeführt und können zusätzlich Angaben zu möglichen Parameter und deren Klasse, Initialwerte sowie eventuelle Eigenschaftswerte und Zusicherungen enthalten. Eine Operation meint dabei die abstrakte Definition einer Funktionalität – im Gegensatz zur Methode, der konkreten Implementierung einer Operation.

Eine Assoziation modelliert Verbindungen zwischen Instanzen einer oder mehrerer Klassen. Es ist jedoch üblich, von einer Assoziation zwischen Klassen zu sprechen, obwohl streng genommen die Objekte dieser Klasse gemeint sind. Im häufigsten Fall handelt es sich um eine Beziehung zwischen genau zwei Klassen. Grafisch wird eine Assoziation durch eine Linie dargestellt. Sind mehr als zwei Typen an einer Assoziation beteiligt, wird diese durch eine Raute dargestellt, an die zu den Objekten führende Linien anliegen. Eine reflexive Assoziation besteht dagegen zwischen Instanzen derselben Klasse. Die Kardinalitäten einer Assoziation spezifizieren, wie viele Objekte der beteiligten Klasse ein bestimmtes Objekt kennen. Mann unterscheidet zwischen Kann- und Muss-Assoziationen: Eine Kann-Assoziation hat als Untergrenze eine Kardinalität von 0, eine Muss-Assoziation eine Kardinalität von 1 oder größer. Eine unbestimmte Obergrenze wird durch das Zeichen * gekennzeichnet. Assoziationen können benannt werden. Beschreibt der Name nur eine Richtung der Assoziation, wird die Leserichtung durch ein schwarzes Dreieck oder einen Pfeil angegeben. Ist die Bedeutung der Assoziation offensichtlich, kann der Name fehlen.

Eine Aggregation ist eine spezielle Assoziation, die eine Rangordnung auf den verbundenen Instanzen einer Klasse definiert, die sich durch „ist Teil von“ bzw. „besteht aus“ beschreiben lässt (Teil-Ganzes-Beziehung). Man spricht von einem gerichteten azyklischen Graphen: Wenn B Teil von A ist, dann darf A nicht Teil von B sein. Kann ein Teilobjekt mehreren Aggregationsobjekten zugeordnet werden, spricht man von „shared aggregation“ (dt. i. e. geteilte Aggregation) oder „weak ownership“ (dt. i. e. schwacher Besitz). Im Klassendiagramm wird eine Aggregation durch eine nicht ausgefüllte Raute am „Ganzes-Ende“ der Assoziationslinie gekennzeichnet.

Eine Komposition ist eine noch stärkere Form der Aggregation. Neben einer Teil-Ganzes-Beziehung gelten noch folgende Bedingungen:

• Jedes Objekt der Teilklasse darf immer nur Komponente eines einzigen Objekts der Aggregationsklasse sein, d. h. die Kardinalität bei der Aggregationsklasse darf jeweils nicht größer als 1 sein.
• Wird „das Ganze“ gelöscht, dann werden automatisch auch seine Teile gelöscht.
• Die dynamische Semantik des Ganzen gilt auch für seine Teile. Wird beispielsweise das Ganze kopiert, werden auch seine Teile kopiert.

Bei der Komposition wird das „Ganzes-Ende“ durch eine gefüllte oder schwarze Raute gekennzeichnet.

Die Vererbung dient dazu, aufbauend auf existierenden Klassen neue zu schaffen, wobei die Beziehung zwischen ursprünglicher und neuer Klasse dauerhaft ist. Eine neue Klasse kann dabei eine Erweiterung oder eine Einschränkung der ursprünglichen Klasse sein. Neben diesem konstruktiven Aspekt dient Vererbung auch der Dokumentation von Ähnlichkeiten zwischen Klassen, was insbesondere in den frühen Phasen des Softwareentwurfs von Bedeutung ist. Auf der Vererbung basierende Klassenhierarchien spiegeln strukturelle und verhaltensbezogene Ähnlichkeiten der Klassen wider. Die vererbende Klasse wird meist Basisklasse (auch Elternklasse) genannt, die erbende abgeleitete Klasse (Kindklasse). Den Vorgang des Erbens nennt man meist Ableitung oder Spezialisierung, die Umkehrung hiervon Generalisierung, was ein vorwiegend auf die Modellebene beschränkter Begriff ist. In der UML wird eine Vererbungsbeziehung durch einen Pfeil mit einer dreieckigen Spitze dargestellt, der von der abgeleiteten Klasse zur Basisklasse zeigt. Geerbte Attribute und Operationen werden in der Darstellung der abgeleiteten Klasse nicht wiederholt.

Objektdiagramm

Ein Objektdiagramm kann als Sonderfall des Klassendiagramms angesehen werden. Während ein Klassendiagramm die allgemeinen „Schablonen“ und alle möglichen Beziehungen der Objekte untereinander modelliert, stellt das zugehörige Objektdiagramm die tatsächlich erzeugten Objekte, deren Attributwerte und Beziehungen innerhalb eines begrenzten Zeitraums der Laufzeit dar. Die Darstellung umfasst somit typischerweise Ausprägungsspezifikationen von Klassen und Assoziationen. Wie sich ein Objekt in einer bestimmten Situation verhält, hängt wesentlich von seinem Zustand ab. Dieser ergibt sich aus der konkreten Wertbelegung seiner Attribute.

Die graphische Darstellung eines Objekts ist der einer Klasse sehr ähnlich. Objekte werden ebenfalls durch Rechtecke repräsentiert. Im ersten Feld ist der Objektname zusammen mit dem Typ angegeben. Zur Unterscheidung von der Klassen-Notation wird der Name des Objekts unterstrichen. Im zweiten Feld werden Attribute mit ihren Namen und einem beispielhaften oder im jeweiligen Zusammenhang aktuellen Wert aufgeführt. Operationen werden nicht genannt, da diese keine objekt-individuellen Ausprägungen besitzen und für alle Objekte einer Klasse identisch sind. Stattdessen wird in Kommunikations- und Sequenzdiagrammen der konkrete Nachrichtenaustausch zwischen Objekten dargestellt.

Das Verhalten eines objektorientierten Systems wird durch Botschaften (auch Nachrichten genannt) beschrieben, mit denen Objekte untereinander kommunizieren. Objekte agieren dabei in den Funktionen von Sendern (Clients) und Empfängern (Suppliern): Der Sender sendet eine Botschaft mit der Aufforderung, eine Dienstleistung zu erbringen. Eine Botschaft besteht aus einem Selektor (einem Namen), einer Liste von Argumenten und geht an genau einen Empfänger. Der Empfänger interpretiert diese Botschaft und führt eine Operation aus. Der Sender der Botschaft weiß jedoch nicht, wie die entsprechende Operation ausgeführt wird (Geheimnisprinzip).

Eine aktuelle Beziehung zwischen Objekten wird Link oder Objektbeziehung genannt. Ein Link beschreibt also die konkrete Beziehung zwischen zwei Objekten einer Klasse und kann somit als eine Instanz einer Assoziation aufgefasst werden. Er wird ähnlich wie die Assoziation im Klassendiagramm als Linie zwischen den Objekten dargestellt. An den jeweiligen Verbindungsenden können Rollenbezeichnungen stehen, die das Verhalten der Objekte zueinander näher beschreiben.

Anwendungsfälle

Mit Anwendungsfällen (englisch use cases) werden die extern beobachtbaren Funktionen spezifiziert, das heißt das, was ein Anwendungssystem einem Benutzer anbieten soll. Ein Akteur ist dabei eine außerhalb des Systems liegende Einheit, die an der Interaktion mit dem System beteiligt ist. Dies kann ein Mensch sein, aber ebenso ein technisches System wie ein Betriebssystem oder ein Drucker. Folgende Regeln sind zu beachten:

• An jedem Anwendungsfall ist mindestens ein Akteur beteiligt.
• Jeder Anwendungsfall hat einen fachlichen Auslöser.
• Jeder Anwendungsfall produziert ein für die Akteure relevantes fachliches Ergebnis, d. h. ein Ergebnis von „geschäftlichem Wert“.

Anwendungsfälle werden klassischerweise so benannt, wie die Ziele aus Sicht der Akteure heißen: Mitglied anmelden, Geld abheben, Auto zurückgeben usw. Die Granularität von Anwendungsfällen kann sich stark unterscheiden: Auf sehr hohem Niveau beschreibt ein Anwendungsfall lediglich sehr grob und abstrakt, was passiert. Die Technik des Anwendungsfall-Schreibens kann jedoch bis auf Ebene von IT-Prozessen verfeinert werden, sodass das Verhalten einer Anwendung detailliert beschrieben wird. Dies widerspricht der ursprünglichen Intention von Use Cases, ist aber manchmal zweckmäßig.

Der inhaltliche Aufbau eines Anwendungsfalls folgt meistens einer zu definierenden Vorlage, die abhängig vom Kontext der späteren Benutzung des Anwendungsfalls ausgearbeitet werden muss. Meist werden für verschiedene Analysephasen auch unterschiedlich stark formalisierte Vorlagen verwendet, von der rein prosaischen Kurzbeschreibung bis zu einem vollständigen, ausgearbeiteten Anwendungsfall. Wie man „Use Cases“ strukturieren sollte und welche Bestandteile hineingehören, beschreibt beispielsweise Alistair Cockburn (Siehe dazu auch Aufbau eines Anwendungsfalls).

Ein Anwendungsfalldiagramm stellt Anwendungsfälle und Akteure mit ihren jeweiligen Abhängigkeiten und Beziehungen dar. Es ist somit ein Verhaltensdiagramm, das das erwartete Verhalten eines Systems spezifiziert, und keine Ablaufbeschreibung, wie es etwa ein Sequenz- oder Kommunikationsdiagramm ist.

Ein Anwendungsfalldiagramm enthält eine Menge von Anwendungsfällen, die durch einzelne Ellipsen dargestellt werden und eine Menge von Akteuren, die daran beteiligt sind. Diese werden durch Linien mit den entsprechenden Anwendungsfällen verbunden. Ein Rahmen um die Anwendungsfälle symbolisiert die Systemgrenzen.

Sequenzdiagramm

Eine Sequenz von Verarbeitungsschritten, die unter bestimmten Bedingungen auszuführen ist, wird Szenario genannt. Diese Schritte sollen das Hauptziel des Akteurs realisieren und ein entsprechendes Ergebnis liefern. Man unterscheidet zwei Kategorien von Szenarios: Solche, die eine erfolgreiche Bearbeitung des Geschäftsprozesses beschreiben, und solche, die zu einem Fehlschlag führen. Szenarios werden durch Interaktionsdiagramme dargestellt. Die UML bietet dafür zwei Arten von Diagrammen an: das Sequenzdiagramm und das Kommunikationsdiagramm. Sequenzdiagramme stellen den zeitlichen Ablauf in den Vordergrund, Kommunikationsdiagramme zeigen dagegen die prinzipielle Zusammenarbeit.

In Sequenzdiagrammen sollen Szenarios so präzise modelliert werden, dass deren fachliche Korrektheit diskutiert werden kann, um eine geeignete Vorgabe für Design und Implementierung zu erstellen. Sequenzdiagramme beschreiben den Austausch von Nachrichten zwischen Ausprägungen mittels Lebenslinien und stellen in der Regel einen Weg durch einen Entscheidungsbaum innerhalb eines Systemablaufes dar. Sie besitzen zwei Dimensionen: Die Vertikale repräsentiert die Zeit, auf der Horizontalen werden die Objekte eingetragen.

Jedes beteiligte Objekt wird als Rechteck dargestellt und eine gestrichelte vertikale Linie darunter, die Lebenslinie, symbolisiert dessen Existenz während eines einer bestimmten Zeit. Eine Nachricht wird in einem Sequenzdiagramm durch einen Pfeil dargestellt, wobei der Name der Nachricht über den Pfeil geschrieben wird. Synchrone Nachrichten werden mit einer gefüllten Pfeilspitze, asynchrone Nachrichten mit einer offenen Pfeilspitze gezeichnet. Nachrichten, die asynchronen Signalen entsprechen, werden gleich dargestellt wie asynchrone Operationsaufrufe. Der wesentliche Unterschied zwischen asynchronen und synchronen Nachrichten ist, dass die synchronen Nachrichten die ausgehende Lebenslinie für weitere Nachrichten „blockiert“ ist, bis diese eine Antwort erhalten hat. Dies ist bei asynchronen Nachrichten nicht der Fall. Die schmalen Rechtecke, die auf den Lebenslinien liegen, sind Aktivierungsbalken, die den „Focus of Control“ anzeigen, also jenen Bereich, in dem ein Objekt über den Kontrollfluss verfügt, und aktiv an Interaktionen beteiligt ist.

Bedingungen werden in eckigen Klammern angegeben, also in der Form [Bedingung] Operation {}. Die genannte Operation wird somit nur dann aufgerufen, wenn die Bedingung erfüllt ist. Wiederholungen werden durch * [Bedingung] Operation {} dargestellt.

Ein Sequenzdiagramm muss mit dem Klassendiagramm konsistent sein, d. h. alle Botschaften, die an ein Objekt einer Klasse gesendet werden, müssen im Klassendiagramm in der Operationsliste dieser Klasse enthalten sein.

Kommunikationsdiagramm

Das Kommunikationsdiagramm entspricht dem Kollaborationsdiagramm der UML 1.X. Es ist umbenannt worden, da der Name Kollaborationsdiagramm irreführend ist. Es gibt in der UML zwar auch das Modellelement Kollaboration, dieses hat aber nichts mit dem „Kollaborationsdiagramm“ zu tun.

Ein Kommunikationsdiagramm dokumentiert die Zusammenarbeit von Objekten und steht dem Objektdiagramm sehr nahe. Im Gegensatz dazu modelliert es jedoch nicht eine Momentaufnahme der Systemstruktur, sondern zeigt, wie die Objekte für die Ausführung einer bestimmten Operation zusammenarbeiten. Neben den Links zwischen den Objekten zeigt es auch die Botschaften, die diese einander senden. Eine solche wird in Form eines Pfeiles, der auf das empfangende Objekt zeigt, an die Verbindung zwischen zwei Objekten eingetragen. Eine Beschriftung an dem Pfeil zeigt den Inhalt der Botschaft. In der Regel teilt die Botschaft dem empfangenden Objekt mit, dass es eine seiner Operationen ausführen soll.

Objekte, die während der Ausführung neu erzeugt werden, sind mit {new}, Objekte, die während der Ausführung gelöscht werden, mit {destroyed} gekennzeichnet. Objekte, die während der Ausführung sowohl erzeugt als auch wieder gelöscht werden, sind {transient}. Analog dazu können Objektverbindungen, die im Laufe der Ausführung erstellt werden mit {new}, gelöschte Links mit {destroyed} und Verbindungen, die innerhalb des Szenario sowohl auf- als auch abgebaut werden, mit {transient} beschriftet werden.

Zustandsdiagramm

Der Zustand eines Objekts wird durch seine Attributwerte festgelegt. Je nachdem, in welchem Zustand sich nun ein Objekt befindet, kann es auf gleiche eingehende Nachrichten unterschiedlich reagieren. Dieses Verhalten von Objekten kann durch Zustandsautomaten modelliert werden: Dabei handelt es sich um eine Menge von Zuständen und eine Übergangsfunktion, die abhängig vom momentanen Zustand und dem eingehenden Ereignis den Nachfolgezustand bestimmt.

Die Zustände werden im Zustandsdiagramm als abgerundete Rechtecke dargestellt und müssen unterschiedliche Namen haben. Ein Zustandsübergang (Transition) wird als Pfeil vom Ausgangszustand zum neuen Zustand repräsentiert. Eine Transition wird mit dem Namen des Ereignisses (Triggers) beschriftet, das diese Transition auslöst. Es gibt zwei besondere Zustände: den Startzustand und den Endzustand. Jeder Zustandsautomat kann jeweils nur einen Startzustand besitzen. Der Startzustand wird im Diagramm als schwarz gefüllter Kreis und der Endzustand als schwarz gefüllter Doppelkreis gekennzeichnet.