Mit der SOPHIST-Satzschablone wurde eifrigen Anforderungsschreibern vor über zehn Jahren ein Werkzeug in die Hand gegeben, mit dem Sie Anforderungssätze einheitlich strukturiert und sprachliche Defekte, wie z. B. das Fehlen des Akteurs, von vorherein vermeiden können.

Nun sind zehn Jahre eine lange Zeit und auch eine Satzschablone ist von Alterserscheinungen nicht befreit. Daher stellen wir Ihnen an dieser Stelle die überarbeitete, reifer gewordene, aber auf keinem Fall aus der Mode gekommene Satzschablone für funktionale Anforderungen vor (vgl. Abb. 1).

Abbildung 1: FunktionsMASTeR

Die Schablone in Abbildung 2, der FunktionsMASTeR, ist im Rahmen unseres Innovationsprojekts MASTeR neben Schablonen für nicht-funktionale Anforderungen und Schablonen für Bedingungen, die sowohl funktionale als auch nicht-funktionale Anforderungen ergänzen können, entstanden. Zu den nicht-funktionalen MASTeR-Schablonen informieren bereits zwei Blogeinträge.

Mit diesem Blogeintrag möchten wir Ihnen Hintergrundwissen zu den einzelnen Positionen des FunktionsMASTeR vermitteln, damit Sie ihn als Werkzeug zum Schreiben von Anforderungen richtig einsetzen können. Wem die Ausführungen an dieser Stelle etwas zu kurz sind, der sei auf unsere Broschüre MASTeR verwiesen, die voraussichtlich im November dieses Jahres erscheinen wird. Außerdem werden wir an dieser Stelle weitere Blogeinträge zu den MASTeR-Bedingungsschablonen veröffentlichen.

Schauen wir uns die verschiedenen Satzpositionen des FunktionsMASTeRs näher an:

System

So einfach es auch scheinen mag – nennen Sie das zu betrachtende System beim Namen. Sie geben dem Leser Ihrer Spezifikation auf diese einfache Art und Weise eine Lese- und Verständnishilfe mit auf den Weg.

Rechtliche Verbindlichkeit

Wie auch die Meinungen zum älter werden im Allgemeinen, gehen auch die Meinungen über ein und dieselbe Anforderung in der RE Praxis weit (und manchmal noch weiter) auseinander. Gerade im Zusammenhang mit Verträgen ist jedoch eine einheitliche Gewichtung aller Anforderungen von entscheidender Bedeutung. Ist die rechtliche Verbindlichkeit festgelegt, kann eine Anforderung bei Nichtumsetzung auch eingeklagt werden.

Wir schließen uns dem IREB (International Requirements Engineering Board) an, der folgende drei Schlüsselwörter zu benutzen empfiehlt: muss, sollte und wird.

• Alle Anforderungen, die mit MUSS formuliert sind, sind verpflichtend in der Umsetzung. Die Abnahme eines Produkts kann verweigert werden, sollte das System einer MUSS-Anforderung nicht entsprechen.
• Formulierungen mit SOLLTE stellen einen Wunsch eines Stakeholders dar. Sie sind nicht verpflichtend und müssen nicht erfüllt werden. Allerdings erhöht ihre Umsetzung die Zufriedenheit der Stakeholder und ihre Dokumentation verbessert die Zusammenarbeit und Kommunikation zwischen Stakeholdern und Entwicklern.
• Mit WIRD dokumentieren Sie die Absicht eines Stakeholders. Eine mit WIRD formulierte Anforderung dient als Vorbereitung für eine in der Zukunft liegende Integration einer Funktion. Sie ist verpflichtend in der Umsetzung, auch wenn ihre Realisierung zunächst nicht getestet wird.

Die beste Empfehlung nutzt aber nichts, wenn Sie sich mit den beteiligten Stakeholdern nicht einig sind oder die vereinbarten Definitionen wie ein gut gehütetes Geheimnis für sich behalten. Halten Sie Ihre Schlüsselwörter für die rechtliche Verbindlichkeit in einem Glossar fest, dass für alle Beteiligten einsehbar ist.

Art der Funktion

Mit der nächsten Satzposition entscheiden Sie, um welche Art der Funktion es sich bei der Anforderung handelt:

