Spezifikation -

Das erste Dokument das der Entwickler bekommt, ist das Pflichtenheft des Kunden: eine Beschreibung was der Kunde von dem zu entwickelnden System verlangt. Solch ein Dokument enthält gewöhnlich Fehler, Zweideutigkeiten und Versäumnisse. Folglich ist die erste Aufgabe die der Entwickler ausführen muß, die Umschreibung des Dokumentes in eine Systemspezifikation, welche die Ausmaße des Systems beschreibt.

4.1 Das Pflichtenheft
Der erste Schritt ist das Niederschreiben der Proportionen des Systems aus der Sicht des Kunden. Das Dokument, das zu entwerfen ist, heißt das Pflichtenheft und ist eine Beschreibung des Systems in Wörtern und nicht in irgendeiner technischen Sprache. Generell gilt: die Qualität des Pflichtenheftes hängt vom Kunden selbst ab. Ein Kunde der mit der Technologie und den Begriffen nicht vertraut ist, schreibt ein kurzes Heft in dem die Proportionen nur vage beschrieben werden, während ein anspruchsvoller Kunde, der den Umfang des System selbst festlegt, es einfacher macht, eine Systemspezifikation zu erstellen. Dieser Abschnitt beschreibt all jene Probleme, die vom schlimmst möglichen Pflichtenheft ausgehen. Die beiden Hauptkomponenten des Pflichtenheftes sind Funktionen und Einschränkungen.

Probleme beim Lesen des Pflichtenheftes:
1. Das Pflichtenheft soll in einer natürlichen Sprache geschrieben sein. Dies kann oft sehr schwierig sein.
2. Dieses Heft ist sehr oft von Mitarbeitern geschrieben, die mit den technischen Möglichkeiten nicht vertraut sind, und oft unmögliches verlangen, das aber nicht zu realisieren ist.
3. Der Kunde weiß selbst nicht was er von dem zu entwickelnden System verlangen soll und schreibt eine Dokumentation die nur vage beschreibt, was das System können soll.
4.2 Einige Definitionen aus dem Pflichtenheft
4.2.1 Sätze ohne Aussage/Inhalt (PLATITUDES)
Ein häufig auftretender Fehler des Kunden in seinem Dokument ist es, es mit Platitudes zu \"verseuchen\". Solche \"leere Sätze\", die sehr banal sind, sind jedoch oft schwer zu beschreiben. z.B.: Das System soll benutzerfreundlich sein

4.2.2 Zweideutigkeiten (AMBIGUITIES)
Zweideutigkeiten führen zu Unklarheiten, und es könnte zu einer Fehlentwicklung kommen. Eine Reorganisation erfordert viel Zeit und Geld. Anhand dieses Beispiels kann man dies vielleicht besser erklären:
4.2.3 Entwurfs- & Implementierungsanweisungen
Entwicklungs- & Implementierunganweisungen sind Beispiele für Einschränkungen im Pflichtenheft. Zu viele Einschränkungen können den Entwickler jedoch zu sehr einengen. Man sollte dem Entwickler soviel wie mögliche Lösungswege offen lassen, um so vielleicht bessere Systeme zu bekommen (schnellere Zeiten, weniger Speicherplatz).

4.2.4 Unterlassungen (OMISSIONS)
Die meisten Fehler in einem Pflichtenheft beinhalten Unterlassungen d.h. ein trivial zu scheinender Teil des Systems nimmt plötzlich Ausmaße an, mit dem man nicht gerechnet hat, und das auch nicht im Pflichtenheft genauer beschrieben ist.
Die Systemspezifikation sollte genau beschreiben was geschieht, wenn man Fehler begeht, oder welche Fehlermeldung erscheint. Dies sind die am häufigst auftretenden Fehler in solch einem Dokument.
4.2.5 Mischung der Abstraktionen
Das Beschreiben der Funktionen des Systems kann in verschiedene Abstraktionsebenen aufgeteilt werden. Einige haben eine höhere und andere eine niedrigere Abstraktionsstufe. In einem Pflichtenheft oder in einer Systemspezifikation sollen beide Stufen der Abstraktion enthalten sein. d.h. wichtigere Sachen genauer beschreiben, und unwichtigere mit einer höheren Abstraktionsstufe.
Die ideale Systemspezifikation

