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 (Teil 2).

Die Grundidee für die Auftrennung in Essenz und Inkarnation ist folgende: Betrachtet man die Lebenszeit eines Softwareprodukts, so ist die Änderungsrate für essentielle Teile eines Systems um ein Vielfaches geringer als die Änderungsrate der inkarnationsspezifischen Teile.

Neue Randbedingungen für verwendete Geräte oder für die Organisation, in die das System eingebettet ist, sind viel wahrscheinlicher. Deshalb sollte man bei der Gestaltung von Systemen die Essenz deutlich hervorheben und von den momentanen physikalischen Realisierungsaspekten trennen (Abbildung 4).

Nur die essentiellen Anforderungen bestimmen die Qualität und die Lebensdauer des Systems. In den Augen des Kunden kann die Forderung, daß Terminals eines bestimmten Typs für das Buchhaltungsprogramm verwendet werden, genauso wichtig sein wie die Forderung nach Einhaltung der steuerlichen Richtlinien. Der Systemanalytiker muß jedoch unterscheiden können, daß der Terminaltyp und die momentane Steuertabelle zur Inkarnation des Systems gehören; die Tatsache aber, daß überhaupt Steuern berechnet werden, indes zur Essenz des Systems. Diese Auftrennung ist nicht immer einfach, da die beiden Gruppen von Anforderungen oft ineinander vermischt auftreten.

Betrachtet man das Beispiel der Abbildung 5a, so ist zu erkennen daß hier inkarnationsspezifisch modelliert wurde. Selbst bei einer Umbenennung der Funktionen, wie zum Beispiel in "Ticket erstellen" und "Ticket ausgeben", bleibt das Modell inkarnationsspezifisch. Die korrekte Modellierung der Essenz dieser Aufgabe ist in Abbildung 5b dargestellt.

Unter Berücksichtigung dieser Aspekte wurden in den letzten Jahren Methoden entwickelt und in der Praxis erprobt (M-P81). Eine neu entstandene Technik - Advanced Structured Analysis - legt offen, wie die essentiellen Anforderungen an ein System schrittweise erarbeitet werden und es so zu einem langlebigen Modell und dadurch bedingt zu einem anpassungsfreundlichen System kommt.

Die in Abbildung 4 dargestellte Vorgehensweise hat den Nachteil daß es sehr schwierig ist, die Essenz eines Systems direkt zu modellieren. Was der Benutzer nämlich sieht und kennt, ist seine momentane Inkarnation, der Ist-Zustand. Deshalb wird der Knoten 1 der Abbildung 4 zu einem Bild verfeinert, wie es in Abbildung 6 dargestellt ist.

Das Modellieren der momentanen Inkarnation kann nach den bereits vertrauten Methoden und mit Hilfe der erprobten Werkzeuge erfolgen. Man zeichnet Datenflußdiagramme, legt ein Data Dictionary an und schreibt die Minispecs zu jedem Knoten der Diagramme. Das was ursprünglich das fertige Pflichtenheft darstellte, wird jetzt jedoch so weiterbearbeitet, daß man daraus die essentiellen Teile extrahiert.

Der Schritt vom momentanen physikalischen Modell zum momentanen logischen Modell ist der schwierigste und aufwendigste. Hat man erst einmal die Essenz des bestehenden Systems abgeleitet, so können die neuen Anforderungen leicht in dieses Modell integriert werden, um ein neues logisches Modell zu erhalten. Dieses Modell ist der Ausgangspunkt für die Ableitung einer möglichen neuen physikalischen Inkarnation, wie sie in Abbildung 4 dargestellt wurde.

Um die Essenz aus einem physikalischen Modell herauszukristallisieren, gibt es eine Vielzahl von Untersuchungen, die man Schritt für Schritt durchführen kann. Ziel dieser Untersuchungen ist es zunächst, alle physikalischen Anteile am Modell zu erkennen und aus dem Modell zu streichen.

Essentielle Aktivität

Dazu betrachtet man als erstes die Prozesse in den Diagrammen, die überhaupt keinen Anteil der Essenz enthalten. Typische Beispiele sind Prozesse die nur zur Kommunikation zweier oder mehrerer essentieller Teile dienen: Prozesse zum Aufbereiten und Dekodieren von "Botschaften" oder Prozesse zum reinen Transport.

Aber auch innerhalb von Funktionsgruppen, die essentielle Teile beinhalten, gibt es rein physikalische Prozesse, die nur der Administration rund um eine essentielle Aktivität dienen. Dazu zählen Datenaufbereitungen, Datenprüfungen oder Überwachungsprozesse.

