Es gibt mehrere Möglichkeiten Anforderungsschablonen zu erstellen, wobei zwei in diesem Kapitel genauer erläutert werden. Anschließend erfolgt eine Eingliederung dieser Arbeit.

„Eine Anforderungsschablone ist ein Bauplan, der die syntaktische Struktur einer einzelnen Anforderung festlegt.“ [Rupp et al 07]

Bereits mit dieser Definition behaftet Rupp die Anforderungsschablonen als rein syntaktische Methode. Sie sagt aus, dass Anforderungsschablonen einem Requirements Engineer die Syntax vorgeben und der Requirements Engineer nur noch die notwendige Semantik definieren muss.

Christine Rupp möchte dabei die natürliche Sprache erhalten, nur soll diese in dem Maße eingeschränkt werden, dass „perfekte“ Anforderungen entstehen. Im Mittelpunkt ihrer Schablonen steht dabei das Prozesswort, welches ausdrückt was gemacht werden soll. Somit muss sich der gesamte Satzbau und der Inhalt der Anforderung an es anpassen. Ein weiterer Punkt ist die Systemaktivität. Dort trifft sie drei Unterteilungen:

• selbstständige Systemaktivität,
• Benutzerinteraktion und
• Schnittstellenanforderung.

Der nächste Aspekt ist das Festlegen der rechtlichen Verbindlichkeit. Da mit jeder Anforderungsliste und jeder Anforderung ein Vertrag einhergeht. Dabei bestimmen die Modalverben, wie wichtig die Anforderung sein soll. Sie benutzt dabei die Modalverben

1. muss,
2. sollte und
3. wird

Nun werden die Schablonen nur noch um ergänzende Objekte und Bedingungen erweitert. Letztendlich erhält man die Möglichkeit semantisch und syntaktisch korrekte Anforderungen zu bauen (siehe Abbildung 1).

Abbildung 1: Fertige Anforderungsschablone nach [Rupp et al 07]

Beispiel:

[Wann? Unter welcher Bedingung] [muss, sollte, wird] das System [Wem? die Möglichkeit bieten, Fähig sein] [Objekt und Ergänzung des Objekts] [Prozesswort].

Daraus wird:

Wenn der Kunde eine Rechnung wünscht, muss das System dem Kellner ermöglichen die Rechnung zu drucken.

[Rupp et. al. 07]

Toro et al. Stellen genauso wie Rupp die natürliche Sprache in den Vordergrund. Bei ihnen erfolgt eine Unterteilung zwischen L- und R Patterns. Dabei stehen L-Patterns für linguistic Patterns und R-Patterns für Requirement Patterns. Mit linguistic Patterns meinen sie häufig verwendete Sätze in natürlich-sprachlichen Anforderungsschablonen. Diese linguistic Pattern ähneln in etwa den Anforderungsschablonen von Rupp.

Der Hauptaspekt liegt jedoch auf den Requirements Patterns. Dabei unterteilen sie diese in drei verschiedene Patterns:

• Information Storage Requirements,
• Functional Requirements Template und
• Non-Functional Requirements.

Sie benutzen dabei für jedes der drei Patterns eine Tabelle. Die Information Storage Requirements sollen dabei den Anwendern helfen herauszufinden welche Informationen von dem System gespeichert werden müssen. Dadurch entstehen viele R-Patterns, die sich lediglich in dem Punkt der Relevanz unterscheiden. So gibt es zum Beispiel welche für Kunden, Produkte, Aufträge, Rechnungen und so weiter.

Das Functional Requirements Template beschreibt use cases und unterstützt Kunden und Nutzer in der Frage, was sie mit den gespeicherten Informationen anstellen wollen. Hier gibt es jedoch nur genau vier R-Patterns, die da wären Create, Read, Update, Delete (CRUD-Patterns).

Der dritte Teil der Non-Functional Requirements deckt jetzt nach Toro et al lediglich den Rest, also die übrig gebliebenen Pattern ab. [toro et al 99]

Diese Methodik findet kann jedoch keine Verwendung bei eingebetteten System finden, da sie vorgegebenen Muster bei weitem nicht ausreichen um alle notwendigen Anforderungen zu beschreiben.

