Erfahrungsbericht über einen Spezifikationsprozess mit einem bunten Reigen an Methoden und Notationen Chris Rupp, Nicole Schimpfky

1. Einleitung Im folgenden werden die Erfahrungen aus dem Spezifikationsprozess von zwei Projekten vorgestellt. Dabei wurde in dem einen Projekt ein geschäftsorientiertes System, in dem anderen Projekt ein technikbasiertes System spezifiziert. Bei beiden Projekten war das Vorgehen gleich. Die Beschreibung des Spezifikationsprozesses beschränkt sich auf vier Bausteine: (1) eingesetzte Methoden für die Strukturierung der Spezifikation, (2) verwendete Software, (3) eingesetzte Methoden für das Sicherstellen der Mindestqualität von Anforderungen und (4) Hilfsmittel für die Projektabwicklung.

Aktivitätsdiagramme ergaben Strukturierungsebene.

die

dritte

Ziele Protokolle von Interviews, Gesprächen ...

uc

example

Use case 1

ad

Use case 2

use case 2

Action 2 Action 1

2. Methoden zur Strukturierung der Spezifikation Das Volere Template wurde von James und Suzanne Robertson entwickelt und ist ein Template für die Anforderungsspezifikation [Robertson]. Im Rahmen des eigenen Spezifikationsprozesses bildete das Volere Template die Grundlage für die Strukturierung der Spezifikation. Der Vorteil des Templates ist, dass es insgesamt ein sehr breites Spektrum an Kategorien abdeckt, es also über den Fokus auf Anforderungen hinaus geht. Der Nachteil des Templates für die eigene Spezifikation bestand aber in der begrenzten Detaillierung der Kategorie „Funktionale und DatenAnforderungen“ (Punkt 9 in Version 9). Eine mangelnde Feinstrukturierung der funktionalen Anforderungen zieht eine Kette von Probleme nach sich. Zum Beispiel könnte ein fehlender Überblick zu redundanten oder auch widersprüchlichen Anforderungen führen. Um ein systematisches Vorgehen sicher zu stellen, wurden zwei UML Diagramme für die Verfeinerung der Strukturierung im Bereich der funktionalen Anforderungen benutzt (siehe Abbildung 1). Die Grundlage für die erste Strukturierungsebene der funktionalen Anforderungen bildete das Use Case Diagramm. Mittels der einzelnen Use Cases beschreibt dieses Diagramm die Aufteilung der Gesamtfunktionalität des Systems. Daher stellten die Use Cases die oberste Strukturierungsebene der funktionalen Anforderungen dar. Die Grundlage für die zweite Strukturierungsebene bildeten die Aktivitätsdiagramme, die für die Verfeinerung der einzelnen Use Cases modelliert wurden. Ein Aktivitätsdiagramm beschreibt Abläufe, die zusammen die Funktionalität eines Use Case formen. Die einzelnen Aktionen der Aktivitätsdiagramme bildeten daher die zweite Strukturierungsebene. In den Fällen, in denen eine weitere Verfeinerung notwendig war, wurden einzelne Aktion wiederum durch ein Aktivitätsdiagramm verfeinert. Aktionen dieser

dann

Action 4 Action 3

ad

Action 3

Action a

Action b

Action c

9.1. Use case 2 9.1.1 Action 1 9.1.2 Action 2 9.1.3 Action 3 9.1.3.1 Action a 9.1.3.2 Action b 9.1.3.3 Action c 9.1.4 Action 4

Abbildung 1: Strukturierung der funktionalen Anforderungen durch UML Diagramme Diese Feinstrukturierung der funktionalen Anforderungen erhöhte auf Kundenseite die Akzeptanz der Spezifikation gegenüber. Auf der Basis dieser Struktur war eine einfache Navigation durch die Gesamtspezifikation möglich. Somit konnten einzelne Kunden nur die Anforderungen bezüglich der Use Cases oder Actions lesen, die Ihren Fachbereich betrafen. Parallel zur Modellierung des Systemverhaltens wurden alle zentralen Begriffe und deren Zusammenhang in Form eines Klassendiagramms modelliert. Jede Klasse, sowie jedes Attribut wurde ausführlich natürlichsprachlich definiert um mit einem Beispiel untermauert, um die Definition sofort plastisch greifbar zu machen. Die im Klassendiagramm definierten Begriffe stellten den Hauptteil des Wortschatzes dar, der bei der natürlichsprachlichen Definition der Anforderungen oder in den verhaltensspezifizierenden UML-Diagrammen verwendet wurde.

3. Software

6. Zusammenfassung und Erfahrungen

Die eingesetzte Software für das Verwalten der Anforderungen variierte in den zwei Projekten. In dem einen Projekt wurden die Anforderungen in der von der SOPHIST Group entwickelten Software CARE [SOPHIST] verwaltet. Bei dem anderen Projekt wurde zunächst MS Word später aber DOORS von Telelogic [Telelogic] als Software eingesetzt. Der Vorteil einer Datenbank basierten Software liegt darin, dass zum einen durch die Wahl verschiedener Sichten das Sortieren und damit das Auffinden von Anforderungen sehr effizient ist und zum anderen die Verfolgbarkeit der zusammenhängender Anforderungen und Dokumenten, z.B. bei Change Requests unterstützt wird. Zusätzlich dazu wurden die UML Diagramme mit MS Visio und UML2-konformen Visioschablonen erstellt und die geführten Gespräche und Interviews, aus denen Anforderungen abgeleitet wurden, mit MS Word dokumentiert.