1. sollte vollständig sein
2. sollte eindeutig geschrieben sein
3. sollte frei von Entwurfs- & Implementierungsanweisungen sein
4. sollte keine Sätze ohne Inhalt beinhalten
5. sollte Funktionen und Einschränkungen getrennt behandeln
6. sollte sortiert sein.

Einschränkungen sind sehr wichtig, können aber beim Verstehen der Funktion oft hinderlich sein. Die ideale Systemspezifikation sollte (mit hinreichenden Querverbindungen dazwischen) Einschränkungen und Funktionen getrennt behandeln. Es ist ebenso wichtig, daß die Spezifikation hierarchisch nach Funktionen geordnet ist. Die Funktionen an der Spitze der Hierarchie sollten eine hohe Beschreibungsstufe haben.

Eine Funktion in einer hohen hierarchischen Ebene sollte wie folgt gegliedert werden:
 sie sollte genauer beschrieben werden als eine Funktion unter ihr
 es sollte festgehalten werden, welche Daten erforderlich sind

 welche Fehler auftreten können
 und welchen Effekt die Funktion haben soll

Wenn eine Funktion einen zu großen Umfang annimmt, soll man diese in eine oder mehrere Subfunktionen aufteilen. Diese wieder in Sub-Subfunktionen...
(Übersichtlichkeit).
4.3 Der Weg zur Spezifikation
1) Lese das Pflichtenheft des Kunden sorgfältig, und schreibe Dir Zweideutigkeiten, Auslassungen und Leersätze heraus.
2) Frage den Kunden was diese Leersätze zu bedeuten haben. Wenn diese jedoch Informationen enthalten (Funktion), müssen sie in die Spezifikation aufgenommen werden.
3) Kläre Auslassungen und Zweideutigkeiten mit dem Kunden und seinen Mitarbeitern.
4) Suche alle Entwurfs- & Implementierungsanweisungen und diskutiere diese mit dem Kunden aus, ob man diese nicht weglassen könnte. Zu klären ist auch, ob es immer notwendig ist, den Kunden zu informieren, wenn man solche Anweisungen weglassen will, wenn diese hinderlich bei der optimalen Systemfindung sind (GELD). Wenn der Kunde und der Entwickler der Meinung sind das gewisse Anweisungen gelöscht werden können, sollten sie das tun.
5) Suche Einschränkungen und Funktionen, und schreibe diese in verschiedenen Teilen der Spezifikation nieder.
6) Untersuche die Funktionen, die im Schritt 5 ausgesondert worden sind, und ordne diese in hierarchischer Reihenfolge.
7) Schreibe die erste Version mit allen Entwurfs- & Implementierungsanweisungen, Einschränkungen und Funktionen.
8) Gib diese Spezifikation den Kunden und bespricht diese mit ihm. Gemäß beinhaltet das Dokument mehrere Fehler. Nach der Besprechung mit dem Kunden schreibe eine neue Spezifikation und gib diese wiederum dem Kunden zur Überprüfung. Dies geschieht solange, bis der Kunde mit der Systemspezifikation vollkommen glücklich ist.

