Requirements Engineering ’91: „Structured Analysis“ und verwandte Ansätze Marburg, 10./11. April 1991

217 Pages·1991·9.716 MB·German

by  Peter Hruschka (auth.), Michael Timm (eds.)

Informatik - Fachberichte
Band 176: H.Trost (Hrsg.), 4. 6sterrelchische Artlflclal-Intelligence Band 201: A. M. Kotz, Triggermechanismen in Datenbanksystemen.
Tagung. Wien, August 1988. Proceedings. VIII, 207 Seiten. 1988. VIII, 187 Selten. 1989.
Band 202: Th. Christailer (Hrsg.), KOnstliche Inteiligenz. 5. FrOh
Band 177: L. Voelkel, J. Pliquett, Signaturanalyse. 223 Seiten. 1989.
jahrsschule, KI FS-87, GOnne, M!!rzIA pril 1987. Proceedings. VII,403
Band 178: H. GOttler, Graphgrammatlken in der Softwaretechnik. VIII, Selten, 1989.
244 Seiten. 1988. Band 203: K. v. Luck (Hrsg.), KOnstliche Intelllgenz. 7. FrOhjahrs
schule, KI FS-89, GOnne, M!lrz 1989. Proceedings. VII, 302 Seiten.
Band 179: W. Amellng (Hrsg.), Simulationstechnik. 5. Symposium. 1989. .
Aachen, September 1988. Proceedings. XIV, 538 Seiten. 1988. Band 204: T. H!!rder (Hrsg.), Datenbanksysteme in BOro, Technik
Band 180: H. Bunke, O. Kabler, P. Stucki (Hrsg.), Mustererkennung und Wissenschaft. GI/SI-Fachlagung, ZOrich, MlIrz 1989. Proceed
1988.10. DAGM-Symposlum,ZOrich, September 1988. Proceedings. ings. XII, 427 Seiten. 1989.
XV, 361 Seiten. 1988. Band 205: P. J. KOhn (Hrsg.), Kommunlkatlon in verteilten Systemen.
ITG/GI-Fachtagung, Stuttgart, Februar 1989. Proceedings. XII, 907
Band 181: W. Hoeppner (Hrsg.), KOnstliche Intelilgenz. GWAI-88, 12. Seiten. 1989.
Jahrestagung. Eringerfeld, September 1988. Proceedings. XII, 333
Band 206: P. Horster, H.lsselhorst,Approximative Public-Key-Kryp
Seiten. 1988. tosysteme. VII, 174 Seiten. 1989.
Band 182: W. Barth (Hrsg.), Visualisierungstechniken und Algorith Band 207: J. Knop (Hrsg.), Organisation der Datenverarbeitung an
men. Fachgespr!!ch, Wien, September 1988. Proceedings. VIII, 247 der Schweile der 90er Jahre. 8. GI-Fachgespr!!ch, DOsseldorf, M!!rz
Seiten.1988. 1989. Proceedings. IX, 276 Seiten. 1989.
Band 208: J. Retti, K. Leidlmair (Hrsg.), 5. 6sterreichische Artificial
Band 183: A.Clauer, W.Purgathofer (Hrsg.), AUSTROGRAPHICS Intelligence-Tagung, Iglsmrol, M!!rz 1989. Proceedings. XI, 452 Sel
'88. Fachtagung, Wien, September 1988. Proceedings. VIII, 267 Sei ten. 1989.
ten. 1988.
Band 209: U.w. Upeck, Dynamische Integrit!!t von Datenbanken.
Band 184: B. Goilan, W. Paul,A. Schmitt (Hrsg.), Innovative Informati VIII, 140 Seiten. 1989.
ons-Infrastrukturen. I.I.I.-Forum, SaarbrOcken, Oktober 1988. Band 210: K. Drosten, Termersetzungssysteme.IX, 152 Selten.1989.
Proceedings. VIII, 291 Seiten. 1988.
Band 211: H. W. Meuer (Hrsg.), SUPERCOMPUTER '89. Mannheim,
Band 185: B. Mitschang, Ein MolekOI-Atom-Datenmodeil fOr Non Juni 1989. Proceedings, 1989. VIII, 171 Seiten. 1989.
Standard-Anwendungen. XI, 230 Seiten. 1988. Band 212: W.-M. Lippe (Hrsg.), Software-Entwicklung. Fachtagung,
Marburg, Juni 1989. Proceedings. IX, 290 Seiten. 1989.
Band 186: E. Rahm,Synchronisation in Mehrrechner-Datenbanksy
Band 213: I. Walter, Datenbankgestotzte Repr!!sentation und Extrak
stemen. IX, 272 Seiten. 1988. tion von Episodenbeschreibungen aus Bildfolgen. VIII, 243 Seiten.
Band 187: R. Valk (Hrsg.), GI-18. Jahrestagung I. Vernetzte und 1989.
komplexe Informatik-Systeme. Hamburg, Oktober 1988. Proceed Band 214: W. GOrke, H. SOrensen (Hrsg.), Fehlertolerierende
ings. XVI, 776 Seiten. Rechensysteme I Fault-Tolerant Computing Systems. 4.lnternatio
nale GI/ITG/GMA-Fachtagung, Baden-Baden, September 1989.
Band 188: R. Valk (Hrsg.), GI-18. Jahrestagung II. Vernetzte und Proceedings. XI, 390 Selten. 1989.
komplexe Informatik-Systeme. Hamburg, Oktober 1988. Proceed
Band 215: M. Bidjan-Irani, Quallt!!t undTestbarkeit hochintegrlerter
ings. XVI, 704 Seiten.
Schaltungen. IX, 169 Seiten. 1989.
Band 189: B. Wolfinger (Hrsg.), Vernetzte und komplexe Informatik Band 216: D. Metzing (Hrsg.), GWAI-89. 13th German Workshop on
Systeme.lndustrieprogramm zur18.Jahreslagung derGI, Hamburg, Artificial Intelligence. Eringerfeld, September 1989. Proceedings. Xii,
Oktober 1988. Proceedings. X, 229 Seiten. 1988. 485 Seiten. 1989.
Band 217: M. Zieher, Kopplung von Rechnernetzen. XII, 218 Seiten.
Band 190: D. Maurer, R&levanzanalyse. VIII, 239 Seiten. 1988.
1989.
Band 191: P. Levi, Plan en fOr autonome Montageroboter. XIII, 259 Band 218: G. Stiege, J. S. Lie (Hrsg.), Messung, Modellierung und
Seiten.1988. Bewertung von Rechensystemen und Netzen. 5. GI/ITG-Fachta
Band 192: K. Kansy, P. WIBkirchen (Hrsg.), Graphik im BOroberelch. gung, Braunschweig, September 1989. Proceedings. IX, 342 Seiten.
1989.
Proceedings, 1988. VIII, 187 Seiten. 1988.
Band 219: H. Burkhardt, K. H. HOhne, B. Neumann (Hrsg.), Musterer
Band 193: W. Gotthard, Datenbanksysteme fOr Sof1lNare-Produkti
kennung 1989. 11. DAGM-Symposium, Hamburg, Oktober 1989.
onsumgebungen. X, 193 Seiten. 1988.
Proceedings. XIX, 575 Seiten. 1989
Band 194: C. Lewerentz, Interaktives Entwerfen groBer Programmsy Band 220: F. Stetter, W. Brauer (Hrsg.), Informatik und Schule 1989:
steme. VII, 179 Seiten. 1988. Zukunftsperspektlven der Informatik fOr Schule und Ausbildung.
GI-Fachlagung, MOnchen, November 1989. Proceedings. XI, 359
Band 195: I. S. Batori, U. Hahn, M. Pinkal, W. Wahlster (Hrsg.), Compu Seiten. 1989.
terlinguistik und ihre theoretischen Grundlagen. Proceedings. IX,
Band 221: H. Schelhowe (Hrsg.), Frauenwelt - Computerr!!ume.
218 Seiten. 1988.
GI-Fachtagung, Bremen, September 1989. Proceedings. XV, 284
Band 197: M. Leszak, H. Eggert, Petri-Netz-Methoden und -Werk Selten.1989.
zeuge. XII, 254 Seiten. 1989. Band 222: M. Paul (Hrsg.), GI-19.Jahrestagung I. MOnchen, Okto
Band 198: U. Reimer, FRM: Ein Frame-Repr!!sentationsmodeil und ber 1989. Proceedings. XVI, 717 Seiten. 1989.
seine formale Semantik. VIII, 161 Seiten. 1988. Band 223: M. Paul (Hrsg.), GI-19.Jahrestagung II. MOnchen, Okto
Band 199: C. Beckstein, Zur Logik der Logik-Programmierung. IX, ber 1989. Proceedings. XVI, 719 Seiten. 1989.
246 Seiten. 1988. Band 224: U.Voges, Software-Diversit!!t und ihre Modeilierung. VIII,
Band 200: A. Reinefeld, Spielbaum-Suchverfahren. IX, 191 Seiten. 211 Seiten. 1989
1989. Band 225: W. Stoil, Test von OSI-Protokollen. IX, 205 Seiten. 1989.
Informatik-Fachberichte 273
Herausgeber: W. Brauer
im Auftrag der Gesellschaft fOr Informatik (GI)
M. Timm (Hrsg.)
Requirements Engineering '91
"Structured Analysis" und verwandte Ansatze
Marburg, 10,/11. April 1991
Proceedings
Spri nger -Verlag
Berlin Heidelberg New York London Paris
Tokyo Hong Kong Barcelona Budapest
Herausgeber
Michael Timm
Gesellschaft fOr Mathematik und Oatenverarbeitung mbH
Institut fOr Systemtechnik
Postfach 1240, SchloB Birlinghoven, W-5205 Sankt Augustin 1
CR Subject Classification (1981): 0.2.1,0.2.2.
ISBN-13 : 978-3-540-54025-0 e-ISBN-13 : 978-3-642-76622-0
001: 10 .1007/978-3-642-76622-0
Dieses Werk ist urheberrechtlich geschOtzt. Die dadurch begrOndeten Rechte, insbesondere
die der Obersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Ta
bellen, der Funksendung, der Mikroverfilmung oder der Vervielfllltigung auf anderen Wegen und
der Speicherung in Datenverarbeitungsanlagen, blelben, bei auch nur auszugsweiserVerwer
tung, vorbehalten. Eine Vervielfaltigung dieses Werkes oder von Teilen dieses Werkes ist auch
im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes
der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung
zulllssig. Sie ist grundsatzlich vergOtungspflichtig. Zuwiderhandlungen unterliegen den Straf
bestimmungen des Urheberrechtsgesetzes.
© Springer-Verlag Berlin Heidelberg 1991
Vorwort
Die Fachtagung "Requirements Engineering '91 - 'Structured Analysis' und
verwandte Ansatze" yom 10. bis 11. April 1991 in Marburg wird in
Fortsetzung der "Requirements Engineering '83" in Friedrichshafen, der
"Requirements Engineering '87" in Sankt Augustin und den Fachveranstal
tungen im Rahmen der Jahrestagung der Gesellschaft fUr Informatik 1985 in
Wi en durchgefUhrt.
Requirements Engineering wird interpretiert als Wissenschaft, die sich mit
der Erfassung, Beschreibung und Uberprlifung von Anforderungen an ein
informationstechnisches System auseinandersetzt mit dem Ziel, metho
dische Konzepte fUr diese Aufgaben zu erarbeiten und in anwendungs
taugliche Verfahren umzusetzen. Die Fachtagung solI den Erfahrungs
austausch zwischen Theorie und Praxis fOrdern, urn versUirkt ingenieur
ma15ige Vorgehensweisen beim Requirements Engineering zu erhalten und
weiterzuentwickeln.
Durch die Ausrichtung auf 'Structured Analysis' und verwandte AnsiHze
erfolgt eine kritische Auseinandersetzung mit Methoden und Verfahren, die
in der Praxis mit Erfolg eingesetzt werden, da sie einerseits die Kom
munikation zwischen weniger DV-erfahrenen Anwendern und System
entwicklern unterstiitzen und andererseits Ansatzmoglichkeiten zur
Uberprlifung der Korrektheit der spezifizierten Anforderungen bieten.
Erfahrungsberichte liber den Einsatz von 'Structured Analysis' und
verwandte Ansatze sowie eine Diskussion ihrer Vor- und Nachteile sind
daher zentraler Gegenstand dieser Veranstaltung.
Die Tagung wird yom FachausschuB 4.3 "Requirements Engineering" des
GI-Fachbereichs 4 "Informationstechnik und technische Nutzung der Infor
matik" veranstaltet. Herzlich danken mochte ich an dieser Stelle
den Autoren der Beitrage, die sehr kooperativ auf die Wlinsche des
Programmausschusses eingegangen sind und ihre AusfUhrungen frist
gerecht fertiggestellt haben,
VI
den Mitgliedern des Programmausschusses fUr ihre konstruktive und
kritische Arbeit bei der Auswahl geeigneter Beitrage und ihr Engagement
bei der Vorbereitung der Fachtagung,
der Gesellschaft fUr Informa tik,
dem Springer-Verlag,
Frau Heidrun Szameit fUr die Vor- und Nachbereitung der Programm
ausschuBsitzungen sowie ihre Unterstiitzung bei der Fertigstellung des
Tagungsbandes und
Frau Christine Harms sowie den Mitarbeiter{inne)n des Fachgebiets
Informatik der Philipps-Universitat Marburg fUr den engagierten Einsatz
bei der Vorbereitung und DurchfUhrung der Veranstaltung.
Die Fachtagung wendet sich an Anwender, Systemanalytiker und Wissen
schaftler, die sich mit Problemen des Requirements Engineering aus
einandersetzen und an einem intensiven Erfahrungsaustausch interessiert
sind. Ich wiinsche der Tagung einen guten Verlauf und hoffe, daB die
Teilnehmer und auch die Leser dieses Tagungsbandes wichtige Anregungen
fUr ihre kiinftige Arbeit sowie fUr die Weiterentwicklung des Requirements
Engineering finden werden.
Sankt Augustin, im Januar 1991 Michael Timm
Inhaltsverzeichnis
Structured Analysis auf dem Weg zum De-facto-Standard 1
(eingeladener Vortrag)
P. Hruschka
Probleme und Schwachstellen der Strukturierten Analyse 14
M. Glinz
Ein Vergleich von Requirements Engineering Methoden auf 40
Metamodell-Basis
H. Ftirberb6ck, T. Gutzwiller, M. Heym
Requirements Engineering bei der Techniker Krankenkasse: 67
Bin Erfahrungsbericht
D. Hansen, C. Roth
Erfahrungen mit der Anwendung von SA-Methoden zur 86
Beschreibung von Informations-Systemen
K. Jogun, M. Schlawne, J. Berger
Zustandsiibergangsdiagramme als strukturbestimmende Sicht 93
eines Systems
W. Theisges, H. Denk
Ein Konzept zur Wiederverwendung von Dokumenten der 129
Strukturierten Analyse
P. Forbrig
Strukturierte Analyse oder objektorientierte Methodik fUr 137
die Systemspezifikation? (eingeladener Vortrag)
E. Denert
Integration Strukturierter Methoden zur Anforderungs 139
spezifikation von Informationssystemen
M. Leszak, B. Franzen, K. Fritschi
VIII
Die Engineering-Sprache GRAPES 160
M. Pfeiffer, J. Kazmeier, R. Haggenmuller, R. Gunther
Die Methode der Strukturierten Analyse mit Petri 178
Netzen (SA/PN) als Echtzeiterweiterung
H. Franzen, G. Siegel
Structured Analysis: Ein Weg aus der Krise? 191
W. Wittstadt
STRUCTURED ANALYSIS
AUF DEM WEG ZUM DE-FACTO-STANDARD
Peter Hruschka
Systemhaus GEl
Aachen
Unter den zahlreichen Methodenansatzen, die als Lasung fUr die vielzitierte Softwarekrise in
den letzten 20 Jahren entwickelt wurden, hat Structured Analysis (SA) inzwischen einen
Stellenwert erreicht, der nicht mehr zu ubersehen ist. Nicht nur wegen technischer Argumente
wenden sich immer mehr Anwender dieser Analysemethode zu; alleine die Tatsache, daJ3 so
viele andere Systementwickler (erfolgreich) mit Structured Analysis arbeiten, veranlaJ3t
Einzelpersonen, Abteilungen, ganze Firmen und manchmal auch staatliche Autoritaten, SA
naher unter die Lupe zu nehmen. Dieser Beitrag diskutiert Griinde und Hintergriinde fUr den
heimlichen Industriestandard, zeigt den erreichten Stand auf und diskutiert magliche Hin
dernisse fur die weitere Verbreitung aus dem Blickwinkel eines "SA-Veteranen", der seit 12
Jahren mit dieser Methode lebt und seit 10 Jahren an der Entwicklung und am Ausbau von
CASE-Werkzeugen fur diese Methode beteiligt ist.
1 Wo steht Structured Analysis heute?
Systemanalyse heiJ3t Umgang mit Menschen -mit ihren Starken und ihren Schwachen, mit
ihren Wiinschen und ihren Zielen. Viele Teile der Arbeit eines Systemanalytikers sind
EinfUhlungsvermagen und Kunst. Ein Teil davon soUte aber in solides Handwerk umgewan
delt werden. Structured Analysis trat Mitte der 70er Jahre mit dem Anspruch an, die
Tatigkeiten, die bei der Analyse groJ3er Systeme anfallen, besser beherrschbar zu machen.
Statt alleine von der Geschicklichkeit und dem Gespur erfahrener Systemanalytiker abhangig
zu sein, wollte man eine lehr- und lernbare Vorgehensweise einfiihren.
Heute darf man unter SA nicht nur das verstehen, was in [DeM78] skizziert wurde. Die
Methode SA, die sich Mitte der 70er Jahre zu formen begann, Ende der 70er Jahre bereits in
mehreren Buchern (z.E. [DeM78], [Wei78], [G&S79]) dokumentiert wurde, hat sich seither
standig evolutionar weiterentwickelt. 1m folgenden wird die Methode SA so interpretiert, wie
sie in [You89a] beschrieben wurde: als drei integrierte Modelle, die drei verschiedene Sichten
auf die reale Welt darstellen (Funktionen, Daten und Verhalten). Viele verschiedene Namen
sind neben der Bezeichnung "Structured Analysis" in der Praxis dafUr im Umlauf: "Struktu
rierte Analyse", die "Yourdon Methodik", "YSM", die "DeMarco Methode", die "Gane-Sarson
Analysetechnik", SAIRT (Structured Analysis for Real-Time Systems), die HatleylPirbhai
Methode u.s.w.
2
Betrachten wir die Entwicklung einer Methode, urn den heute erreichten Status von SA besser
einordnen zu konnen. Viele "Methoden" bestehen zu dem Zeitpunkt, an dem sie der Offent
lichkeit vorgestellt werden, nur aus einem Paradigma und einer Notation.
Das Paradigma dIiickt aus, was dem Methodenschopfer als Abstraktion besonders wichtig
erscheint. Versucht man das Paradigma von SA in wenige Siitze zu fassen, so kommt man zu
folgenden zwei Punkten:
• Divide et impera: zur Beherrschung der Komplexitiit heutiger Systeme teilt SAdas System
modell in drei Teile auf. Dieses Aufteilen hilft beim spiiteren Lesen und Wiederfinden: man
weiB, nach welcher Information man in welcher "Schublade" suchen muB. Datendefinitio
nen findet man im Data Dictionary, Verarbeitungsinformationen in den Mini-Spezifikatio
nen; das Ruckgrat bilden die DatenfluBdiagramme, die ihrerseits wieder hierarchisch
zerlegt sein konnen. Globale Informationen findet man weiter "oben" in der Hierarchie, die
Details weiter "unten". An dieser Aufteilung in einzelne "Schubladen" wurde auch bei den
dieversen Erweiterungen festgehalten.
• Zusammenhang statt Isolation: statt wie fIiiher nur in Funktionen oder Funktionshierar
chien zu denken, denkt man in Zusammenhiingen zwischen den Funktionen (den Daten
flussen), urn spiitere "Schnittstellenprobleme" von vornherein zu vermeiden. 1m Gegensatz
zu HIPO, wo auch Input, Process und Output betrachtet wurden, aber der ProzeB im
Mittelpunkt stand, denkt man jetzt in ProzeB - DatenfluB - niichster ProzeB, wobei der
DatenfluB (der Zusammenhang) im Mittelpunkt steht.
Die Notation einer Methode braucht man unbedingt, urn die abstrakten Ideen der Methode
in konketer Weise zu Papier bringen zu konnen. Damit kann man erste Beispiel fur die
Anwendung des Paradigmas mit anderen Personen diskutieren. Bei SA fallen einem zuerst
die graphischen Ausdrucksmittel ein: die bekannten DatenfluBdiagramme. Mit nur 4 Symbo
len (Kreise fur Funktionen, Pfeile fur Datenflusse, zwei parallele Linien fur Datenspeicher
und Rechtecke fur externe Quellen und Senken) modelliert man Systemzusammenhiinge.
Daneben existieren aber auch die Vorschliige, wie man Daten im Data Dictionary definiert
und wie man Mini-Spezifikationen schreibt.
Ein Paradigma und eine Notation machen jedoch noch keine Methode: von diesem Punkt an
bis zu einer lehr-und lernbaren Vorgehensweise und Verfahrenstechnik ist es ein langer Weg.
SA umfaBt -neben der inzwischen sehr populiiren Notation der DatenfluBdiagramme -eine
Reihe von Verfahrenstechniken und Heuristiken, aber auch Managementregeln, wie man
den AnalyseprozeB im Rahmen des gesamten Projekts einordnen und den Aufwand dafur in
vertretbaren Rahmen halten kann [M&P84], [H&P87].
Die Verfahrenstechniken geben dem Systemanalytiker Antworten auf z.B. folgende Fragen:
Wie grenzt man das System systematisch gegenuber der Umgebung ab? Welche Kriterien kann
man anwenden, urn zu einer Zerlegung einer komplexen Funktion zu kommen? Wie gliedert
man gespeicherte Daten am besten in Entities oder Objekte? Wie modelliert man das dyna
mische Verhalten eines Teilsystems? Wie unterscheidet man zwischen DatenfluB und Steuer-