Formale Methoden sind ein auf Mathematik basierender Ansatz zur Spezifikation, Entwicklung und Verifikation von Software- und Hardwaresystemen. Der Grundgedanke ist dabei, die Erfüllung einer Anforderung nicht nur zu testen, sondern auch mathematisch zu beweisen. Dies ist ähnlich der Cleanroom Methode zur Programmierung.

Der Vorteil dieses Ansatzes ist, dass die Requirement Engineers sehr diszipliniert vorgehen müssen und dadurch Fehler eher entdecken können. Weiterhin sind die entwickelten Anforderungen und Systeme präziser, als wenn sie auf herkömmliche Weise entwickelt wurden.

Die Nachteile dieses Ansatzes sind die hohen Kosten die damit einher gehen, weshalb diese Methodik hauptsächlich Verwendung bei sicherheitskritischen System findet.

Ein Beispiel hierfür ist Esterel. Esterel ist eine synchrone Programmiersprache für die Entwicklung von komplexen reaktiven Systemen. [Coll99]

Es gibt nicht viele Werkzeuge, die das Erstellen von Anforderungen unterstützen sollen, aber DESIRe ist eines von ihnen.

DESIRe ist ein von der HOOD Group entwickeltes Werkzeug, dass Requirements Engineers beim Erstellen von natürlichsprachlichen Anforderungen unterstützen soll. Dadurch sollen mehrdeutige Wörter entfernt werden, indem DESIRe vordefinierte Fragen stellt. Durch das gedankliche Beantworten dieser Fragen macht sich der Requirements Engineer nochmals Gedanken über diese Anforderung und kann für sich validieren ob sie gemäß der Qualitätskriterien korrekt ist. Am Screenshot kann man das Vorgehen ziemlich genau erkennen. DESIRe durchsucht die Anforderung nach Wörtern, die vorher als kritisch (zum Beispiel mehrdeutig) definiert wurden und stellt dem Requirements Engineer die vorher definierten Fragen zu diesem Wort. Dieser kann nun entscheiden, ob er die Anforderung ändern will oder so belassen.

Abbildung 2: Screenshot DESIRe

Ein weiteres Tool, auf das ich aber nicht näher eingehen möchte, wurde von Frau Rupp und den Sophisten entwickelt um ihre entwickelte Methodik zu unterstützen.

Andere Programme wie zum Beispiel DOORS oder Requisite Pro dienen lediglich zur Verwaltung von Anforderungen. Sie unterstützen einem nicht beim Erstellen von Anforderungen gemäß den Qualitätskriterien.

Lange Zeit gab es beim Erstellen von Anforderungen aus Schablonen nur zwei Extrema. Ein Ansatz konzentriert sich darauf die Reviews zu erleichtern, wie zum Beispiel DESIRe. Der andere Ansatz sind formale Methoden, wie sie zum Beispiel von Esterel umgesetzt werden. Der Nachteil des formales Ansatzes ist, dass die natürliche Sprache gänzlich verloren geht. Es entsteht ein Wulst von formalen Regeln. Dadurch ist es für die Personen, die diese formale Methode nicht kennen nicht möglich die Anforderungen zu verstehen. Aber für alle anderen Personen sind die Anforderungen eindeutig. Die formalen Methoden finden meist nur in sehr sicherheitskritischen Anwendungen Verwendung.

Der Nachteil von DESIRe ist, dass erst einmal Anforderungen formuliert werden müssen bevor diese mit Hilfe von DESIRe einem Review unterzogen werden können. Weiterhin habe ich beim testen von DESIRe ein weiteres Manko festgestellt. Es ist nicht in der Lage Zusammhänge zu erkennen. Die Methode von DESIRe wird einfach stupide für jedes Wort angewendet, wodurch es bei schon qualitativ hochwertigen Anforderungen schnell lästig werden kann. Die Fragen werden konsequent weitergestellt, obwohl die Antworten bereits in der Anforderung stehen.

Die Methode von Frau Rupp bildet in meinen Augen eine Grundlage auf der man aufbauen kann, aber für die tatsächliche Benutzung noch erweitert werden muss.

