Beim Schreiben von Anforderungen steht ein Requirements Engineer mit jeder einzelnen immer wieder vor einer großen Herausforderung: Das Schreiben von qualitativ hochwertigen Anforderungen. Der Einsatz von Anforderungsschablonen kann das Qualitätskriterium „Eindeutigkeit“ durch eine festgelegte Syntax unterstützen.

In einem Projekt eines unserer Kunden, hatte ich mehrere Monate lang  die Möglichkeit, ein neuentwickeltes, in IBM rational DOORS integrierbares Tool einzusetzen, welches den Requirements Engineer dabei hilft, die richtige Syntax der Anforderungsschablonen einzuhalten. Da Anforderungsschablonen aus einem festgelegten Anteil von Begriffen der natürlichen Sprache bestehen, können sie automatisch verarbeitet werden.

Durch die festgelegte Syntax ist das Tool in der Lage, während dem Anwenden der verschiedenen Schablonen intern ein Modell zu erzeugen, so dass das Tool die Struktur des spezifizierten Systems lernt. Wendet man bei der Systemspezifikation die „Strukturierte Analyse“ an, so lernt das Anforderungsschablonen-Tool hierarchisch das System, seine Subsysteme, deren Funktionen, Inputs und Outputs kennen. Die folgenden beispielhaften Anforderungsschablonen zeigen, wie das Tool sein internes Modell erzeugt:

  1. Das Gesamtsystem <Systemname> besteht aus folgenden Subsystemen:<Subsystemname1> , <Subsystemname2> ,<Subsystemname3>.
  2. Das System <Subsystemname1> verarbeitet folgende Eingangsgrößen:<Inputname1>, <Inputname2>.

Mit Schablone 1 erfährt das Tool, welchen Namen das Gesamtsystem hat und welche Systeme (Subsysteme) unmittelbar eine Hierarchieebene unter dem Gesamtsystem stehen.
Durch Schablone 2 lernt das Tool die Eingangsgrößen von Subsystem 1 kennen.

Mit diesem Wissen kann das Tool, dem Requirements Engineer über eine Content-Assist Funktion (wie man sie aus Entwicklungsumgebungen wie Eclipse oder Visual Studio kennt) die System- oder Funktionsnamen oder Inputs und Outputs an den richtigen Stellen der jeweiligen Schablone zur Auswahl anbieten. Die Content-Assist Funktion bietet dem Requirements Engineer selbstverständlich auch die entsprechenden Schablonenkonstrukte an, so dass die gesamte Menge an Anforderungsschablonen nicht zuerst auswendig gelernt werden muss, bevor man das Tool einsetzen möchte.
Die festgelegte Syntax ermöglicht es dem Tool, ferner eine Problemliste zu erstellen, falls es Anforderungen findet – die eventuell vorher ohne das Tool geschrieben wurden –  welche nicht die korrekte Syntax der bekannten Schablonen aufweisen.

Das Tool ist intuitiv bedienbar, performant und verringert die Anzahl an Tippfehlern in bereits definierten Systemnamen oder Größen. Durch die integrierte Modellbildung des Tools könnte man in einer Weiterentwicklung per Knopfdruck Datenflussdiagramme erzeugen, so dass ein zeitraubendes, manuelles zusammenklicken von Datenflussdiagrammen entfällt. Des Weiteren kann man bei der automatischen Generierung von Datenflussmodellen sicher sein, dass keine Informationen überlesen werden.

Trotz Einsatz von Anforderungsschablonen wird es immer einen hohen Anteil an Freitextanforderungen geben, die der Modellbildung des Tools keinen Mehrwert bieten. Diese können daher nicht vom Tool interpretiert werden und es ist keine Fehlererkennung möglich. Allerdings bietet HOOD genau zu diesem Zweck das Tool DESIRe® an, welches Freitextanforderungen auf mögliche Schwächen hin untersucht.

Zu guter Letzt wird es schwierig sein, Anforderungsautoren ein Anforderungsschablonen-Tool „unterzujubeln“, wenn diese vorher bereits jahrelang frei und formlos spezifiziert haben.