Anforderungen an ein Softwaresystem werden üblicherweise in der Analysephase eines Projektes erarbeitet und im Pflichtenheft als Ergebnis dieser Phase dokumentiert. Durch eine Klassifizierung von Requirements wird ein alternativer Ansatz zur herkömmlichen Life Cycle-orientierten Vorgehensweise aufgezeigt. Im Mittelpunkt steht die Trennung der essentiellen Teile eines Systems von einer speziellen, momentan ausgewählten Realisierung.
In vielen Lehrbüchern und in fast 100 Prozent aller Firmenpraktiken betrachtet man die Festlegung von Anforderungen an ein zu automatisierendes System als Teil der Systemanalyse. Zahlreiche Erhebungsverfahren, Interviewmethoden und Regeln für Beobachtungen von Arbeitsabläufen wurden beschrieben. Meistens werden die Erhebung der Anforderungen und die saubere Niederschrift zeitlich strikt nacheinander abgehandelt. Dies führt grafisch dargestellt zu dem klassischen Projektbeginn (Abbildung 1).
Bei der Erhebung versucht man, möglichst alle Anforderungen aus dem Munde des Auftraggebers zu erfahren. Viele Verfahren trennen dabei nicht zwischen Wesentlichem und Detail, zwischen absolutem "Muß" und "Kann" - die Anforderungen werden sequentiell, wie man sie erfährt, angenommen.
Auch bei der Niederschrift treten dieselben Aspekte in den Vordergrund: Meistens hat man ein Gliederungsschema, so daß auf den ersten Blick ein Pflichtenheft gut strukturiert aussieht. Versucht man jedoch, die Kriterien zu analysieren, die die Gliederung dieses Dokuments bestimmt haben, so stellt man oft fest, daß diese für das spezielle Projekt erfunden wurden oder einer langgepflegten Tradition folgen (weil jeder von seinem Vorgänger abschreibt), aber trotzdem einige wesentliche Nachteile bestehen bleiben.
Auch in diesen Dokumenten wird selten zwischen Wesentlichem und Details unterschieden; die Darstellung ist eher "linear", das heißt, in einem durchgehend lesbar. Versuchen Sie einmal in einem herkömmlichen Pflichtenheft eine Detailfrage zu finden oder zu klären?
Aufgrund der üblichen Notation eines Pflichtenheftes - der deutschen Umgangssprache - wird selten eine Abstufung der Dringlichkeit von Anforderungen vorgenommen. Wörter wie "muß", "sollte" oder "kann" werden mehr nach Gutdünken, als konsequent verwendet.
Außerdem werden sehr oft wirkliche Anforderungen an das System und notwendige Entwurfseinschränkungen mit willkürlichen, unnötigen Entwurfsentscheidungen vermischt. Letztere sind nicht nur überflüssig, sie behindern oftmals das Verständnis des wahren Problems und verhindern andere, effizientere oder elegantere Lösungsansätze.
Ein wesentlich größeres Problem ergibt sich jedoch aus der Form der Darstellung: Sie läßt keinerlei Prüfungen auf die Konsistenz, Vollständigkeit und Widerspruchsfreiheit der aufgestellten Forderungen zu.
Durch die Einführung des Software Life Cycle wurde das vorhandene Bewußtsein der Phasentrennung noch verstärkt. Die erste Phase behandelt die Analyse und Definition der Anforderungen. Methoden entwickeln, die eine systematischere Darstellung der Requirements erlauben. Der Strukturbegriff steht dabei im Vordergrund. Alle Methoden strukturieren das Pflichtenheft so, daß man wesentliche und unwesentliche Teile auseinanderhalten kann. Außerdem gestatten die Methoden einen gewissen Grad an Prüfbarkeit bezüglich Konsistenz und Vollständigkeit.
Zwei Denkansätze werden dabei unterschieden: Eine Gruppe von Methoden stellt die Modellbindung in den Vordergrund, das heißt, die Abbildung der Anforderungen in der wirklichen Welt in eine meist grafisch orientierte Modellwelt, die danach den Ausgangspunkt für Entwurf und Realisierung bildet. Die zweite Gruppe stellt eher die Ansammlung der Anforderungen in einer Datenbank in den Vordergrund und ermöglicht zu beliebigen Zeitpunkten die Aufbereitung und Prüfung des bisher angesammelten Wissens über die Anforderungen.
Zu der Gruppe der Modellbildungsmethoden gehören zum Beispiel Structured Analysis und SADT/DeM79, Ros77/. Man geht davon aus, hauptsächlich die funktionalen Anforderungen zu erfassen und in Form von top-down organisierten Diagrammen niederzuschreiben.
Die Top-down-Organisation gestattet es, Requirements auf verschiedenen Stufen der Abstraktion mit dem Benutzer zu diskutieren. Die oberste Ebene soll dabei einen allgemeinen Überblick über die wesentlichsten Aspekte des Systems vermitteln; wer mehr Details wissen muß, betrachtet die entsprechenden Verfeinerungen der Diagramme.
Ein wesentlicherer Aspekt als die Darstellungsweise ist jedoch die zugehörige Denkweise. Die Konzentration auf das Denken in Datenflüssen bei Structured Analysis führt zu wesentlich besseren Zerlegungen von Systemen, da dabei nicht so sehr das funktionale Denken im Vordergrund steht, sondern die Zusammenfassung zwischen den Funktionen. Die Betonung liegt auf den Schnittstellen zwischen den Funktionen statt auf deren Inhalt. Die Fehler mit den drastischen Auswirkungen - die Schnittstellenfehler - werden so schon bei der Aufsammlung der Requirements vermieden.
Durch die Zerlegung eines Systems in kleinere Teile wird jedoch nur der Rahmen für die Spezifikation der Anforderungen abgesteckt, es werden "Minisysteme" gegeneinander abgegrenzt. Die eigentliche Spezifikation dieser Minisysteme erfolgt in den Komponenten des Modells, im Data Dictionary und in den "Minispecs" zu jedem Teilsystem.
Das Data Dictionary klärt alle Fragen zu den verwendeten Begriffen und deren Struktur. Die Minispecs beschreiben mit wenigen Sätzen, was die Minisysteme leisten müssen. Werkzeuge, die diese Modellbildungsmethoden unterstützen, müssen durch interaktive Prozessoren die Erstellung und Prüfung der Diagramme, Data Dictionarys und Minispecs zulassen.
Die zweite Kategorie von Methoden, zu denen als Vertreter PSL/PSA, Tei77, SREM/SREP und Alf 77 gehören, basiert auf der Idee, alle Informationen, aus der Anforderungsanalyse in Form von Objekten und Relationen in einer Datenbank abzulegen. Dafür stellen die Methoden eine Reihe von Objekten und Relationen zur Verfügung. Objekte sind zum Beispiel "Eingabedaten", "Ausgabedaten", "Teilsysteme" und "Datenelemente"; Relationen sind "empfängt", "sendet" oder "ist Teilsystem von".
Die Methode besteht nun darin, Aussagen des Kunden auf Objekte und Relationen abzubilden und - zunächst ungeordnet - in eine Datenbank einzutragen. Durch systematische Aufstellung von Reports kann man den Inhalt der Datenbank wiedergeben und dadurch Lücken in den bisher erfragten Anforderungen feststellen. Diese Lücken können dann durch gezieltes Nachfragen geschlossen werden.
Im Gegensatz zum sequentiellen "Erst Requirements erfragen, dann dokumentieren" ergibt sich bei beiden Modellen jetzt ein iterativer Ansatz, bei dem jederzeit der Stand der Anforderungen auch gleich dokumentiert ist. Im ersten Fall - bei den modellorientierten Ansätzen - wächst das Modell auch top-down, wie die endgültige Darstellung. Im zweiten Fall - bei den datenbankorientierten Ansätzen - wächst die Anforderungsdefinition mehr nach den Wünschen des Benutzers, da dessen Aussagen zunächst gesammelt und kategorisiert werden. Erst im Iterationsschritt - durch gezieltes "Nachbohren" - werden diese Informationen vervollständigt (Abbildung 2).
Bei Projekten, deren Zielsetzung halbwegs durchschaubar ist, haben sich modellorientierte Ansätze gut bewährt - unabhängig von der Größenordnung und dem Anwendungsbereich des Systems. Voraussetzung ist aber, daß zumindest am Anfang der Projektlaufzeit ungefähr klar ist, was das System leisten soll. Bei den meisten industriellen Projekten, deren Gesamtlaufzeit einige Monate oder wenige Jahre beträgt, ist diese Voraussetzung gegeben.
Liegen sehr viele und widersprüchliche Ziele vor oder ist die Zahl der Requirements so groß, daß eine Modellbildung von Anfang an nicht möglich ist, so sind datenbankorientierte Ansätze vorzuziehen, die wenigstens gewährleisten, daß die vorhandene Information so gut wie möglich verwaltet, gebündelt und ausgewertet wird. Dies gilt vor allem für Projekte, bei denen sich die Analysephase allein über einen Zeitraum von mehreren Jahren erstreckt, wie dies im Bereich militärischer Großsysteme durchaus üblich ist.
Die Nachteile aller bisher geschriebenen Methoden bezüglich der Behandlung von Requirements liegen darin, daß sie alle von dem Modell des Software Life Cycle ausgehen, der fordert, daß alle Requirements definiert sind, bevor man den Entwurf dieses Systems beginnt. In den meisten Fällen wird zwar zugestanden, daß sich durch Argumente, die man erst im Entwurf findet, einiges an den Anforderungen ändern kann. Aber fast immer geht man davon aus, daß spätestens nach dem Entwurf der Systemarchitektur die Anforderungen eingefroren werden können und keine weiteren Änderungen mehr auftreten.
Die Voraussetzung ist in den wenigsten realen Projekten wirklich durchzuhalten. Meistens häufen sich neue Wünsche des Kunden genau dann, wenn er zum ersten Mal das System in Betrieb sieht. Im Life Cycle bedeutet dies eine Rückkopplung von der Realisierungsphase bis in die Systemanalyse, was meist mit viel Ärger, großen Kosten und viel Zeit verbunden ist.
Die Alternative dazu wird als Rapid Prototyping bezeichnet. Man geht davon aus, möglichst rasch einen Prototyp eines Systems dem Benutzer zur Verfügung zu stellen, um frühzeitig Änderungswünsche oder zusätzliche Anforderungen zu erfahren (Abbildung 3).
Mit dieser Vorgehensweise handelt man sich einen Nachteil ein, der durch die oben beschriebenen Methoden schon behoben war: Es ist wieder kaum zwischen wesentlichen Aspekten und Detailforderungen zu unterscheiden. Sehr oft werden an solchen Prototypen die Gestaltung von Bildschirmmasken, die Reihenfolge der Eingaben und ähnliches kritisiert, daneben aber zusätzliche Leistungen gefordert. Die Trennung zwischen wesentlichen Funktionen und Realisierungsdetails, die bei Methoden mit Modellbildung bereits vorhanden war, geht dabei wieder verloren.
Im folgenden wird versucht, Life Cycle und Rapid Prototyping zu vermischen und dadurch zu einer Projektgliederung zu kommen, die die Requirements in völlig neuem Licht erscheinen läßt. Der Ausgangspunkt ist eine Auftrennung eines Systems nach zwei Aspekten: der Essenz eines Systems und der Inkarnation eines Systems.
Unter der Essenz eines Systems versteht man die Teile, die unabhängig von der Technologie der Realisierung unmittelbar zur Lösung der gestellten Aufgabe beitragen. Wenn man sich einen idealen Prozessor vorstellt, der keine Zeit zur Ausführung von Funktionen benötigt, immer genug Speicherplatz hat und nie Fehler macht, so bleiben von einem System immer noch Teile übrig, die dann noch realisiert werden müßten. Diese Teile bilden die Essenz eines Systems.
Zur Inkarnation eines Systems gehören die Teile, die unter bestimmten nicht idealen technologischen Randbedingungen gemacht werden müssen, um die Funktionsfähigkeit des Systems zu gewährleisten. Funktionen zum Prüfen der Korrektheit von Eingabedaten, zum Weiterleiten von einem Rechner an einen anderen, Programmteile, die die Reihenfolge bestimmen, in denen Dialoge mit dem Benutzer abgewickelt werden, gehören zu einer Inkarnation eines Systems.
Betrachtet man etwa ein Lohnabrechnungsprogramm, so gehört die Funktion, die aus dem Grundlohn, der Arbeitszeit, den steuerlichen Richtlinien unter anderem den Lohn eines Arbeiters berechnet, zu essentiellen Funktionen des Systems. Funktionen, die festlegen, in welcher Weise die Arbeitsstunden eingegeben werden, in welcher Reihenfolge die Löhne berechnet werden und wie der Bildschirm zum Ansehen von Zwischenergebnissen beschickt wird, sind Teile einer speziellen Inkarnation dieses Systems.
*Dr. Peter Hruschka ist Leiter des Bereichs Software-Engineering bei der GEI - Gesellschaft für elektronische Informationsverarbeitung mbH, Aachen.