Mittlerweile sind aber auch viele Forschungen gemacht worden einen Mittelweg zwischen diesen beiden Extrema zu finden. Ein Ansatz ist zum Beispiel der Artikel von Herr Holtmann [Holt10]. Dieser nennt die Probleme, die entstehen, wenn man Anforderungen mit reiner natürlicher Sprache schreibt und wie diese durch Verwendung von Satzmustern behoben werden können. Dabei werden den Requirements Engineers Anforderungssätze vorgegeben und sie müssen in diesen die entsprechenden Satzteile verändern, so dass eine vollständige Anforderung entsteht. Herr Holtmann legt dabei großen Wert darauf, dass die Anforderungen so geschrieben werden, dass es später möglich ist automatisch ein Modell daraus zu entwickeln. Er gibt dafür eine Unterteilung in 4 Kategorien an und erwähnt das momentan circa 100 verschiedene Satzmuster existieren. Ein Beispiel eines Satzmuster ist:

Systemzustandswechsel:

„¹⁾ in den [Zustand] (<Zielzustand> | Endzustand) über [; ( parallel dazu | zugleich) wird [die Funktion „<Funktion>“ (gestartet | aktiviert | reaktiviert | gestartet oder reaktiviert)]]. [Dies darf [minimal <Min-Zeit>] [und] [maximal <Max-Zeit>] dauern.] „

Dabei sind | Auswahl einer Alternative, [] optionale Teile, <> Stelle, in der Aufzählungen oder gewisse Freitextanteile eingesetzt werden können.

Meiner Meinung nach sind diese Satzmuster zu groß und zu komplex um sie wirklich anzuwenden. Es ist schwer festzustellen welche Anforderungen mit diesem Satzmuster entwickelt werden können und erst durch Probieren sind die Ausmaße wirklich erkennbar. [Holt10]

Der Vorteil von Anforderungsschablonen ist, dass Anforderungen in natürlicher Sprache geschrieben werden, aber durch einen beschränkten Wortschatz in der Form vereinfacht, dass sie leichter zu verstehen sind und auch eindeutiger werden. Durch die Vorgabe der Syntax erhalten die Anforderungen eine einheitliche Struktur, wodurch einem auch die Möglichkeit geboten wird Anforderungen einfacher wieder zu verwenden. Zur Erstellung solcher Anforderung ist jedoch ein geeignetes Werkzeug unabdingbar, da das Erstellen von Hand für den Requirements Engineer mühsam wäre.

Der Ansatz dieser Arbeit ist ähnlich dem von Herrn Holtmann, jedoch verfolgt sie ein anderes Ziel. Es geht darum Anforderungen einheitlicher, leichter, verständlicher und auch schneller zu formulieren ohne dabei auf natürliche Sprache zu verzichten. Somit steht am Ende nicht das Modell im Vordergrund sondern die Anforderungsliste. Außerdem wird bei Herrn Holtmann nicht erwähnt wie die Variablen in den Satzmustern gewählt werden. Vielleicht eine hierarchische Struktur, vielleicht aber auch eine große Liste. Aus den Screenshots lässt sich lediglich erahnen, dass wahrscheinlich eine hierarchische Struktur verwendet wird.

Die Analyse ist der erste Schritt der Systementwicklung und entscheidet somit maßgeblich über den Erfolg oder Misserfolg des Projektes. Nach wissenschaftlichen Studien wird das Entfernen von Fehlern in späteren Entwicklungsphasen immer um ein vielfaches teurer als in der Phase, in der der Fehler entstanden ist. Rupp [Rupp 2006] gibt zum Beispiel an, dass sich 65% der schwerwiegenden Fehler auf fehlerhaftes Verhalten in der Analyse zurückführen lassen.

Man bräuchte somit eine Methode, welche einem Requirements Engineer ermöglicht den Qualitätskriterien gemäß korrekte Anforderungen mit Hilfe von Templates zu erstellen.

• Zusammenfassung
• Einleitung
• Grundlagen
• Stand der Technik
• Variable Templates
• Usecases
• Prototypische Implementierung
• Evaluation
• Fazit