4.4 Unterschreiben
Der letzte Schritt ist das Abzeichnen der Systemspezifikation d.h. der Kunde als auch der Entwickler unterschreiben die Spezifikation des zu entwickelnden Systems, der letzten Version. Wenn dies nicht geschieht besteht die Gefahr, daß der Kunde oder der Entwickler ihre Meinung, in Hinblick auf die Systemspezifikation, ändern und es so zu Zwistigkeiten kommt. Außerdem würde eine Neuüberarbeitung des Dokumentes einen Mehraufwand bedeuten (KOSTEN). Wenn beide unterschrieben haben kann der Prozeß des Systementwurfes beginnen.
4.5 Weiterentwicklung der Systemspezifikation
Das Hauptprinzip bei der Entwicklung von Softwareprojekten ist es, Fehler zu suchen und sie zu beseitigen. Je weniger Fehler die Systemspezifikation aufzuweisen hat, desto früher ist das zu entwickelnde System fertig, und vielleicht noch wichtiger, desto billiger wird die Entwicklung. Fehler, die bis zum Schluß unentdeckt bleiben, können die Kosten für die Entwicklung ins Unendliche steigen lassen. Darum ist es unbedingt notwendig Fehler so schnell wie möglich, wenn möglich noch während der Analyse und Systemspezifikationsentwicklung, zu finden und zu beseitigen. Die Hauptaufgabe eines Systemcheckers ist es, das System zu testen. Unglücklicherweise kann man aber nicht während der Entwicklung testen, sondern erst danach, wenn der Programmcode verfügbar ist. Folglich braucht man eine andere Möglichkeit. Eine der leistungsfähigsten Methoden ist der Systemspezifikations-Rückblick:
Bei kleineren Projekten ist das ganze nur ein zwangloser Rückblick von zwei bis drei Mitarbeitern. Dabei besteht das Team aus einem Analytiker, der für die Spezifikation verantwortlich ist, und dem Projektleiter. Normalerweise wird der Rückblick nach einer Liste von Fragen abgearbeitet, die in diesem Stadium des Projektes gestellt werden sollten.
4.5.1 Checkliste
Sind die Anforderungen klar formuliert ?
Jede Anforderung sollte auf Klarheit untersucht werden. Zu untersuchen ist aber auch, ob Sätze irgendwie verschachtelt sind. Gibt es Sätze mit mehreren Objekten und Subjekten ?
Gibt es Sätze mit einer Vielzahl von Fürwörtern ? Jede Anforderung sollte unter diesen Gesichtspunkten untersucht werden.
Sind die Anforderungen umgangssprachlich geschrieben ?
Wie schon erwähnt, sollte in den Sätzen so wenig wie möglich mit Fachausdrücken gearbeitet werden, um so eine höhere Verständlichkeit zu erreichen.

Sind zweckmäßige Anforderungen vom Pflichtenheft zur Spezifikation nachvollziehbar ?
d.h. der Entwickler muß das Pflichtenheft des Kunden so durchsuchen und filtern, daß Funktionen und Anforderungen deutlicher und eindeutig herauskommen.
Sind die Anforderungen technisch durchführbar ?
Ein Hauptproblem, das im Pflichtenheft immer wieder auftaucht, ist die Undurchführbarkeit einiger Anforderungen.
z.B.: der Kunde will ein System das schnell antwortet. Will aber nicht zuviel Geld für Arbeitsspeicher ausgeben.
Dies sind zwei Dinge die sich gegenseitig ausschließen. Oft kann das Team die technische Realisierbarkeit nur anhand eines Simulationsprogrammes schätzen.

Sind die Anforderungen prüfbar ?
Dies ist die Frage, die Zweideutigkeiten, eine Menge von Unkomplettheiten und Sätze ohne Inhalt aufspürt. Am Ende des Softwareprojektes muß man eine Reihe von Abnahmetests durchführen. Jede Annahme testet einen anderen Bereich des Systems. Diese Tests entstanden aus der Spezifikation heraus. Jede Funktion und Einschränkung des Systems sollte vom Review-Team genügend getestet werden.
Welche Tests sind für jede Anforderung erforderlich ?
Es gibt eine große Vielzahl von Testmöglichkeiten für Softwareprojekte. Die Programmcodes könnten kontrolliert werden, ob die Funktionen richtig realisiert worden sind. Die Version könnte auf einem langsameren System getestet werden ...
Es ist nur wichtig, daß die Art des Testes während der Rückschau bekannt ist. Dies ist wichtig, da manche Tests im Echtzeitbetrieb laufen und eine spezielle Hard- bzw. Software benötigen.
Gibt es irgendwelche Entwurfs- und Implementierungsanweisungen ?
Entwurfs- oder Implementierungsanweisungen, die den Entwickler zu sehr einschränken, sollten in dieser Stufe spätestens entfernt werden. Einige werden natürlich bleiben: oft ist es notwendig, ein neues System mit einem bereits vorhandenen System zu kombinieren: d.h. der Faktor Dateistruktur kann vom Entwickler nicht selbst geändert werden.
4.6 Ableitung des Systems und Abnahmetest
System- und Abnahmetests ist der kritischste Teil bei einem Softwareprojekt. Ein System, das solch einen Test nicht besteht, kann die Anforderungen des Kunden nicht erfüllen. Sollte es einem Fehler gelingen auch diese Stufe zu überspringen, hat dies mit sehr großer Wahrscheinlichkeit große Auswirkungen auf die Kosten der Entwicklung.
Dies hat drei Gründe:
1. Der Fehler erfordert einen riesigen Aufwand der Respezifikation, des Redesigns und des Reprogrammierens, um diesen Fehler wieder auszubessern.
2. Wenn ein Test fehlgeschlagen ist, könnte der Kunde darauf bestehen auch andere Tests wiederholen zu lassen. Der Grund für die Testwiederholung liegt darin, ein falsches Ergebnis könnte die in der Hierarchie darunterliegenden Funktionen beeinflußt haben.
3. Danach muß noch mal geklärt werden, ob nicht andere Fehler übersehen worden sind.

