Und weiter geht die Reise durch unser Requirements-Engineering und – Management Buch. Nach der modellbasiserten Dokumentation kommen wir nun zur natürlichsprachlichen Dokumentation mithilfe unserer Anforderungsschablonen.
Der Erfahrung nach können natürlichsprachliche Anforderungen in der „freien Wildbahn“ zunächst einmal jede Form und Farbe annehmen. Dass das nicht immer optimal ist, bemerkt man schnell, wenn man einige von ihnen im Rudel betrachtet. Beschreiben sie vielleicht alle das gleiche? Oder geht es überhaupt um dasselbe System? In den wenigsten Projekten findet sich die Zeit, jede Anforderung separat auf Eindeutigkeit und Konsistenz zu überprüfen.
Doch keine Sorge! Es gibt einen Plan, einen MASTeR-Plan!
Mithilfe der MASTeR-Schablonen lassen sich Anforderungen von Beginn ihres Daseins an, in syntaktische Ketten legen. Durch eine einheitliche Struktur werden Anforderungen eindeutiger, einheitlicher und eine Menge sprachlicher Effekte, die Wurzeln vieler Missverständnisse, werden vermieden.
Hat man eine solche Schablone erst vor Augen, sieht der geübte REler auch direkt den Mehrwert im ersten Baustein: Klare Ansagen – ein Akteur – Wer soll die Anforderung umsetzen? – Das System!
Ist für die erste Position des Anforderungssatzes sein System, oder „das System“ festgehalten, benötigt man jetzt die rechtliche Verbindlichkeit, oder Wichtigkeit der Anforderung. Ist die Umsetzung der Anforderung rechtlich bindend für die Abnahme des Produkts? Falls ja, muss ein „muss“ an zweiter Stelle folgen. Drückt die Anforderung stattdessen den Wunsch eines Stakeholders aus? Dann sollte hier auch ein „sollte“ stehen. Mit dem Verbindlichkeitswort „wird“ lassen sich zukünftige Rahmenbedingungen und bereits bestehende Absichten abstecken.
Anschließend muss man sich zunächst Gedanken über den Kern der Anforderung machen, die gewünschte Funktionalität, bzw. den durchgeführten Prozess. Dieser sollte durch ein Vollverb, also ein Verb das alleine im Satz stehen kann möglichst akkurat beschrieben werden. Dieses Wort merkt oder notiert man sich für das Ende des Anforderungssatzes.
Warum man das Pferd von hinten aufzäumt?
Das Vollverb, bzw. Prozesswort gibt meist schon einen starken Hinweis auf die Art von Systemaktivität, die diese Anforderung beschreiben soll: Handelt es sich um eine Systemaktivität, welche vom System selbsttätig gestartet und durchgeführt wird, wie das Berechnen einer Variable, folgen Objekt und Prozesswort direkt auf das Verbindlichkeitswort. Wenn hingegen einem Nutzer des Systems eine Funktionalität zur Verfügung gestellt wird, benötigen wir nach dem Prozesswort diesen Nutzer, oder <Akteur>, sowie die Formulierung „die Möglichkeit bieten“. Auch der dritte Typus Systemaktivität hängt davon ab, wie die beschriebene Aktion letztendlich ausgelöst wird. Falls der Anstoß hierzu von einem anderen System kommt, verwenden wir die Formulierung „fähig sein“, zwischen Verbindlichkeitswort und Objekt oder Prozesswort.
Für eine erste vollständige Anforderung fehlt uns nur noch das Objekt des Anforderungssatzes. Schließlich ist die Anforderung „Das System soll drucken.“ so alleine doch recht inhaltslos. Wir beschreiben nun im vorerst letzten Schritt mit einem Objekt noch unser Prozesswort näher. Damit haben wir es geschafft! Eine zunächst vollständige, einheitliche Anforderung, die Missverständnisse bereits syntaktisch vermeidet. Erweitern lässt sich diese natürlich noch durch beispielsweise Bedingungen, ebenfalls formuliert mit dem BedinungsMASTeR, einem Heroldsschild gegen absehbare Missverständnisse, da er nur eindeutig formulierte Bedingungen zulässt und konditionale Ausdrücke auf das präzise Minimum reduziert.
Oder durch eine nähere Beschreibung des Objekts mit dem Eigenschafts-MASTeR, oder durch eine Prüfung auf sprachliche Defizite mit dem Regelwerk, oder, oder, oder…
Natürlich lässt sich nicht jeder Typ von Anforderung in die gleiche Form pressen. Deshalb gibt es unsere spezialisierten Schablonen.
Auch wenn das schrittweise Formulieren einer einzelnen Anforderung so zunächst aufwändig wirkt und Konzentration erfordert, geht einem doch die Struktur mit jeder neuen Anforderung in Fleisch und Blut über. Schon bald erscheint jede Anforderung die nicht dem Template entspricht „irgendwie falsch“, während man selbst automatisch schablonisiert verfasst, wie der Autor selbst bemerken durfte.
Buchkapitel 10 unseres Werkes „Requirements-Engineering und Management“ bietet natürlich nicht nur eine Anleitung zum Verwenden der einzelnen Schablonen sondern auch Hintergründe zu Syntax, Semantik, Prozessen und natürlich ebenfalls den englischsprachigen MASTeR-Plan.
Testen Sie Ihr Wissen doch einfach mit unseren Fragen.
Viel Spaß!
Ihre SOPHISTen