Diese beiden Gruppen - Transportprozesse und Administrationsprozesse - können zunächst aus den Diagrammen entfernt werden. Was übrigbleibt, ist meistens nicht mehr zusammenhängend. Bevor man jedoch darangeht, die Zusammenhänge wieder herzustellen, erfolgt ein weiterer Minimierungsvorgang Auch in den verbleibenden Teilen sind noch physikalische Aspekte versteckt, gemischt mit essentiellen Anteilen des Systems.

Am ehesten findet man diese Teile noch in Datenflüssen und Dateistrukturen, wo außer den für die Lösung der Aufgabe notwendigen Teilen auch noch Verzweigungen zu anderen Datenstrukturen, unnötige Bündelungen oder Statuskennungen enthalten sind. Um diese zu entfernen, ist es meistens notwendig, zunächst Aufspaltungen vorzunehmen und dann die nicht gebrauchten Teile zu streichen.

Sind die physikalischen Aspekte so weit als möglich entfernt, beginnt der konstruktive Zusammenbau der verbleibenden essentiellen Teile des Systems. Auch hierfür gibt Advanced Structured Analysis Anleitungen, wie die übriggebliebenen Fragmente gegliedert werden sollen.

Im wesentlichen folgt man den Stimuli, die im System Antworten auslösen sollen und verbindet alle Fragmente, die zu einem Stimulus gehören.

Durch Zusammenfassen dieser "ereignisorientierten" Funktionsgruppen erhält man neue Abstraktionslevel, die wieder zu der gewohnten Top-down-Gliederung des Systemmodells führen, diesmal jedoch zu einem Modell, in dem nur mehr die essentiellen Funktionen enthalten sind.

Zerlegen und Zusammenfügen der Diagramme gelingt selbst in komplexen Systemen verhältnismäßig rasch, vorausgesetzt, man benutzt effiziente und rechnerunterstützte Werkzeuge. Nach ersten Erfahrungen zahlt sich diese Vorgehensweise in jedem Fall aus, denn das so gewonnene Modell ist die langlebige Basis für alle neue Requirements, die eingebracht werden sollen und auch für alle organisatorischen Einbettungen und Realisierungseinschränkungen.

Letztere sind notwendig, um die nicht vorhandene, ideale Technologie, von der man ausgegangen ist, auf eine vorhandene, nicht ideale Technologie abzubilden.

Wird von der realistischen Annahme ausgegangen, daß Requirements nur in den seltensten Fällen wirklich am Anfang eines Projektes bekannt sind und daher nicht festgeschrieben werden können, so kommt man fast von selbst dazu, den Begriff des Software-Life-Cycle, die darin verankerten Methoden und die damit verbundenen Managementpraktiken anzuzweifeln.

Advanced Structured Analysis zeigt einen vielversprechenden Weg, wie durch Konzentration auf die essentiellen Teile eines Systems die Wahrscheinlichkeit erhöht werden kann, daß

- der Kunde von vornherein klarer die Leistungsfähigkeit des bestehenden oder neu zu gestaltenden Systems erkennt und seine wahren Anforderungen äußert, und

- die Änderungen an den Requirements, die dem Kunden trotzdem erst spät im Ablauf der Projektarbeit einfallen, keinen dramatischen Einfluß auf die Gesamtstruktur haben und daher leicht eingebracht werden können.

Literatur:

(Alf77)

M. Alford

A Requirements Engineering Methodology for Real-Time Processing Requirements, IEEE, Trans. on SE, Jan. 1977

(DeM79)

T. DeMarco

Structured Analysis and System Specification Yourdon Press, 1979

(Hru82)

P. Hruschka

Methodische Systemerstellung mit proMod GEI-Kursunterlagen, 1982

(MM-P81)

S. M. McMenamin, J. F. Paler Advanced Structured Analysis Edition 4. 1, Yourdon, inc. 1981

(Pos77)

D. T. Ross, K. E. Schoman, Jr. Structured Analysis for Requirement Definition IEEE, Trans. on SE, Jan. 1977

(Tei77)

D. Teichroew, E. A. Hershey III

OSL/PSA: A Computer - Aided Technique For Structured Documentation and Analysis of Information Processing Systems IEEE, Trans. on SE, Jan. 1977

Dr. Peter Hruschka ist Leiter des Bereichs Software - Engineering bei der GEI- Gesellschaft für elektronische Informationsverarbeitung mbH, Aachen.