• Selbsttätige Systemaktivität: Selbst ist das System! Ein System startet eine Funktion automatisch und führt sie anschließend automatisch aus. Diese Anforderungen formulieren Sie mit der entsprechenden rechtlichen Verbindlichkeit (Modalverben MUSS, SOLLTE oder Hilfsverb WIRD) und einem Prozesswort im Infinitiv. Das Prozesswort bildet die Funktion des Systems ab, die es selbsttätig durchführt. Ein Benutzer tritt dabei nicht in Erscheinung.
• Benutzerinterkation: Das System stellt seinem Benutzer eine Funktion zur Verfügung oder es tritt mit ihm in Interaktion (das kann z. B. in Form einer Datenausgabe oder Auswahlmaske geschehen). Für diese Interaktion zwischen System und Benutzer wählen Sie die Formulierung <Rolle> DIE MÖGLICHKEIT BIETEN und ein Prozesswort im Infinitiv mit zu. Hinter Rolle verbirgt sich ein mit dem System interagierender Benutzer.
• Schnittstellenanforderungen: Mit Anforderungen an Schnittstellen wird der Fall abgedeckt, dass ein System eine Funktion nur in Anhängigkeit der Informationseingabe durch einen Dritten, der nicht der Benutzer ist, ausführen kann. Das kann ein Nachbar- oder Fremdsystem sein. Die Übergabe der Informationen kann in unregelmäßigen Abständen erfolgen und unvorhersehbar sein. Formulieren Sie diese Anforderungen mit FÄHIG SEIN und einem Prozesswort im Infinitiv mit zu.

Objekt

Anschließend wird von der Satzschablone ein Objekt gefordert. Objekte sind fachlich wertvolle Begriffe im Kontext des betrachteten Gegenstandes. Unter solch einen Betrachtungsgegenstand kann Ihr System oder auch nur Teile Ihres Systems fallen. An dieser vierten Position des FunktionsMASTeR können die semantisch verschiedensten Substantive stehen (z. B. Temperatursensor, Mitarbeiter, Rezept, Verkauf usw.). Die Semantik wird dabei stark vom Prozesswort beeinflusst, d. h. welches Objekt denn überhaupt Sinn in einer Anforderung macht, ist vom Prozesswort abhängig.

Prozesswort

Charakteristisch für die deutsche Syntax und somit auch für Anforderungen, die nach FunktionsMASTeR geschrieben sind, ist die Klammer aus finitem Verb (bei uns MUSS, SOLLTE oder WIRD) und infinitem Verb (bei uns Prozesswort). So endet ein Anforderungssatz nach dem FunktionsMASTeR mit einem Prozesswort im Infinitiv. Es ist der semantische Kern der Anforderung, denn es nennt die Funktion eines Systems, wie z. B. archivieren, auswählen oder rechnen.

Nun sind Genauigkeit und Eindeutigkeit ständige Begleiter emsiger Anforderungsschreiber. Die Schablone in Abbildung 2 beinhaltet Fragewörter, die Hinweise für die Präzisierungs- bzw. Konkretisierungsmöglichkeiten der mit dem FunktionsMASTeRs formulierten Anforderung geben und Sie somit dem Ziel genauer und eindeutiger einen Schritt näher bringen.

Abbildung 2: Detaillierungsmöglichkeiten des FunktionsMASTeR

Mit dem Fragewort welche/r/s kann ein Objekt um eine Eigenschaft oder einen Zustand ergänzt werden. Diese Konkretisierung ist dem Objekt vorangestellt. Eine weitere Konkretisierung des Objekts ist mit dem Fragewort wessen möglich. Wessen konkretisiert die Rolle oder den Akteur, für den das Objekt gilt. Diese Information ist dem Objekt nachgestellt.

Das Prozesswort als semantischer Kern einer Anforderung kann mit den Antworten auf jeweils vier Fragewörter konkretisiert werden.

• Wann konkretisiert den Zeitpunkt, zu dem ein Prozess gestartet wird oder verfügbar sein soll.
• Wo konkretisiert einen Betrachtungsgegenstand und eventuell den Standort, an dem ein Prozess ausgeführt wird.
• Wohin konkretisiert Betrachtungsgegenstände (Fremd- oder Nachbarsysteme), mit dem das zu spezifizierende System interagiert.
• Woher konkretisiert Betrachtungsgegenstände (Fremd- oder Nachbarsysteme), die mit dem zu spezifizierenden System agieren.

Enden soll unser Blogeintrag nicht ohne ein Beispiel bzw. eine Einzelanforderung, in der die obigen Ausführungen berücksichtigt wurden:

Das Bibliothekssystem muss dem Bibliothekar die Möglichkeit bieten, die selektierten Kundendaten eines registrierten Kunden auf einem Drucker zu drucken.

Und wer weiß – möglicherweise hat dieser Blogeintrag doch noch nicht ganz sein Ende gefunden und in zehn weiteren Jahren haben Sie vielleicht durch Ihre Arbeit mit dem FunktionsMASTeR weitere Punkte gefunden, die eine Überarbeitung wert sind. In diesem Sinne – rasten oder rosten Sie nicht und schreiben oder erzählen Sie uns von Ihren Erfahrungen mit dem FunktionsMASTeR per E-Mail an heureka@sophist.de oder per Telefon unter 0911 40 9000.

Hier finden Sie den zweiten Teil dieser Blogserie.