Schöner schreiben mit Schablone – Teil 3

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).

FA_Blogeintrag_schöner schreiben mit Schablonen_Bild 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.

FA_Blogeintrag_schöner schreiben mit Schablonen_Bild 2

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.

6 Gedanken zu „Schöner schreiben mit Schablone – Teil 3

  1. Hallo zusammen,

    ich habe ein paar Fragen zur rechtlichen Verbindlichkeit.

    Ist eine WIRD-Anforderung juristisch verbindlich? Kann diese analog zur MUSS-Anforderungen eingeklagt werden? Wird eine WIRD-Anforderung zu einer MUSS-Anforderung, wenn der Zeitpunkt der Funktionsintegration gekommen ist?

    Vielen Dank & viele Grüße
    Mattias Kulke

    • Hallo Herr Kulke,

      vielen Dank für Ihre Frage.

      Ja, eine WIRD-Anforderung ist juristisch verbindlich. Das ist eine Gemeinsamkeit mit einer MUSS-Anforderung. Der entscheidende Unterschied ist jedoch, dass eine WIRD-Anforderung als Vorbereitung für eine in der Zukunft liegende Integration einer Funktion dient. Sie ist verpflichtend in der Umsetzung zu berücksichtigen, auch wenn ihre Realisierung zunächst nicht getestet wird.

      Gern würden wir auch Ihnen unsere MASTeR Broschüre zukommen lassen. Teilen Sie uns einfach Ihre Adresse unter Heureka@sophist.de mit.

      Viele Grüße

      Kristina Schöne

  2. Hallo,

    ich habe noch eine Anmerkung zur Verwendung von MUSS / KANN / SOLL:

    Da diese Verben rechtliche Verbindlichkeit nahelegen, empfehle ich sie in öffentlichen Ausschreibungen zu vermeiden. Wenn der Anbieter nur ein einziges Muss-Kriterium nicht erfüllt, ist Schluss! Daher sollten die so vorsichtig wie möglich eingesetzt werden. Häufig braucht es dazu einige Abstimmrunden, um das wirklich final festzulegen.

    Dort formuliere ich die Anforderungen ohne diese Verben (insbesondere ohne MUSS) und lege Verbindlichkeit und Gewicht über die Art der Kritierien im Kriterienkatalog fest:
    – Auschlusskriterien (= MUSS)
    – Bewertungskriterien (= SOLL, KANN)

    Das bietet die größtmögliche Flexibilität beim Schreiben und Erstellen der Ausschreibungsunterlagen: Die Gewichtung und die Auswahl, welche Anforderungen wirklich „muss“ sind erfolgt im letzten Schritt, wenn alle Anforderungen beschrieben und formuliert sind. Denn wenn man die Verbindlichkeit nicht reinformuliert hat, kann man mit einem einfachen Kreuz in der Spalte Ausschlusskriterium aus einem Kann ein Muss machen und umgekehrt.

    Daher bin ich mit der Satzschablone auch nicht wirklich glücklich im Umfeld von öffentlichen Ausschreibungen ;-)

    • Vielen Dank für das aufmerksame Lesen unseres Beitrages!

      Die Satzschablone ist als ein Hilfsmittel, als ein Vorschlag zu verstehen. Dass sie in manchem Umfeld an ihre Grenzen stößt, ist vollkommen legitim

      Sie beschreiben eine weitere Möglichkeit, die rechtliche Verbindlichkeit festzulegen – als Attribute, das bei Ihnen in einem letzten Schritt befüllt wird. Den Vorteil dieses Vorgehens beschreiben Sie anschaulich in Ihrem Kommentar. Gleichzeitig fällt auf, dass bei diesem Vorgehen in der Anforderung selber ein „Kann“ stehen kann und in der entsprechenden Spalte das „Muss“ gesetzt ist. Ggf. kann es zu Verwirrungen kommen, welcher Wert führend ist.

      Führend zu dieser Jahreszeit sind ganz sicher unsere Wünsche zu einem frohen besinnlichem Weihnachtsfest und einem guten Rutsch ins neue Jahr.

      Viele Grüße

      Ihre SOPHISTen

  3. Hallo,

    danke für die Rückmeldung. Weitere Anmerkungen dazu:

    1. Leider wird das so wie Sie das beschreiben von Ihnen nicht gelehrt und auch in den Büchern nirgends so beschrieben. Ich höre oft als Gegenargument gegen meine Art, mit Verbindlichkeit umzugen, das würden aber die Sophisten anders lehren.

    2. Das Problem, das sie schildern, entsteht bei mir nicht, da ich jegliche Verben, die Verbindlichkeit beinhalten könnten, weglasse. Ich beschreibe das SOLL-System so, als gäbe es es bereits.

    Beispiel: „Das System hängt an jedes erstellte Dokument einen Zeitstempel an.“ Statt „Das System soll an jedes erstellte Dokument einen Zeitstemple anhängen.“

    3. Das hat noch einen weiteren Vorteil: Beim Erstellen der Systemdokumentation kann ich mir das Umformulieren sparen und viel aus der Spezifikation übernehmen.

    Viele Grüße,
    Maas

    • Hallo,

      der Fokus in unseren Veröffentlichungen ist, die Satzschablone vorzustellen. Ggf. geht der Punkt 1 da etwas unter. Was nicht heißen soll, dass es keine anderen Möglichkeiten gibt, Anforderungen zu dokumentieren.

      Es freut uns natürlich, dass sich in der Praxis unsere Satzschbalone durchgesetzt hat und in Diskussionen als Lösung herangezogen wird. Da sich in dieser Satzschablone die Erfahrungen aus vielen Jahren unterschiedlichster Berater in der den unterschiedlichsten Branchen wiederspiegeln, ist sie eine Möglichkeit, qualitativ gute Anforderungen zu schreiben.

      Die Formulierung ohne rechtliche Verbindlichkeit spart das Umformulieren. Das ist ein einigen Projekten ein Vorteil. Den Punkt, den es bei der Entscheidung für oder gegen diese Art der Formulierung zu berücksichtigen gilt, ist: Wie wird die Priorität der Anforderungen unterschieden? Müssen alle Anforderungen umgesetzt werden? Ggf. arbeiten Sie hier mit den erwähnten Attributen oder im Vorfeld sind Entscheidungen dazu getroffen wurden.

      Viele Grüße

      Ihre SOPHISTen

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert