Softwareentwicklung
Anforderungsmanagement: Lesbarkeit und Effizienz
Jedes Software-Entwicklungsprojekt ist nur so gut wie seine Spezifikation. Diese müssen jedoch diverse Qualitätskriterien erfüllen, außerdem sind konsistente Gliederung und Verwaltung unabdingbar. Ein neuer Ansatz soll einen Spezifikationsstandard setzen.
Bei jedem Projekt müssen Spezifikationen diverse Qualitätskriterien erfüllen, damit alle Projektbeteiligten diese verstehen und umsetzen können. Neben Vollständigkeit, Korrektheit und Verständlichkeit existieren weitere Kriterien wie Konsistenz, Prüfbarkeit und Eindeutigkeit. Sind diese Kriterien erfüllt, erhält man qualitativ hochwertige Spezifikationen.
Weiterhin stellt sich die Frage, wo und wie diese Spezifikationen zu gliedern und abzulegen sind, um eine effiziente Arbeitsweise im Projekt zu gewährleisten. Genau hier soll der STABLE-Ansatz Abhilfe schaffen. Das Akronym steht für »STrukturieren Sie Anforderungen Besser, Lesbarer und Effizienter«.
Durch systematisches Strukturieren der funktionalen Anforderungen sollen konzeptuelle Lücken vieler Spezifikationslandschaften geschlossen werden. Zurzeit existieren unzählige Vorgaben (beispielsweise [1], [2], [3]), die beschreiben, wie man relevante Details einer Systemspezifikation in einer groben Spezifikationsgliederung aufführen kann. Diese Vorgaben sind allgemeingültig und verzichten auf eine Anleitung zur feineren Strukturierung der funktionalen Anforderungen.
Jobangebote+ passend zum Thema
Die Aufteilung von funktionalen Anforderungen ist prinzipiell von den fachlichen Gegebenheiten abhängig. Daher können keine einheitlichen Regeln festgelegt werden, um das allgemeine Vorgehen zu beschreiben. Um dieses Problem zu beheben, ist eine universelle Regelung zur Strukturierung verschiedener Spezifikationsartefakte nötig.
In der Praxis existieren genaue Vorgaben wie unternehmens- und projektspezifische Regelungen zur Gliederung von Spezifikationslandschaften und -artefakten (d.h. Dokumente und Anforderungen).
Da universelle Regelungen zur Strukturierung funktionaler Anforderungen fehlen, sehen sich die Autoren gezwungen, die Struktur selbstständig zu wählen.
Dabei werden die einzelnen funktionalen Anforderungen - die meist das Herzstück der Spezifikationen darstellen - wie ein Nebenprodukt behandelt und in einem Kapitel zusammengeführt, das für alle funktionalen Anforderungen als Behälter dienen soll (siehe Bild 1).
Folgen heterogener Spezifikationen
Ohne eine einheitliche Struktur zur Gliederung der Spezifikationsartefakte sind mögliche Fehler und Probleme vorprogrammiert. Man stelle sich einen Autor vor, der für jedes neue Dokument bezüglich der Anforderungsgliederung bei null anfängt oder sich an anderen Spezifikationen orientiert, deren abweichende fachliche Ausrichtung keine Hilfe bei der Strukturierung leisten kann.
Des Weiteren hat jeder Autor durch seine persönliche und berufliche Erfahrung eine eigene Vorstellung, wie fachliche Sachverhalte am besten aufzuteilen sind. Da Menschen ihre Arbeitsweise kontinuierlich verändern, kommt es oft vor, dass derselbe Autor in derselben Spezifikation zu verschiedenen Zeitpunkten Anforderungen unterschiedlich gliedert, sodass die Spezifikation in sich selbst heterogen strukturiert ist.
Bei einer Zusammenarbeit von mehreren Autoren an der gleichen Spezifikation kommt es ebenfalls sehr oft vor, dass diese nach unterschiedlichen Vorgehensweisen gliedern. Ohne zentrale Verantwortung für die Struktur ist eine inkonsistente Gliederung nahezu garantiert. Infolgedessen wird die Lesbarkeit eines Dokuments so erschwert, dass sich die Leser nicht in ein systematisches Gliederungskonzept hineinversetzten können und sich ständig fragen, wo die gesuchten Inhalte zu finden sind.
Dies kann Irrtümer, Missverständnisse und Enttäuschungen hervorrufen. Neben der inkonsistenten Gliederung können auch ungewöhnliche Gliederungen die Lesbarkeit erschweren. Die Denkweise jedes Menschen ist verschieden - was dem einen sinnvoll und strukturiert vorkommt, kann den anderen überfordern oder verwirren. Ebenso erschweren Mängel in der Aufteilung, die sich über mehrere unterschiedliche Dokumente hinziehen, die Lesbarkeit der Dokumente. Dies hat zur Folge, dass der Leser, der sich in dem einen Dokument zurechtfindet, für ein anderes Dokument wieder umdenken muss.
Von inkonsistenten oder verwirrenden Gliederungen sind neben den Lesern auch die Autoren betroffen, wenn diese neue Inhalte in eine Spezifikation einfügen möchten und sich in der mangelhaften Struktur nicht zurechtfinden. Dies führt dazu, dass neue Inhalte an ungeeignete Stellen in der Gliederung eingefügt werden und diese an dieser Stelle mehrdeutig wird. Diese Mehrdeutigkeit verleitet Autoren dazu, Neuinhalte an falsche Stellen zuzuordnen - nach dem Motto: »Wenn jener Sachverhalt dort steht, dann kann dieser neue Sachverhalt auch dort beschrieben werden«.
Durch diese ungenügende Systematik können selbst anfangs gut strukturierte Gliederungen nachhaltig zerstört werden. Anhand dieser Beispiele wird ersichtlich, dass die Nachteile einer inkonsistenten oder verwirrenden Gliederung zu einem hohen Zeitaufwand durch Suche nach nötigen Informationen und zu Fehlern durch Inkonsistenz/Redundanz führen und sich somit negativ auf die Effizienz im Umgang mit Spezifikationsartefakten und den darauf aufbauenden Entwicklungsprozessen auswirken.
Ordnung ins Chaos
Um das Problem der fehlenden Systematik zu lösen, wurde bei Sophist das Regelwerk »STABLE« entwickelt, das auf der Use-Case-Analyse [4] aufbaut.
In Bild 2 ist auf der linken Seite schematisch das Vorgehen der Use-Case-basierten Systemanalyse dargestellt. Dabei wird das betrachtete (Teil-)System bis in Elemente, die das detaillierte Verhalten des Systems beschreiben (z.B. Aktivitäten, Zustände), zerlegt.
Am Anfang stehen Use-Cases, welche die Systemfunktion aus Benutzersicht abstrakt beschreiben. In weiteren Schritten werden die Use-Cases in feinere Use-Cases, Aktivitäten oder Zustände zerlegt, um daraus funktionale Anforderungen abzuleiten. In der Regel werden die Ergebnisse dieser Analyse in Form von UML-Diagrammen dokumentiert.
Das STABLE-Regelwerk führt die Ergebnisse der Use-Case-Analyse in eine hierarchische Gliederungsstruktur über. Die dem Regelwerk zugrundeliegenden Prinzipien finden bei den Mitarbeitern von Sophist seit Langem in Projekten erfolgreiche Verwendung, sie werden auch in Schulungen vermittelt. Jedoch fehlte bisher eine dokumentierte Form der konkreten Vorgehensweise, um eine hierarchische Gliederungsstruktur auf Basis einer verhaltensorientierten Zerlegung zu erzeugen.
Kurz gesagt, werden mit Hilfe des STABLE-Regelwerks die im Umfang der Use-Case-Analyse erzeugten Modelle und Artefakte in eine analoge hierarchische Gliederung überführt, die eine Kapitelstruktur für natürlichsprachige Anforderungen darstellt. Das oberste Ziel des STABLE-Regelwerks war es, dieses deterministisch und iterativ aufzubauen. Anhand diverser Regeln wurden eindeutige Entscheidungen getroffen, wo welche Kapitel oder Unterkapitel angelegt werden müssen.
Bei der Anwendung einer Use-Case-Analyse können viele verschiedene Kombinationen von Diagrammen und Notationselementen zum Einsatz kommen. Daher sind die meisten jener Regeln durch vorangestellte Bedingungen eingeschränkt. Zum Beispiel können verschiedene Regeln bezüglich der Einordnung eines Use-Case-Diagramms in die Kapitelstruktur gelten. Je nachdem, ob ein Use-Case-Diagramm das Gesamtsystem, ein Teilsystem, einen anderen Use-Case, etc. beschreibt, gelten andere Regeln.
Einige Regeln der STABLE-Systematik sind rekursiv aufgebaut, da Verfeinerungen prinzipiell beliebig tief verschachtelt sein können - solche Regeln werden sowohl auf der obersten Ebene (z.B. grober Use-Case) als auch auf einer unteren Ebene (z.B. Detail-Use-Case) angewandt.
In Bild 3 ist eine exemplarische Präsentationsfolie zu sehen, die als Teil der Dokumentation des STABLE-Regelwerks erstellt wurde.
Diese enthält neben den eigentlichen Regeln des STABLE-Ansatzes ein Beispiel-UML-Modell und eine sich kontinuierlich vervollständigende Beispielgliederung. Das Regelwerk wurde Schritt für Schritt aufgebaut. In der ersten Version wurden nur die UML-Diagramme analysiert, die für die Use-Case-Analyse wichtig sind und am häufigsten angewandt werden.
Dabei beschränkte man sich auf folgende UML-Diagramme: Use-Case-Diagramm, Aktivitätsdiagramm und Zustandsautomatendiagramm. Die Ergebnisse dieser Analysen sind in dem STABLE-Regelwerk zusammengeführt. Im Moment werden die Regeln für verhaltensorientierte Diagramme um die Regeln für statische Diagramme (Klassen- und Komponentendiagramm) ergänzt.
Es finden Untersuchungen der statischen Diagramme auf deren Einsatzmöglichkeiten, die sinnvolle Einordnung in die Gesamtstruktur (z.B. Begriffsmodell zur Gliederung des Glossars) und die konkrete Überführung der Notationselemente hin statt. Als besondere Herausforderung stellt sich dabei die Hierarchisierung dar: Die Polyhierarchie der Notationselemente (beispielsweise Klassen im Klassendiagramm) muss in die Monohierarchie der Dokumentenstruktur überführt werden.
Die Monohierarchie in der Kapitelstruktur erlaubt immer nur ein Oberelement, während im Modell mehrere Oberelemente möglich sind. Weiterhin ist es nicht einfach, die Reihenfolge der Notationselemente nach thematischen Gesichtspunkten festzulegen. Sinnvolle und verständliche Regeln zur thematischen Gruppierung von Begriffen und deren Abhängigkeiten werden in der Forschung der Ontologie und Taxonomie noch immer untersucht. Alternativ könnte eine beliebige oder alphabetische Reihenfolge Verwendung finden.
Durch die Ergänzung der Regeln soll in Zukunft die vollständige Abbildung der in der Analyse geläufigen modellierbaren Diagramme in eine analoge Spezifikationsstruktur gewährleistet sein. Es gibt diverse Möglichkeiten das STABLE-Regelwerk einzusetzen. Zum einen kann es beispielsweise als Anleitung für einen Anforderungsanalytiker dienen, der anhand der Regeln systematische Gliederungen erzeugen kann. Zum anderen entsteht die Möglichkeit, UML-Modelle sinnvoll in natürlichsprachige Spezifikationen zu integrieren, da die erzeugte Gliederung aus den Diagrammen eine enge Bindung zwischen den Modellen und der natürlichen Sprache darstellt.
Es sind Pilotprojekte geplant, in deren Rahmen das Automatisierungspotenzial der Gliederungssystematik zu erforschen sein wird. Beispielsweise soll in einem Pilotprojekt die Erprobung eines (semi-)automatischen Abgleichs der UML-Modelle aus einem Modellierungswerkzeug mit der Gliederungsstruktur eines Requirements-Management-Werkzeugs stattfinden. Ferner soll eine automatische Übertragung von Änderungen an einem Modell in die Gliederungsstruktur getestet werden.
Referenzen
[1] VOLERE - S. Robertson, J. Robertson.: Mastering the Requirements Process. 2nd Edition. Pearson 2006.
[2] V-Modell XT - Beispielprojekt WiBe: Bundesrepublik Deutschland. KBSt 2004, kbst.bund.de
[3] IEEE Standards Board: IEEE Std 830-1998. IEEE Recommended Practice for Software Requirements Sepcifications. IEEE Press, 1998.
[4] A. Cockburn: Agile Software-Entwicklung. Die Prinzipien der agilen Software-Entwicklung dargestellt und erläutert. The MIT Press, 2003.
Lesen Sie mehr zum Thema