Man kann sich ungefähr ausmalen wieviele Tests dies bei einem großen Projekt sein könnten (Tausende Tests).
Als Folge eines Fehlers, muß man den gesamten Testvorgang neu starten.
Für manche mag es danach aussehen, daß in diesem Stadium es äußerst früh ist um mit dem Testen zu beginnen.

Es gibt jedoch eine Menge guter Gründe dafür:
Warum so früh testen ?
1. Ein Grund wurde schon genannt. Wenn man für dieses System einige spezielle Hardwaremittel braucht, diese aber erst bestellen muß, hätte man eine Standzeit, die aber Geld kostet.
2. Ein Softwareprojekt entsteht nicht in Isolation. Falls der Entwickler eine kleinere Firma ist, gibt es eine Reihe von anderen Projekten die gleichzeitig ablaufen. Die Aufwandschätzung für solch ein Softwareprojekt kann ein sehr komplizierter Prozeß werden und ist keine beneidenswerte Arbeit des Managers. Es ist notwendig, so früh wie möglich eine möglichst genaue Aufwandschätzung durchzuführen.
3. Für viele Projekte ist der Abnahmetest zusammen mit der Systemspezifikation, die vertraglichen Dokumente. Manche Kunden ziehen es vor, einen Abnahmetest zu lesen, als eine Systemspezifikation, mit dem Vorteil, daß sie sich einen Überblick verschaffen, was das System tun wird können. Dieses Vertragsdokument sollte so früh wie möglich erstellt werden.
Die Entwicklung des Systems und Abnahmetests geschehen im gesamtem Softwareprojekt. Man gibt, entweder kurz danach oder während der Spezifikationsphase, die genauen Testergebnisse aus.

Der Entwickler hat zwei Typen von Tests vorzubereiten:

 Systemtests
 Abnahmetests

Diese Tests sind sich sehr ähnlich. Jedoch ist ihr kleiner Unterschied sehr entscheidend.
Der Systemtest wird mit den Umgebungsbedingungen des Entwicklers durchgeführt, während der Abnahmetest in dem System gemacht wird, indem es laufen soll. Beim Abnahmetest wird automatisch der Kunde mit einbezogen, der als Zeuge fungieren soll, und außerdem muß er die abgeschlossenen Testdokumente signieren. Der Entwickler wählt Sets von Systemtests aus und daraus entwickelt er Subsets für die Abnahmetests. Der Kunde ist jedoch nur an Tests interessiert, die das externe Verhalten des Systems ausgeben.
4.7 Ergänzung
Pflichtenheft (customer statement of requirements): Wird vom Kunden alleine erstellt.
Spezifikation wird vom Kunden und vom Systemanalytiker gemeinsam in Benutzersprache verfaßt.

In der Spezifikation enthalten:
 Funktionen des Systems - DfD, Dekomposition
 Randbedingungen - Zeit- (für Suche 0,4 sec) und Speicherverbrauch (Programm < 2 MB)
 Benutzeroberfläche (Liste aller Masken)
 Schnittstelle zu anderen Systemen

In der Spezifikation nicht enthalten:
 Banalitäten = Platitüden = bla bla bla
 Mehrdeutigkeiten wie "meistens ...", "verarbeiten ..." und "normalerweise ..." ...
 Implementierungs-, und Entwurfsanweisungen (z.B.: in C++ geschrieben)


Allgemeine Eigenschaften:
 die Spezifikation muß eindeutig sein
 immer Status anzeigen

 viele Bilder
 Masken

 Übergangsgraphiken
 Prüfungen für Inkonsistenzen