Übersetzungsdienst für Anforderungen

Bei der Beleuchtung der Parallelen und Unterschiede von Dokumentation in Diagrammform und in natürlicher Sprache entstanden Formeln für die Transformation von UML-Diagrammen in natürlichsprachliche Anforderungen.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 14 Min.
Von
  • Rainer Joppich
Inhaltsverzeichnis

Äpfel und Birnen lassen sich bekanntlich nicht miteinander vergleichen. Trotzdem haben sie ihre Gemeinsamkeiten – und Unterschiede. Ähnlich verhält es sich im Requirements Engineering beim Vergleich von Dokumentation in Diagrammform und in natürlicher Sprache. Bei einer Beleuchtung der Parallelen und Unterschiede beider Dokumentationstechniken entstanden Formeln für die Transformation von UML-Diagrammen in natürlichsprachliche Anforderungen.

Die einen dokumentieren ihre Anforderungen in natürlicher Sprache, andere hingegen ziehen die Unified Modeling Language (UML) [1] vor. Letztere fasst unterschiedliche grafische Notationen für die Spezifikation von Systemen zusammen und verwendet dabei Diagrammtypen wie das Aktivitäts- oder Klassendiagramm. Beide Beschreibungsformen – die in Text- und die in Modellform – haben ihre Stärken und Schwächen.

Eine hohe Komplexität des zu beschreibenden Bereichs lässt sich mit der Modellierung in UML verständlicher darstellen als mit natürlichsprachlichen Anforderungen. Spezifiziert man Anforderungen jedoch ausschließlich mit der UML, birgt das das Risiko, die Realität zu sehr zu abstrahieren und zu vereinfachen. Dem wirken Firmen entgegen, indem sie zusätzlich zum UML-Anforderungsmodell ihre Anforderungen um natürlichsprachliche Mittel erweitern, die das Modell mit weiteren Informationen anreichern. Wird diese Mischform bei der Anforderungsdokumentation nicht eingesetzt, lässt sich mit hoher Wahrscheinlichkeit vermuten, dass die Anforderungsspezifikation das Qualitätskriterium der Vollständigkeit nicht erfüllt. Um die Risiken nur einer Dokumentationsart zu minimieren, sollten Firmen beide Notationsformen in einem für das Projekt angemessenen Verhältnis verwenden.

Nicht selten tritt in Projekten die Situation auf, dass die Beteiligten Schwierigkeiten haben, die Bedeutung der UML-Diagramme zu verstehen. Dann kann es passieren, dass Anforderungen in Modellform ohne weiteres Hinterfragen abgenickt werden, um fehlendes Verständnis nicht preisgeben zu müssen. Das kann teure Nachbesserungen nach sich ziehen oder im schlimmsten Fall zur Nichtabnahme des Produkts führen.

Da das Abstimmen von Anforderungen für den Anforderungsanalytiker eine zentrale Aufgabe darstellt, ist die oben genannte Situation zu verhindern. In bestimmten Projektkonstellationen ist es deshalb nötig, mit der UML dargestellte Anforderungen in natürlichsprachliche Anforderungen zu überführen. Und zwar deshalb, weil ein Teil der Kunden nicht das Wissen über den Einsatz der UML-Notation als Anforderungsspezifikation besitzt – also die Personen, die die Anforderungen lesen, abstimmen, bewerten und weiterverarbeiten müssen.

Um die Übersetzung von Anforderungen zu erleichtern, hat die Sophist Group, die Firma des Autors, eine Methode zur Transformation der UML-Diagramme in eine Form entwickelt, die auch UML-Unkundige verstehen. Der Übersetzungsdienst Richtung natürlicher Sprache stellt im Sinne des "Certified Professional for Requirements Engineering" (CPRE) [3] eine Methode zur Unterstützung des Prüfprinzips "Wechsel der Dokumentationsform" und seiner Realisierung in der Praxis dar.

Diese Übersetzung dient dem Anforderungsanalytiker zusätzlich als qualitätssichernde Maßnahme seiner Analyseartefakte. Einerseits für ihn selbst innerhalb der Disziplin Analyse, um seine Ergebnisse zu prüfen. Andererseits auch in Form eines sogenannten Quality Gate beim Übergang von der Analyse in nachfolgende Disziplinen wie Architektur, Design oder Test. Denn spätestens bei diesen Disziplinübergängen muss der übergebene Teil der Anforderungsspezifikation hinsichtlich definierter Qualitätskriterien geprüft und abgenommen sein. Der Wechsel der Dokumentationsform über den Übersetzungsdienst erleichtert das Auffinden von Fehlern und Lücken innerhalb der Anforderungen und stellt somit ein Mittel dar, die geforderte Qualität der Anforderungsspezifikation zu erreichen.

Die Transformation vom UML-Diagramm zu natürlichsprachlichen Anforderungen und Dokumentationen wird regelgeleitet beschrieben, unterstützt durch den Einsatz von Templates, die je nach Diagrammart und Notationselementen differieren. Die Untersuchung beschränkte sich zunächst auf vier UML-Diagrammtypen, die für die Beschreibung von Anforderungen in der Anforderungsanalyse häufig zum Einsatz kommen: auf Klassen-, Use-Case-, Aktivitäts- und Zustandsdiagramm.

Durch den Einsatz des Regelwerks lässt sich eine vollständige Beschreibung der UML-Diagramme in
natürlichsprachlichen Anforderungen erreichen. Man läuft somit nicht Gefahr, wichtige Informationen während der Transformation zu verlieren. Da es schier unmöglich ist, alle Ableitungsregeln vorzustellen, beschränkt sich der Artikel auf einige wenige zu den unterschiedlichen Diagrammen.