Softwaretechnik

4 Bausteine der Spezifikation (S. 49-50)
von Wolfgang Krug und Johannes Siedersleben

? Aus welchen Bausteinen besteht eine Spezifikation und wie schreibt man sie auf?

4.1 Ubersicht und Einordnung

Die Spezifikation ist der Bauplan fuer das System und sie sagt dem Benutzer, was ihn erwartet. Wie schreibt man so etwas auf? Diese Frage ist so alt wie die Softwaretechnik selbst, und sie ist immer noch nicht beantwortet. Wir begegnen zwei Trends, die wir fuer gefaehrlich halten: Erstens die Beschraenkung der Spezifikation auf Bilder wie z.B. Klassendiagramme und zweitens der Verzicht auf die Spezifikation insgesamt.

Bilder sind hilfreich und ein Bild sagt bekanntlich mehr als tausend Worte. Aber tausend Bilder sagen weniger als hundert Seiten sorgfaeltig geschriebene und sinnvoll illustrierte Dokumentation. Die Beschraenkung auf Bilder ist gefaehrlich: Am Anfang erscheint alles einfach und uebersichtlich, aber am Ende droht das Chaos. Wir brauchen Bilder, das ist selbstverstaendlich, aber wir vermeiden bewusst den Irrweg, den viele Werkzeuge nahe legen: naive Reduzierung auf die Graphik und weitgehender Verzicht auf Text. Software wird geschrieben, nicht gezeichnet (vgl. [Den93]).

Der vollstaendige Verzicht auf die Spezifikation, wie er im XP1)-Umfeld gelegentlich propagiert wird, ist mit Sicherheit ein Irrweg und diskreditiert andere wertvolle XP-Elemente (wie etwa die Idee des permanenten Tests). Nun gibt es neben der grafiklastigen Spezifikation und dem voelligen Verzicht eine weitere Gefahr, naemlich die der Überspezifikation. Viele Projekte haben sich buchstaeblich zu Tode spezifiziert, Berge von Dokumenten erstellt, die keiner liest, die fuer den Anwender und den Programmierer unverstaendlich und schon zum Erstellungszeitpunkt veraltet sind. Dieses Kapitel beschreibt einen Mittelweg. Wir sind der Ansicht, dass man wichtige Dinge aufschreiben muss, denn nur was aufgeschrieben ist, kann man auch verbindlich kommunizieren, und erst beim Niederschreiben werden Unstimmigkeiten und Luecken offenbar ± das wei[02da] jeder, der eine Diplomarbeit verfasst hat. Unabhaengig von jeder Methode gelten zwei Regeln: Erstens erstellen wir nur solche Papiere, die auch ihren Leser finden, denn alles andere ist vertane Zeit. Und zweitens sind nur kurze Papiere gute Papiere. Die akzeptable Laenge haengt natuerlich von der Zielgruppe ab: Der Manager liest am liebsten nur eine Seite, maximal drei, doch die Spezifikation der Anwendungsfaelle eines Systems darf auch 100 Seiten dick sein ± aber bitte keine tausend!

Dieses Kapitel beschreibt die Bausteine der Spezifikation. Das sind nicht weniger als insgesamt 17 Stueck. Sie sind entstanden im Rahmen einer Analyse von mehreren in unserem Haus durchgefuehrten Projekten und dienen als Fahrplan fuer die Erstellung von Spezifikationen. Zwar haengen die Bausteine zum Teil voneinander ab, aber gerade der Bausteincharakter macht es moeglich, die verschiedenen Themen zu entzerren und zeitlich gestaffelt zu bearbeiten. Insofern ist der Bausteingedanke kompatibel zu verschiedenen Vorgehensmodellen.

Jeder Baustein ist eine Anleitung fuer einen bestimmten Teil der Spezifikation; die Liste der Bausteine selbst dient als Checkliste. Das Ganze ist zu verstehen als Baukasten: Jedes Projekt entscheidet, welche Bausteine in welcher Tiefe ausgefuehrt werden. Alle Bausteine sind in ausfuehrlicher Form im Intranet von sd&m verfuegbar. Gro[02da]e Projekte sind erst machbar, wenn sie in ueberschaubare Teilprojekte aufgeteilt sind. Es gibt keine belastbaren Angaben zur Überschaubarkeit, aber als ganz grobe Richtlinie nennen wir die Zahl von sieben Bearbeiterjahren (Sieben spielt auch hier eine besondere Rolle). Projekte, die wesentlich groe[02da]er sind, sollte man aufteilen.