Durch den vorgestellten Reigen an Methoden und Werkzeugen konnte systematisch eine qualitativ hochwertige Spezifikation erstellt werden, die vom Kunden verstanden und akzeptiert wurde. Doch hat auch dieses Vorgehen seine Schwächen. Das Volere-Template stellt eine sehr gute Top-LevelStruktur für Anfroderungssdokumente dar. Durch die Beschreibung der einzelnen Kategorien unterstützt es den Analytiker sehr viele Kategorien von Anforderungen, sowie das Projektumfeld zu erfragen. Einige der Volere-Kategorien überschneiden sich allerdings sehr stark mit anderen Disziplinen. Z.B. kann man lange darüber diskutieren, ob es Aufgabe des Systemanalytikers ist sich mit der Risikoanalyse oder dem Projektbudget zu befassen und ob diese Informationen in einem Anforderungsdokument am richtigen Platz sind. Wahr ist, dass diese Informationen auch für den Analytiker von Bedeutung sind. Durch die weitere Strukturierung mittels Use Cases und Aktivitätsdiagrammen sind die Anforderungen zwar sehr klar strukturiert, aber auch sehr eng mit den UML-Diagrammen verzahnt. Anforderungen und UML Diagramme wurden aber mit verschiedenen Medien (MS Visio, MS Word, CARE, DOORS) erstellt. Diese Konstellation verursachte Konsistenzprobleme, da das Einpflegen von Änderungen z.B. in der Funktionalität, in den Abläufen oder in der Struktur händisch und nicht tool-unterstützt erfolgte. Eine mögliche Lösung wäre eine Software, die den gesamten Spezifikationsprozess abbildet und die Änderungen automatisch an allen betroffenen Stellen aktualisiert. Ein weiteres Problem stellten die Use Cases als erste Strukturierungsebene der Spezifikation dar. Zwar beschreiben Use Cases auf sehr abstrakter Ebene die Funktionalität des Systems und sollten daher recht stabil im Verlauf des Spezifikationsprozesses sein, doch hat sich bei beiden Projekte herausgestellt, dass die anfänglich aufgestellte Use Cases instabil waren. Neue Erkenntnisse über das System, die in Interviews gewonnen wurden, erforderten manchmal ein Umdefinieren der Use Cases. Das hatte zur Folge, dass die gesamte Struktur der Spezifikation geändert und somit alle Anforderungen umsortiert werden mussten. Einen stabileren Strukturierungsansatz verspricht das Klassendiagramm. Hier besteht aber die Gefahr, dass der Kunde damit Verständnisprobleme hat. Der Erfahrungsbericht hat gezeigt, dass das angewandte Verfahren praktikabel ist, aber mittels geeigneter Software durchaus noch effizienter gestaltet werden könnte.

4. Methoden für die Sicherstellung einer Mindestqualität Qualitativ hochwertige Anforderungen sparen Kosten, da sie den Änderungsaufwand während und nach der Systementwicklung reduzieren [Rupp]. Die Qualität der Anforderungen ist an folgenden Eigenschaften messbar: Korrektheit, Eindeutigkeit, Vollständigkeit, Widerspruchsfreiheit, Klassifizierbarkeit und Überprüfbarkeit. Um eine Mindestqualität der Anforderungen in beiden Projekten sicherzustellen, wurden bei der Formulierung der Anforderungen die Anforderungsschablone [Rupp] sowie das SOPHISTREgelwerk [Rupp] angewendet. Mit dieser Kombination aus Methoden, basierten die generierten Anforderungen auf einheitlichen Begriffen und waren syntaktisch korrekt und klassifizierbar.

5. Hilfsmittel für die Projektabwicklung Zusätzlich zu den genannten Methoden wurden Arbeitsanweisungen und standardisierte Mails für die Kommunikation mit dem Kunden verwendet. Diese halfen den administrativen Aufwand zu reduzieren. An den Kunden wurde ein wöchentlicher Statusbericht mit Statistiken und Informationen über den Projektfortschritt geschickt. Ferner wurde dem Kunden ein Webzugang zu den Datenbanken (CARE) angeboten, um „live“ den Arbeitsvorgang mitzuverfolgen. Beide Maßnahmen dienten der Projekttransparenz und erhöhten das Vertrauen auf Kundenseite, wobei die Kunden den Webzugang nur sehr eingeschränkt nutzten. Für das bessere Verständnis der Spezifikation wurde für den Kunden ein UML Notations-Leitfaden geschrieben, der alle verwendeten Diagramme und deren Notationselemente erläuterte.

7.

Literatur

[Robertson] Robertson, S. und J.: Mastering the Requirements Process, Addison-Wesley, London, 1999. [Rupp] Rupp, C.: Requirements Engineering and –Management, Hanser, München, 2004. [SOPHIST] www.sophist.de [Telelogic] www.telelogic.de