Kapitel 1

Ziel von Aktivitäten der Spezifikation ist die Erstellung einer technischen Dokumentation der nach außen relevanten Anforderungen, nach denen ein Softwaresystem produziert werden soll. Aufbauend auf den Erkenntnissen des fachlichen Requirements Engineerings, bei der fachliche Anforderungen ermittelt, dokumentiert, geprüft und abgestimmt wurden, wird im Rahmen der Spezifikation eine stark technisch ausgeprägte Dokumentation des zu erstellenden Systems erstellt.

Dabei handelt es sich bezogen auf die Aktivitäten des Requirements Engineerings um eine Erweiterung und Detaillierung der Dokumentation von Anforderungen. Hinsichtlich Ermittlungstechniken oder Prüftechniken unterscheiden sich RE und Spezifikation nicht.

• Grundlage für die Umsetzung des Systems (Design und Implementierung)

• Grundlage für die Formulierung verschiedener Testfälle

• Durchführung und Auswertung von Tests

• Fehler der Spezifikation oder Missverständnisse beim Lesen haben weitreichende Auswirkungen auf das gesamte Projekt

Die Spezifikation eines Systems gibt aus fachlicher Sicht den technisch detaillierten Rahmen für Designentscheidungen vor. Dabei trifft eine Spezifikation keine Entscheidung darüber, wie das System intern konstruiert werden muss, sondern beschreibt stets nur die nach außen sichtbaren Systemeigenschaften. Erst beim Design werden konkrete Elemente des Systems gestaltet. Dabei muss sich an die Vorgaben der Spezifikation gehalten werden.

Die Systemgrenze des Systems markiert den Bereich, der im Rahmen des Projektes gestaltet werden kann. Alle Elemente außerhalb der Systemgrenze sind in der Regel nicht durch das Projekt beeinflussbar. Somit sind zum einen alle Use Cases innerhalb des Systems für die Spezifikation relevant. Konkrete fachliche und technische Abläufe innerhalb eines Use Cases sowie die dazu benötigten Regeln, Geschäftsobjekte und Systemkomponenten müssen spezifiziert werden.

Weiterhin erfordert jeder Schnittpunkt von Kommunikationsbeziehungen mit der Systemgrenze eine Systemschnittstelle, die detailliert spezifiziert werden muss. Falls es sich um eine Kommunikationsbeziehung von einem menschlichen Akteur mit dem System handelt, handelt es sich in der Regel um eine grafische Nutzerschnittstelle (GUI). Handelt es sich bei dem Akteur um ein anderes System, wird eine technische Systemschnittstelle benötigt, an der zwei Systeme miteinander kommunizieren.

Befinden sich darüber hinaus noch rechtliche, technische oder organisatorische Rahmenbedingungen im Systemkontext, müssen auch diese auf deren konkreten Einfluss auf das System analysiert werden. Neben funktionalen Anforderungen enthalten diese Rahmenbedingungen häufig auch Qualitätseigenschaften, die im Rahmen der Spezifikation zu messbaren Qualitätsmerkmalen des Systems entwickelt werden müssen.

• Datenmodell: Das Datenmodell enthält die Geschäftsobjekte, die im System von den Systemkomponenten verarbeitet werden, sowie deren Beziehung untereinander. Beispiel: Schadensmeldung, Versicherungsantrag, Kundendaten.

• Fachfunktionen: Fachliche Beschreibung der Aufgaben des Systems bzw. der spezifizierten Komponente. Beispiel: Algorithmus zur Prämienberechnung, Vorgehen bei Vertragskündigung, Abschluss eines Vertrags.

• Geschäftsregeln: Geschäftsregeln sind Regeln zu einem Geschäftsobjekt, die nicht verletzt werden dürfen. Beispiel: Datum des Vertragsbeginn muss vor dem des Vertragsendes liegen. Die Summe des Warenkorbs darf nicht negativ sein.

• Inhalte und Aufbau von einzelnen Dialogmasken:

  Detaillierte Vorgabe zu Art, Größe, Position, Farbe und Inhalt von Elementen einer Bildschirmseite, z. B. von Eingabefeldern, Texten, Schaltflächen, Bildern

• Validierung von Daten:

  Spezifikation der Regeln, um Eingabefelder auf fachliche Plausibilität zu prüfen

• Dialogfluss:

  Spezifikation der Führung des Anwenders durch die Oberfläche in Abhängigkeit von eingegebenen Daten und Aktionen des Anwenders

• Der Zweck der Schnittstelle auf einer fachlichen Ebene. Beispiel: Übertragung der Fondskurse in die Fondsverwaltung, Validierung von Adressdaten auf Gültigkeit.

• Das detaillierte Verhalten bzw. das technische Protokoll der Kommunikation sowie die Regeln, nach denen das System mit seinem Umfeld kommuniziert. Beispiel: HTTP, FTP.

• Die Datenstruktur der Nachrichten, die an der Schnittstelle ausgetauscht werden. Beispiel: XML, CSV

• 1. Metainformationen über das Dokument

• 2. Einleitung

• 3. Systemüberblick

• 4. Fachliche Systemkomponenten (falls bekannt auch technische Komponenten)

• 5. Angaben zu einzuhaltenden Vorschriften (Compliance)

• 6. Anhang

• Aktivitätsdiagramm, Zustandsdiagramm

• Sequenzdiagramm

• Klassendiagramm

• Objektdiagramm

Das UML-Objektdiagramm wird zur Darstellung eines ganz bestimmten Datensatzes auf Basis der in einem Klassendiagramm vorgegebenen Struktur erstellt. Vergleichbar mit dem Sequenzdiagramm können mit einem Objektdiagramm Sachverhalte exemplarisch dargestellt und veranschaulicht werden.

Einsatz: z. B. zur Veranschaulichung konkreter Daten aus einem Klassendiagramm zur Abstimmung mit Fachexperten ODER zur Überprüfung der Eignung des Klassendiagramms anhand von konkreten Datensätzen.

• GUI-Prototypen zur Spezifikation von Benutzerschnittstellen,

• XML-Sprachen zur Spezifikation von Datenstrukturen an technischen Systemschnittstellen,

• Entscheidungstabellen zur Spezifikation von Systemverhalten sowie Geschäftsregeln, die je nach Situation zur Spezifikation von Datenstrukturen oder Systemverhalten eingesetzt werden können.