Warum DSD?

Die Entwicklung von DSD – Nein, wir meinen nicht die Castingshow aus dem deutschen Fernsehen!

Nicht selten erleben wir in Projekten, dass die Projekt-Beteiligten Schwierigkeiten haben, die Bedeutung von Diagrammen der UML zu verstehen. Deshalb kommt es einerseits häufig vor, dass man sich in Projekten auf natürlichsprachliche Anforderungen einigt. Das kann jedoch ab einer bestimmten Komplexität dazu führen, dass die Anforderungsspezifikation unübersichtlich, beziehungsweise unlesbar wird. Weiterhin besteht die Möglichkeit, dass Sie die Vorgabe bekommen, Anforderungen redundant (in Diagrammform und anhand von natürlicher Sprache) zu beschreiben, da z. B. die Anforderungsspezifikation öffentlich gemacht werden muss und Sie nicht ahnen können, welchen Wissenstand Ihre Leser besitzen.
Des Weiteren haben wir die Erfahrung gemacht, dass der Kunde in Diagrammform dokumentierte Anforderungen ohne weiteres Hinterfragen einfach ab nickt, um sein fehlendes Verständnis nicht preisgeben zu müssen. Sollten Sie den Kunden bei der Anforderungserhebung missverstanden haben, kann dadurch die Entwicklung des Produkts an den tatsächlichen Kundenwünschen vorbei laufen. Das bedeutet im schlimmsten Fall, dass das fertige Produkt nicht abgenommen wird.

Um dies zu verhindern, haben wir eine Methode entwickelt, welche UML-Diagramme in eine Form transformiert, die auch UML Unkundige verstehen – natürliche Sprache. Dies hat den Nutzen, dass UML-Neulinge die Diagramme korrekt verstehen und diese Diagramme gleichzeitig von den Neulingen erlernt werden. DSD bietet weiterhin die Möglichkeit UML-Diagramme auf ihre Qualität zu überprüfen. Beispielsweise können Sie bei der Übertragung des UML-Diagramms in natürlichsprachliche Anforderungen, viele Unklarheiten identifizieren, sowie bereinigen.

In dieser Blog-Serie werden wir Ihnen die Transformation der am häufigsten verwendeten UML-Diagramme zu natürlichsprachlichen Anforderungen näher bringen.
Ziele und Nutzen von DSD

Die Transformation vom UML Diagramm zu natürlichsprachlichen Anforderungen und Dokumentationen beschreiben wir regelgeleitet, unterstützt durch den Einsatz von Templates, die je nach Diagrammart und den verschiedenen Modellelementen differieren. Wie zuvor erwähnt, haben wir uns auf die gebräuchlichsten Diagramme, die in der Anforderungsanalyse verwendet werden, konzentriert:

Um Ihnen den Lernprozess und die Arbeit zu erleichtern, haben wir diese Regelwerke und die Templates für die natürlichsprachlichen Anforderungen möglichst nah an die SOPHIST Anforderungsschablone [1] und das SOPHIST REgelwerk [1] angelehnt.

Neben dem Erschaffen einer allgemein verständlichen Kommunikationsbasis ist deren Qualität für einen erfolgreichen Projektverlauf von großer Bedeutung. Die natürlichsprachlichen Anforderungen, die Sie durch die Transformation als Output erhalten, erfüllen die Qualitätskriterien:

• Konsistenz
• Vollständigkeit
• Eindeutigkeit
• Bewertet

für Anforderungen [2].

Durch den Einsatz des Regelwerkes können Sie eine vollständige Beschreibung der UML Diagramme in natürlichsprachlichen Anforderungen erreichen und laufen somit nicht Gefahr wichtige Informationen während der Transformation zu verlieren.

In Abbildung 1 sehen sie einen Auszug aus unserem Regelwerk – eine Regel für die Transformation der Systemgrenze des Use-Case-Diagramms. In unserem nächsten Blogeintrag werden wir Ihnen diese und weitere Regeln für das Use-Case-Diagramm zeigen und anhand eines Beispiels erläutern. Zusätzlich möchten wir Sie auf den Blogeintrag „REstrukturierung gefällig?“ aufmerksam machen. Darin erläutern wir die STABLE Struktur, welche Sie simultan auf das Regelwerk von DSD anwenden können.

Abschließend an diesen ersten Blogeintrag möchten wir uns bei Ihnen für Ihr Interesse bedanken und hoffen, dass Sie die Vorstellung von DSD weiterhin verfolgen. Beachten Sie die Kommentarfunktion, mit der Sie uns ihre Meinung, beziehungsweise Wünsche mitteilen können.

[1]       Rupp, C., SOPHIST GmbH: Requirements-Engineering und –Management. Hanser, München, Wien 2009

[2]       IEEE Standards Board: IEEE Std 830-1998. IEEE Recommended Practice for Software Requirements Sepcifications. IEEE Press, 1998.