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.
Teilweise wird in der Software Engineering Fachliteratur die technische Spezifikation als Ergebnis des Requirements Engineerings beschrieben und nicht zwischen Requirements Engineering und Spezifikation unterschieden. Hier bezeichnen wir mit "Requirements Engineering" die Aktivitäten, Methoden und Techniken zur Ermittlung, Dokumentation, Prüfung und Abstimmung von fachlichen Anforderungen.
Mit Spezifikation bezeichnen wir die Aktivitäten zur Dokumentation von detaillierten technischen Anforderungen. 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.
Diese Unterscheidung ist nach unserer Erfahrung relevant, da insbesondere beim RE von fachlichen Anforderungen der Fokus auf der situationsabhängigen Auswahl und dem Einsatz von Ermittlungs-, Dokumentations- und Prüftechniken liegt. Vor dem Hintergrund bereits stabiler fachlicher Anforderungen (auch: fachliche Spezifikation) und im Hinblick auf die nun anstehende möglichst präzise technische Spezifikation verschiebt sich der Fokus auf die Fragestellung, mit welchen Mitteln welche fachlich-technischen Anforderungen am besten spezifiziert werden können. Anforderungen aus dem Requirements Engineering (RE) werden dabei auf einer technischen Ebene konkretisiert und so verfeinert, dass sie messbar sind.
Die folgende Abbildung veranschaulicht den Einsatz von Spezifikationsdokumenten im Verlauf der Softwareentwicklung. Ermittelte fachliche
Anforderungen werden bei der Spezifikation um technische Anforderungen erweitert und verfeinert. Das Resultat ist eine fachlich-technische
Spezifikation, auf deren Basis zunächst das Systemdesign und anschließend die Implementierung des Systems erstellt werden. Außerdem
werden auf Grundlage der Spezifikation Testfälle für die verschiedenen Teststufen erstellt, in denen das Softwaresystem auf
Erfüllung der Anforderungen hin getestet wird.
Weil die Spezifikation sowohl die Grundlage für die Umsetzung des Systems (Design und Implementierung) als auch die Grundlage für die Formulierung verschiedener Testfälle ist, haben Fehler der Spezifikation oder Missverständnisse beim Lesen der Spezifikation weitreichende Auswirkungen auf das gesamte Projekt. Um die Anforderungen möglichst eindeutig und messbar zu spezifizieren, gibt es im Software Engineering eine breite Palette an Darstellungsmittel (z. B. Softwaremodelle oder Spezifikationssprachen) und Werkzeuge (z. B. Modellierungswerkzeuge), um die spezifischen Elemente eines Softwaresystems zu spezifizieren. 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. Aus Sicht der Spezifikation ist das System eine Black-Box, über deren inneren Aufbau nichts bekannt ist.
Eine Spezifikation trifft Aussagen darüber, was ein System können muss. Sie beschreibt damit das nach außen sichtbare fachliche Verhalten eines Systems. Elemente zur Spezifikation des fachlichen Verhaltens eines Systems sind:
Zusätzlich zu dem nach außen sichtbaren fachlichen Verhalten des Systems müssen die technischen Systemschnittstellen spezifiziert werden. Als Schnittstellen werden die Teile eines Systems bezeichnet, die der Kommunikation mit den Anwendern oder anderen Systemen (auch: Systemumfeld) dienen. Folgende Eigenschaften werden zu Schnittstellen spezifiziert:
Darüber hinaus werden Anforderungen hinsichtlich Qualitätseigenschaften und Randbedingungen in der Spezifikation auf einer technischen Ebene verfeinert.
Spezifikationen von Benutzeroberflächen legen konkrete Vorgaben für folgende Aspekte fest:
Die grafischen Benutzeroberflächen (GUIs) werden sowohl visuell als auch textuell spezifiziert. Die visuelle Spezifikation legt dabei das Aussehen der verwendeten Elemente, deren Anordnung auf einer Maske und die Beziehungen zu Fachobjekten und Fachfunktionen fest. Hilfsmittel zur Spezifikation sind dabei Skizzen oder Screenshots von GUI-Prototypen und einfache Diagramme, welche die Reihenfolge von Dialogmasken darstellen. Die textuelle Spezifikation detailliert Zusammenhänge, die sich nicht unmittelbar visuell ausdrücken lassen oder deren Visualisierung die Übersicht erschweren würde. Dazu zählen unter anderem die Regeln zur Aktivierung und Deaktivierung von GUI-Elementen, Validierungsregeln und Dialogflussbedingungen.
Die Spezifikation vom Aufbau und den Abläufen innerhalb eines Systems und an den technischen Schnittstellen lässt sich in folgende Einzelschritte unterteilen:
Komponenten
In einer Spezifikation wird in der Regel nicht nur das zu erstellende Softwaresystem als Ganzes beschrieben. Je nach
konkreter Projektsituation ist nur ein ganz bestimmter Teil des Systems relevant. Daher werden komplexe Softwaresysteme in sogenannte
Komponenten aufgeteilt, wobei jede Komponente eine unabhängige Softwareeinheit ist, die aufgrund vereinbarter Schnittstellen
mit anderen Komponenten zu einem Softwaresystem zusammengestellt werden kann.
Im Rahmen der Spezifikation werden daher ...
Fachliche Datenmodelle
Mit fachlichen Datenmodellen werden fachliche Entitäten (Geschäftsobjekte) und deren
Zusammenhänge spezifiziert und damit einheitlich für alle Beteiligten festgelegt. Mit Hilfe von Softwaremodellen (z. B. UML
Klassendiagramm) werden Aufbau, Zusammensetzung und Beziehungen zwischen verschiedenen fachlichen Entitäten spezifiziert. Auf Basis
von fachlichen Datenmodellen kann gewährleistet werden, dass insbesondere in komplexen Systemen, in denen die gleichen Daten in
verschiedenen Komponenten verarbeitet werden, die Austauschfähigkeit erhalten bleibt. So müssen zum Beispiel die Daten, die
über eine GUI eingegeben werden, genauso dem Datenmodell entsprechen, wie die Daten, die in der Datenbank gespeichert werden.
Geschäftsregeln
Eine Geschäftsregel ist eine Aussage, die einen fachlichen Aspekt definiert oder bedingt.
Mit Geschäftsregeln können Zusicherungen über die Struktur von Geschäftsobjekten beschrieben und das Verhalten von
Geschäftsprozessen beeinflusst werden. Dabei können neben strukturellen Vorgaben (Beispiel: "Ein Vertrag muss immer einem
Versicherungsnehmer zugeordnet sein.") durch Geschäftsregeln auch operative Vorgaben spezifiziert werden (Beispiel: "Ein Schaden
über 500.000 EUR muss immer durch zwei Sachbearbeiter begutachtet werden." oder "Verträge mit einem öffentlichen
Auftraggeber werden nur in der Hauptverwaltung abgeschlossen."). In der Praxis werden Geschäftsregeln in der Regel in Form von Text
spezifiziert.
Neben der Spezifikation von funktionalen Anforderungen an Softwaresysteme müssen bei der Spezifikation ebenso Qualitätseigenschaften an das System beschrieben werden. Der Begriff Softwarequalität kann nach dem ISO 9126-Standard folgendermaßen definiert werden: "Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung zur Erfüllung gegebener Erfordernisse bezieht." Um auf die Qualitätsmerkmale gezielt einzugehen, wird in fachlichen Anforderungsdokumenten häufig verlangt, dass das System eine "gute Usability" gewährleisten muss, dass die "Datensicherheit" immer garantiert werden soll, oder dass das System "immer" erreichbar sein soll.
Im Rahmen der detaillierten Spezifikation von Qualitätseigenschaften müssen aus den oben genannten allgemeinen Anforderungen messbare Qualitätskriterien abgeleitet werden. Denn die konkret formulierten Qualitätseigenschaften haben einen maßgeblichen Einfluss auf die Architektur des zu entwickelnden Systems: Ob mit dem System nur fünf oder 500.000 Nutzer gleichzeitig arbeiten sollen, oder ob das System werktags von 09-16 Uhr oder an allen Kalendertagen 24h verfügbar sein muss - solche Qualitätseigenschaften beeinflussen die technische Umsetzung in der Regel stärker als die Erweiterung des Funktionsumfangs um eine weitere Fachfunktion.
Darüber hinaus muss auch besonders auf die Testbarkeit von Qualitätskriterien geachtet werden. Wie weiter oben erwähnt, werden auf Basis der Spezifikation konkrete Testfälle erstellt. Daher müssen die Qualitätseigenschaften so spezifiziert werden, dass ihre Erfüllung im Rahmen von Tests nachgewiesen werden kann.