Nachdem wir Ihnen im ersten Teil unserer Blogserie die SOPHIST-Schablone und eine Schablone von Esser & Struss vorgestellt haben, zeigten wir im zweiten Teil eine Schablonen von Alistair Mavin (EARS+), eine der IAG Consulting sowie eine von Jörg Holtmann. Dies alles sind Schablonen für funktionale Anforderungen. Im dritten und letzten Teil unserer Blogserie möchten wir Ihnen eine Schablone für nichtfunktionale Anforderungen vorstellen. Unter dem Namen NoFun (Akronym für Non-Functional Requirements) entwickelten Xavier Franch und Pere Botella eine Pseudo-Sprache für nichtfunktionale Anforderungen.
Franch und Botella gehen davon aus, dass in einer Anforderung einem Attribut eines bestimmten Typs ein Wert zugewiesen wird. Diese Attribute werden in Modulen deklariert und in Anforderungen instanziiert. Grund für diese Modularisierung ist die Möglichkeit der Kombination und Wiederverwendung der Module.
Am anschaulichsten ist die Erklärung wahrscheinlich an einem Beispiel:
attribute module DELIVERING_ISSUES
explanation date of delivery of components
attribute Month declared as Integer [1..12]
attribute Year declared as Integer [1970..]
attribute Date derived
declared as Tuple(Integer [1..12], Integer [1970..])
defined as (Month, Year)
explanation name of company delivering the product. „Own“ states for software produced in the company; use it instead of the name
attribute Supplier declared as string
end DELIVERING_ISSUES
Das attribute module DELIVERING_ISSUES besteht aus einem attribute Date, abgeleitet aus Month und Year, sowie aus einem attribute Supplier vom Typ string. Diesem attribute module werden im Folgenden requirement module Werte zugewiesen:
requirement module DATE_FACTS on DELIVERING_ISSUES for ACME
explanation requirement on the date of creation of ACME delivered software
definition
ACME-delivery-date: advisable
explanation Software made by ACME must not be dated before April 1998, which is the date the company started to use OO methodologies
defined as
Supplier = ‚ACME‘ implies
(Date.Year > 1998) or (Date.Year = 1998 and Date.Month >= 4)
end DATE_RESTRICTION
Das Date bekommt den Wert April 1998 und der Supplier den Wert ACME.
Alles klar? Falls Sie weitere Informationen über NoFun erhalten möchten, bekommen Sie die hier.
Unser durchgängig verwendetes Beispiel der Datei ergibt mit NoFun keinen Sinn, da unsere Anforderung eine funktionale Anforderung ist, mit NoFun aber nichtfunktionale Anforderungen geschrieben werden.
Der hohe Grad der Formalisierung der Schablone ist sowohl ein Vorteil als auch ein Nachteil. Vorteilhaft ist, dass Sie Anforderungen sehr genau und unmissverständlich aufschreiben. Außerdem lassen sich die Anforderungen kombinieren und zusammensetzen. Schließlich können Sie Anforderungen wiederverwenden, was viel Arbeit beim Neuerheben von Anforderungen erspart.
Nachteil der hohen Formalisierung ist die starke Komplexität. Wir jedenfalls mussten noch ein oder zwei Artikel über NoFun lesen, bis wir es ausreichend verstanden hatten. Falls Sie schneller sind, lassen Sie es uns wissen. ;-)
Fazit
In unseren drei Blogbeiträgen haben wir Ihnen einige Schablonen vorgestellt, mit denen Sie je nach Situation (fast) immer gute Anforderungen schreiben können. Da gab’s die SOPHIST-Schablone, mit der Sie immer funktionale Anforderungen schreiben könnten. Da war die Schablone von M. W. Esser und P. Struss, mit der automatisch Testfälle aus den Spezifikationen abgeleitet werden können. Da war EARS+ für verschiedene Spezifikationslevel. Da war die der IAG Consulting zur Dokumentation von Geschäftsprozessen. Da war eine von Jörg Holtmann, die besonders geeignet ist, falls auch ein Zustandsautomat modelliert wird. Und da war das formale aber sehr komplizierte NoFun für nichtfunktionale Anforderungen.
Damit haben Sie nun einen Überblick über die verschiedenen Formulierungshilfen zur Dokumentation von Anforderungen. Wählen Sie eine aus, dann steht Ihnen für gute Anforderungen nichts mehr im Wege.