SOPHIST WISSEN-for-free · SMART TWIN

MASTeR interaktiv – Schablonen für alle Fälle

Anforderungen schreiben leicht gemacht: Die SOPHIST-Satzschablonen zum Ausprobieren, Üben und Nachschlagen.

Cover der Broschüre MASTeR – Schablonen für alle Fälle

0 von 5 Kapiteln gelesen

Lernstrecke: Die MASTeR-Schablonen kennenlernen

MASTeR steht für Mustergültige Anforderungen – die SOPHIST Templates für Requirements. Hier lernst du alle sieben Schablonen kennen: für funktionale Anforderungen, nicht-funktionale Anforderungen und Bedingungen. Klick dich durch die Kapitel – und probier jede Schablone direkt im Baukasten aus.

Kapitel 1 Warum Schablonen? – Schöner Schreiben mit Schablone

Von den vier Haupttätigkeiten des Requirements Engineering – Ermitteln, Dokumentieren, Prüfen und Abstimmen sowie Verwalten von Anforderungen – ist besonders die Dokumentation eine Herausforderung. Eine Satzschablone sorgt dafür, dass Anforderungssätze einheitlich strukturiert sind und typische Defekte (z. B. ein fehlender Akteur) von vornherein vermieden werden.

Definition Anforderungsschablone

Eine Anforderungsschablone ist ein Bauplan, der die Struktur eines einzelnen Anforderungssatzes festlegt.

Mit den MASTeR-Schablonen wendest du implizit einige grundlegende Regeln des SOPHIST-REgelwerks an:

  • Anforderungen werden stets im Aktiv geschrieben.
  • Anforderungen werden stets als vollständige Sätze geschrieben.
  • Anforderungen bilden Prozesse mit Hilfe von Vollverben ab.
  • Für jedes Vollverb wird genau ein Anforderungssatz geschrieben.
  • Die Detaillierungsmöglichkeiten des FunktionsMASTeRs helfen bei der Analyse fehlender Informationen zum Vollverb.

Auch nach Schablone geschriebene Anforderungen sind nicht völlig frei von sprachlichen Effekten (Tilgung, Verzerrung, Generalisierung). Die Schablone ist ein Werkzeug, das hilft, viele davon zu vermeiden – sie ersetzt nicht das Mitdenken. Und: Anforderungen, die für sich alleine stehen, sind nur selten eindeutig und vollständig. Mehrdeutigkeiten lösen sich häufig erst durch weitere Anforderungen oder Glossareinträge auf.

Die MASTeR-Familie besteht aus:

  • einer Schablone für funktionale Anforderungen (FunktionsMASTeR) mit Detaillierungsmöglichkeiten,
  • drei Schablonen für nicht-funktionale Anforderungen (Eigenschafts-, Umgebungs-, ProzessMASTeR) sowie
  • drei Schablonen für Bedingungsnebensätze (Logik-, Ereignis-, ZeitraumMASTeR), die funktionale wie nicht-funktionale Anforderungen ergänzen können.
Kapitel 2 Welche Schablone brauche ich? – die Entscheidungshilfe

Beantworte ein paar kurze Fragen – und du landest bei der passenden MASTeR-Schablone. Mit direktem Absprung in den Baukasten.

Kapitel 3 FunktionsMASTeR – funktionale Anforderungen

Definition funktionale Anforderung

„Eine funktionale Anforderung ist eine Anforderung bezüglich eines Ergebnisses oder eines Verhaltens, das von einer Funktion eines Systems bereitgestellt werden soll.“ [Pohl11]

So ist der FunktionsMASTeR aufgebaut – klick auf die Positionen, um mehr zu erfahren:

[<Bedingung>]
<Betrachtungs­gegenstand>
MUSS
SOLLTE
WIRD
– (selbsttätig)
<wem?|was?> DIE MÖGLICHKEIT BIETEN
FÄHIG SEIN
<Objekt>
<Verb>
Schritt 5 – Die Bedingung (optional): Bestimmte Funktionen stellt ein System erst unter einer oder mehreren Bedingungen zur Verfügung. Die Bedingung eröffnet als Nebensatz den Satz; nach dem Komma folgt die rechtliche Verbindlichkeit, dann der Betrachtungsgegenstand. Formulierungsvorschläge liefert der BedingungsMASTeR (Kapitel 5).
Gegeben – Der Betrachtungsgegenstand: Nenne das zu betrachtende System beim Namen. Das gibt allen Lesenden deiner Spezifikation eine Lese- und Verständnishilfe mit auf den Weg. Der Betrachtungsgegenstand kann das ganze System oder auch nur ein Teil davon sein.
Schritt 1 – Die rechtliche Verbindlichkeit:
• MUSS: verpflichtend in der Umsetzung. Die Abnahme kann verweigert werden, wenn das System einer MUSS-Anforderung nicht entspricht.
• SOLLTE: ein Wunsch von Stakeholder*innen – nicht verpflichtend, aber die Umsetzung erhöht die Zufriedenheit.
• WIRD: dokumentiert die Absicht von Stakeholder*innen und bereitet eine zukünftige Integration einer Funktion vor. In der Umsetzung zu berücksichtigen, auch wenn die Realisierung zunächst nicht getestet wird.
Tipp: Halte die Bedeutung der Schlüsselwörter im Glossar deiner Spezifikation fest.
Schritt 3 – Die Art der Funktionalität:
• Selbsttätige Systemaktivität (leerer Pfad): Das System startet eine Funktion automatisch und führt sie automatisch aus – ohne Benutzer*in. „Die Wetterstation muss Temperaturinformationen archivieren.“
• Benutzerinteraktion (<wem?|was?> DIE MÖGLICHKEIT BIETEN): Das System stellt einem*einer Benutzer*in eine Funktionalität zur Verfügung. Verb im Infinitiv mit ZU. „Das System muss dem Benutzer die Möglichkeit bieten, Rezepte zu ordnen.“
• Schnittstellenanforderung (FÄHIG SEIN): Der Betrachtungsgegenstand führt eine Funktion nur in Abhängigkeit der Informationsübergabe durch einen Dritten aus (Nachbar- oder Fremdsystem, nicht Benutzer*in). Verb im Infinitiv mit ZU.
Lässt sich eine Anforderung mehreren Funktionsarten zuordnen, such das Gespräch mit den relevanten Stakeholder*innen und kläre die Semantik.
Schritt 4 – Das Objekt: Objekte sind fachlich wertvolle Begriffe im Kontext des betrachteten Gegenstandes. Welches Objekt Sinn ergibt, hängt stark vom Vollverb ab. Objektkandidaten: greifbare Objekte (Fließband, Temperatursensor), Rollen (Pilot, Käufer), zusammenfassende Objekte (Steuerprogramm, Rezept), Vorgänge (Anruf, Verkauf).
Schritt 2 – Das Verb (Prozesswort): Der Anforderungssatz endet mit einem Verb im Infinitiv – dem semantischen Kern der Anforderung. Es nennt die geforderte Funktion des Systems. Tipp: Leg am Projektanfang eine Liste definierter Vollverben an (z. B. archivieren, auswählen, berechnen) – das schafft gemeinsames Verständnis.

▲ Klick auf eine Position der Schablone, um die Erklärung zu öffnen.

Die Wetterstation muss Temperaturinformationen archivieren.

Das System muss dem Benutzer die Möglichkeit bieten, Rezepte zu ordnen.

Sobald das Ereignis Geburtstag eintritt, muss das System dem Benutzer einen Kalendereintrag anzeigen.

Falls der Benutzer einen Termin eingibt, muss das System dem Benutzer die Möglichkeit bieten, den Termin zu speichern.

Detaillierter FunktionsMASTeR

Der detaillierte FunktionsMASTeR ist keine eigenständige Schablone – er zeigt, wie sich die letzten beiden Positionen semantisch ausführlicher beschreiben lassen:

Präzisierung des Objekts

  • welche/r/s? ergänzt das Objekt um eine Eigenschaft oder einen Zustand – vorangestellt (die selektierten Kundendaten).
  • wessen? konkretisiert die Rolle oder den Akteur, für den das Objekt gilt – nachgestellt (Kundendaten eines registrierten Kunden).

Konkretisierung des Verbs

  • wann? – der Zeitpunkt, zu dem ein Prozess gestartet wird oder verfügbar sein soll.
  • wo? – der Betrachtungsgegenstand bzw. Standort, an dem ein Prozess durchgeführt wird.
  • wohin? – Fremd- oder Nachbarsysteme, mit denen das System interagiert.
  • woher? – Fremd- oder Nachbarsysteme, die mit dem System agieren.

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

Warum fehlt das „wie“? Das Fragewort wie wurde bewusst nicht aufgenommen: Es würde meist nicht-funktionale Anteile in den FunktionsMASTeR integrieren. Halte funktionale und nicht-funktionale Anforderungen getrennt – z. B. in unterschiedlichen Kapiteln deines Anforderungsdokuments.

Englische Version: FunctionalMASTER

Den FunctionalMASTER gibt es als klickbare Schablone im Reiter English MASTeR – zusammen mit den englischen Versionen aller anderen Schablonen.

Kapitel 4 Nicht-funktionale Anforderungen – Eigenschafts-, Umgebungs- und ProzessMASTeR

Die Funktionen eines Systems stehen oft im Mittelpunkt – doch nicht-funktionale Anforderungen gehören in jede Spezifikation, denn sie haben großen Einfluss auf Realisierungsmöglichkeiten und Akzeptanz eines Systems. Wegen ihrer Vielfalt gibt es nicht eine, sondern drei Schablonen.

Die sechs Kategorien nicht-funktionaler Anforderungen

Technologische AnforderungenDirekter Einfluss auf die zu verwendenden Technologien. Subkategorien: Systemumwelt (Temperatur, Feuchtigkeit, Stromversorgung …), Mengengerüst (Benutzeranzahl, Speicherplatz …), Schnittstellen (mechanisch oder softwarespezifisch), Vorgaben an Komponenten.

QualitätsanforderungenAngaben über die Güte des Produkts, des Prozesses oder der beteiligten Personen: Änderbarkeit, Benutzbarkeit, Effizienz, Funktionalität, Übertragbarkeit, Zuverlässigkeit.

BenutzungsoberflächeVisuelles, akustisches oder haptisches Erscheinen und Bedienung des Systems: Bedienkonzepte, Rahmenbedingungen für die Gestaltung, Bedienelemente.

Sonstige LieferbestandteileAlles, was während der Entwicklung mit erstellt werden muss: Handbücher, Dokumentationen, Schulungsunterlagen, Installationssoftware, Montagewerkzeuge.

Durchzuführende TätigkeitenProjektprozesse: wie das Produkt zu entwickeln, einzuführen oder zu betreiben ist – meist im Projekthandbuch oder in Vereinbarungen dokumentiert.

Rechtlich-vertragliche AnforderungenVereinbarte Rechte und Pflichten zu Entwicklung und Verwendung des Produkts: Anforderungen an den Auftragnehmer, Kosten, Angebotsprozess, rechtliche und Übereinstimmungsanforderungen.

Welche Schablone für welche Kategorie?

KategorieEigenschaftsMASTeRUmgebungsMASTeRProzessMASTeR
Qualitätsanforderungen✕
Technologische Anforderungen✕Umgebung, Mengengerüst
Benutzungsoberfläche✕
Sonstige Lieferbestandteile✕
Durchzuführende Tätigkeiten✕✕
Rechtlich-vertragliche Anforderungen✕✕

Der Quasi-Alles-Könner ist der EigenschaftsMASTeR. Für Umgebungs- und Mengengerüstanforderungen gibt es den UmgebungsMASTeR trotzdem – die Anforderungen klingen mit ihm einfach besser.

EigenschaftsMASTeR

[<Bedingung>]
<Betrachtungs­gegenstand>
MUSS
SOLLTE
WIRD
<Eigenschaft>
[<Vergleichs­ausdruck>]
<Wert>
<Verb>
Bedingung (optional): Auch nicht-funktionale Anforderungen können an Bedingungen geknüpft sein – Formulierungsvorschläge liefert der BedingungsMASTeR.
Eigenschaft und Betrachtungsgegenstand: Die Anforderung beginnt mit einer Eigenschaft eines Betrachtungsgegenstandes – einem bestimmten Merkmal, das zu ihm gehört. Drei Fragen helfen beim Eingrenzen: Welcher Teil des Systems ist gerade mein Fokus? An welche Eigenschaft habe ich Erwartungen? In welcher Qualität soll eine Funktion realisiert werden?
Rechtliche Verbindlichkeit: MUSS = verpflichtend, SOLLTE = Wunsch, WIRD = Absicht der Stakeholder*innen (vgl. FunktionsMASTeR, Schritt 1).
Eigenschaft: Ein bestimmtes Merkmal des Betrachtungsgegenstandes, z. B. Gewicht, Farbe, Dateiformat, Dauer, Erreichbarkeit.
Vergleichsausdruck (fakultativ): z. B. mindestens, maximal, kleiner gleich, größer (als). Mit Vergleichsausdruck und Wert wird die Eigenschaft mess- und testbar.
Wert (obligatorisch): Ein Zahlenwert mit semantisch passender Einheit (Zeit, Gewicht, Längenmaß …) oder eine Wortgruppe, die einen Wert repräsentiert (weiß, PDF in der Version 1.5). Gesteigerte Adjektive wie schnell oder besser ohne Eingrenzung sind nicht testbar.
Verb: Die Anforderung endet mit einem Vollverb – meist sein. Funktionsverben wie drucken oder rechnen sind hier unangebracht: Funktionen beschreibt der FunktionsMASTeR.

▲ Klick auf eine Position der Schablone, um die Erklärung zu öffnen.

Das Gewicht des Smartphone muss kleiner gleich 100g sein.

Die Farbe des Gehäuses des Smartphones muss weiß sein.

Das Dateiformat des Monatsreports muss PDF in der Version 1.5 sein.

Die Dauer des Einschaltvorgangs des Fernsehers muss in 40 % der Fälle maximal fünf Sekunden sein.

UmgebungsMASTeR

[<Bedingung>]
<Betrachtungs­gegenstand>
MUSS
SOLLTE
WIRD
<Umgebungs­einfluss>
[<Vergleichs­ausdruck>]
<Wert>
<Verb(-gruppe)>
Bedingung (optional): Beim UmgebungsMASTeR steht die Bedingung im Satzmittelfeld – die Positionen der Schablone ändern sich mit einer Bedingung nicht.
Betrachtungsgegenstand: Auch einzelne Komponenten sind möglich (Smartphone – Akku, Display – LCD). Achtung: Die Umgebung kann sich je nach Betrachtungsgegenstand ändern – eine einzelne Komponente hat unter Umständen andere Umgebungseinflüsse als das Gesamtsystem.
Rechtliche Verbindlichkeit: MUSS = verpflichtend, SOLLTE = Wunsch, WIRD = Absicht (vgl. FunktionsMASTeR, Schritt 1).
Umgebungseinfluss: Aspekte, die von außerhalb auf den Betrachtungsgegenstand einwirken – oft elektrische, mechanische, chemische oder klimatische Einflüsse. Wichtig: Die Anforderung wird an das System gestellt, nicht an die Umgebung! „Die Umgebungstemperatur des Smartphones muss -20 bis 60°C sein“ setzt den Fokus falsch.
Vergleichsausdruck (fakultativ): z. B. von … bis (streng genommen zwei Vergleichsausdrücke: größer gleich und kleiner gleich).
Wert (obligatorisch): Präzise Zahlenwerte (-20°C, 60°C) sind ein eindeutiger Hinweis für Tester. „Bei einer niedrigen Umgebungstemperatur“ ist zu ungenau und nicht testbar.
Verb(-gruppe): Beschreibt, in welchem Lebenszyklus des Betrachtungsgegenstandes der Umgebungseinfluss einwirkt: Herstellung, Betrieb, Reinigung, Transport, Installation … (z. B. „betrieben werden können“, „gereinigt werden können“).

▲ Klick auf eine Position der Schablone, um die Erklärung zu öffnen.

Die Außenhülle des Smartphones muss so gestaltet sein, dass das Smartphone bei einer Umgebungstemperatur von -20°C bis 60°C betrieben werden kann.

Die Oberfläche des Systems muss mit Reinigungsbenzin gereinigt werden können.

Das System muss bei einer Spannung von 220 Volt – 10 Volt betrieben werden können.

ProzessMASTeR

[<Bedingung>]
<Akteur>
MUSS
SOLLTE
WIRD
<Objekt>
<Verb>
Bedingung (optional): Auch hier kann optional ein Bedingungsnebensatz vorangestellt werden.
Akteur: Der entscheidende Unterschied zu allen anderen MASTeR-Schablonen: Die Anforderung wird an einen Akteur gestellt, nicht an einen Betrachtungsgegenstand – z. B. an den*die Auftragnehmer*in, den Lieferanten oder die Marketingabteilung. Die Angabe des Betrachtungsgegenstands ist fakultativ und fällt unter die Präzisierung des Objekts.
Rechtliche Verbindlichkeit: MUSS = verpflichtend, SOLLTE = Wunsch, WIRD = Absicht (vgl. FunktionsMASTeR, Schritt 1).
Objekt und Präzisierung: Fachlich wertvolle Begriffe im Kontext des Betrachtungsgegenstandes. Präzisierung nach dem Objekt per Ergänzung mit Präposition (für den MP3-Player) oder vor dem Objekt per Attribut (englisches).
Prozesswort und Konkretisierung: Prozesswörter wie erstellen oder prüfen sind Träger der Bedeutung. Ihre Konkretisierung (z. B. einmal im Quartal) wirkt – wie eine Prozesswortliste – einer Fehlinterpretation entgegen.

▲ Klick auf eine Position der Schablone, um die Erklärung zu öffnen.

Der Auftragnehmer muss ein Betriebshandbuch für den MP3-Player erstellen.

Der Lieferant sollte gelagerte Ersatzteile jährlich im Juni prüfen.

Die Marketingabteilung muss einen Produktkatalog in Farbe erstellen.

Englische Versionen

PropertyMASTER, EnvironmentMASTER und ProcessMASTER findest du als klickbare Schablonen im Reiter English MASTeR.

Kapitel 5 BedingungsMASTeR – Schluss mit dem mehrdeutigen WENN

In einer Spezifikation solltest du eindeutig dokumentieren, unter welchen Voraussetzungen eine Funktion überhaupt bereitgestellt wird. Das Problem: Die in der Projektwelt sehr gern verwendete Konjunktion WENN hat laut Duden fünf verschiedene Bedeutungen – von „falls“ über „sobald“ bis „obwohl“. Diese Mehrdeutigkeit ist eine häufig unterschätzte Ursache für Fehlentwicklungen und lästigen Interpretationsspielraum beim Testen.

Wenn das Smartphone inaktiv ist, muss der Stromverbrauch des Smartphones kleiner als 50 % sein. – Was genau soll hier getestet werden? Der Moment des Zustandswechsels? Der gesamte Zeitraum?

Der BedingungsMASTeR ersetzt WENN durch drei eindeutige Konjunktionen:

FALLS → LogikMASTeRLeitet eine logische Aussage ein. Umschreibungen: für den Fall / unter der Voraussetzung, dass. Zeitform: Präsens – die logische Aussage kann nicht in der Vergangenheit stehen.

SOBALD → EreignisMASTeREin Ereignis ist die Bedingung. Synonym zu: in dem Augenblick, sofort, sowie – rückt den Zeitpunkt in den Vordergrund. Drückt Ungleichzeitigkeit aus: Erst wenn die Bedingung beendet ist, gilt der Hauptsatz. Empfohlene Zeitform: Perfekt.

SOLANGE → ZeitraumMASTeRReferiert auf einen Zeitraum (Synonym: währenddessen). Drückt Gleichzeitigkeit aus: Bedingung und Anforderungshauptsatz laufen gleichzeitig ab und enden gleichzeitig.

Bei einem Bedingungsnebensatz ändert sich die Satzstellung im Hauptsatz: Auf den Nebensatz folgt direkt das Modal- oder Hilfsverb (MUSS/SOLLTE/WIRD), dann der Betrachtungsgegenstand. Ausnahme UmgebungsMASTeR: Hier wird die Bedingung ins Satzmittelfeld eingeschoben.

LogikMASTeR – FALLS <logische Aussage>

So ist der LogikMASTeR aufgebaut – klick auf die Positionen, um mehr zu erfahren:

FALLS
<Vergleichs­gegenstand>
<Akteur>
<Betrachtungs­gegenstand>
<Vergleichs­ausdruck> <Wert>
DIE FUNKTION <Funktion>
<Objekt>
IST
<Verb>
FALLS – die logische Aussage: Leitet eine logische Aussage ein. Umschreibungen laut Duden: „für den Fall, dass“, „unter der Voraussetzung, dass“, „unter der Bedingung, dass“. Zeitform: Präsens – die logische Aussage kann nicht in der Vergangenheit stehen. Triffst du auf eine FALLS-Bedingung in einer anderen Zeitform, hinterfrag sie, um eine Bedeutungsverschiebung zu vermeiden.
Vergleichsgegenstand, Akteur oder Betrachtungsgegenstand: Die logische Aussage kann über einen Vergleichsgegenstand, einen Akteur oder einen Betrachtungsgegenstand getroffen werden. Diese Satzposition ist im jeweiligen Pfad obligatorisch zu besetzen. Falls die Anzahl der entliehenen Leihobjekte größer 10 ist, …
Vergleichsausdruck und Wert (Vergleichspfad): Machen die Bedingung konkret und testbar – weg von schwammigen Adjektiven wie schnell oder intuitiv. Neben Zeit- oder Zähleinheiten sind auch natürlichsprachlich beschriebene Werte möglich. Dieser Pfad endet auf IST.
DIE FUNKTION <Funktion>: Dieser Pfad setzt voraus, dass die Funktionen des Systems bereits ermittelt sind. Gängige Prozesswörter danach: starten, aktivieren, ausführen, beenden. Falls der Bibliothekar die Funktion Leihobjekt suchen verwendet, …
<Objekt>: Objekte sind fachlich wertvolle Begriffe im Kontext des betrachteten Gegenstandes. Falls der Rezeptionist eine Buchung löscht, …
IST / <Verb>: Der Vergleichspfad endet auf IST. In den Pfaden über Akteur oder Betrachtungsgegenstand benennt das Verb als wichtigste semantische Einheit die Funktion bzw. Eigenschaft, an die die Bedingung geknüpft ist.

▲ Klick auf eine Position. Die Pfade lesen sich zeilenweise: oben der Vergleichspfad (endet auf IST), darunter die Pfade über Akteur bzw. Betrachtungsgegenstand (enden auf dem <Verb>).

Falls die Anzahl der entliehenen Leihobjekte größer 10 ist, …

Falls der Bibliothekskunde das Leihobjekt reserviert, …

Falls der Bibliothekar die Funktion Leihobjekt suchen verwendet, …

Falls das Bibliothekssystem das Leihobjekt nicht identifiziert, …

EreignisMASTeR – SOBALD <Ereignis>

So ist der EreignisMASTeR aufgebaut – klick auf die Positionen, um mehr zu erfahren:

SOBALD
DAS EREIGNIS <Ereignis>
<Akteur>
<Betrachtungs­gegenstand>
EINTRITT
DIE FUNKTION <Funktion>
<Objekt>
<Verb>
SOBALD – das Ereignis als Bedingung: Synonym zu „in dem Augenblick“, „sofort“, „sowie“ – rückt den Zeitpunkt, zu dem ein Ereignis eintritt, in den Vordergrund. Drückt Ungleichzeitigkeit aus: Erst wenn die Bedingung beendet ist, beginnt bzw. gilt das funktionale oder nicht-funktionale Verhalten im Hauptsatz.
DAS EREIGNIS <Ereignis> EINTRITT: Der namensgebende Pfad. Ereignisse sind systemrelevante Vorgänge oder Geschehnisse mit Einfluss auf den Betrachtungsgegenstand – z. B. Einschalten, Ausschalten, Update, Erschütterung. Sobald das Ereignis Einschalten eintritt, …
Akteur / Betrachtungsgegenstand: Alternativ wird die Bedingung über einen Akteur oder einen Betrachtungsgegenstand formuliert. Sobald der Bibliothekar alle Kundendaten eingegeben hat, …
DIE FUNKTION <Funktion> / <Objekt>: Wie beim LogikMASTeR: entweder über eine bereits ermittelte Funktion oder über ein Objekt mit Verb. Sobald der Bibliothekar die Funktion Kunde registrieren aufgerufen hat, …
<Verb> – im Perfekt: Empfohlene Zeitform ist das Perfekt („eingegeben hat“, „empfangen hat“) – sie unterstreicht die zeitliche Ungleichheit von Neben- und Hauptsatz. Im Ereignis-Pfad entfällt diese Position: EINTRITT übernimmt die Verbrolle.

▲ Klick auf eine Position. Oberer Pfad: DAS EREIGNIS <Ereignis> EINTRITT – die unteren Pfade enden auf einem <Verb> im Perfekt.

Sobald das Ereignis Einschalten eintritt, …

Sobald der Bibliothekar alle Kundendaten eingegeben hat, …

Sobald das Bibliothekssystem die Kundendaten vom benachbarten Bibliothekssystem empfangen hat, …

ZeitraumMASTeR – SOLANGE <Zeitraum>

So ist der ZeitraumMASTeR aufgebaut – klick auf die Positionen, um mehr zu erfahren:

SOLANGE
<Objekt>
<Betrachtungs­gegenstand>
<Akteur>
IM ZUSTAND <Zustand>
DIE FUNKTION <Funktion>
<Objekt>
BEFINDET
<Verb>
SOLANGE – der Zeitraum als Bedingung: Referiert auf einen Zeitraum (Synonym: währenddessen). Drückt Gleichzeitigkeit aus: Bedingungsnebensatz und Anforderungshauptsatz laufen gleichzeitig ab und enden gleichzeitig.
Objekt, Betrachtungsgegenstand oder Akteur: Der Zeitraum kann über ein Objekt, einen Betrachtungsgegenstand oder einen Akteur formuliert werden. Beim Zustandspfad mit reflexivem „sich“: Solange sich ein Leihobjekt im Zustand Reserviert befindet, …
IM ZUSTAND <Zustand>: Der wichtigste Pfad. Systeme und Objekte befinden sich für bestimmte Zeitabschnitte in bestimmten Verfassungen – z. B. Ruhezustand, Energie sparen, Flugmodus. Verschiedenes Verhalten in verschiedenen Zuständen ist z. B. für die Energieeffizienz entscheidend.
DIE FUNKTION <Funktion> / <Objekt>: Alternativ über eine bereits ermittelte Funktion oder ein Objekt mit Verb. Solange der Administrator den Namen eines neuen Mitarbeiters aufruft, …
BEFINDET / <Verb>: Der Zustandspfad endet auf BEFINDET, die anderen Pfade auf einem Verb – im Präsens, denn Bedingung und Hauptsatz laufen gleichzeitig ab.

▲ Klick auf eine Position. Oberer Pfad: IM ZUSTAND <Zustand> BEFINDET – die unteren Pfade enden auf einem <Verb>.

Solange sich ein Leihobjekt im Zustand Reserviert befindet, …

Solange sich das Smartphone im Zustand Inaktiv befindet, …

Solange das Bibliothekssystem die Funktion Verbindung zum benachbarten Bibliothekssystem herstellen ausführt, …

Merke: Alle Positionen können gleich sein – und die Bedingung unterscheidet sich lediglich in der Konjunktion. Das Schreiben nach Schablone ist kein stumpfsinniges Bestücken: Die gewissenhafte Auseinandersetzung mit den Inhalten einer Anforderung ist unerlässlich.

Englische Version: ConditionMASTER

LogicMASTER (IF), EventMASTER (AS SOON AS) und TimeMASTER (AS LONG AS) findest du als klickbare Schablonen im Reiter English MASTeR.

Bereit für den nächsten Schritt?

Probier dein Wissen direkt aus: Bau deine erste Anforderung im Schablonen-Baukasten, finde mit der Entscheidungshilfe die passende Schablone – oder teste dich im Trainer.

Schablonen-Baukasten: Bau deine Anforderung

Wähle eine Schablone, füll die Positionen aus – und dein Anforderungssatz entsteht live. Zum Schluss kannst du ihn mit einem Klick kopieren.

Trainer: Teste dein MASTeR-Wissen

12 Übungsaufgaben rund um Schablonen, Schlüsselwörter und Bedingungen – mit sofortigem Feedback und Erklärung. Die Fragen kommen bei jedem Durchlauf in neuer Reihenfolge.

English MASTeR: All seven templates at a glance

The official English counterparts of the MASTeR templates – a quick reference for writing specifications in English, not a second learning track. Click any position for a short explanation. For the full background, head over to the Lernstrecke. The translations transfer the semantics of the German templates rather than translating word by word.

FunctionalMASTER – functional requirements

[<condition>]
<subject matter>
SHALL
SHOULD
WILL
– (autonomous)
PROVIDE <whom?|what?> WITH THE ABILITY TO
BE ABLE TO
<verb>
<object>
[<condition>] (optional): A requirement may start with a conditional clause. Use the ConditionMASTER templates below (IF, AS SOON AS, AS LONG AS).
<subject matter>: Name the system – or the part of it – the requirement is about.
Legal obligation: SHALL = mandatory, SHOULD = stakeholder wish, WILL = intention for the future. SHALL, SHOULD and WILL are recommended by SOPHIST and the IREB e.V.
Type of functionality: Empty path = autonomous system activity. PROVIDE <whom?|what?> WITH THE ABILITY TO = user interaction. BE ABLE TO = interface requirement (interaction with a third system).
<verb>: The process verb naming the required function. Note the word order: unlike German, the verb comes before the object in English.
<object>: A term that carries value in the domain of the subject matter.

The system shall design postcards.

The system should provide the user with the ability to search items.

The system will provide the user with the ability to print selected colored photos at the network printer.

PropertyMASTER – EigenschaftsMASTeR

[<condition>]
<subject matter>
SHALL
SHOULD
WILL
<verb>
<property>
[<comparison operator>]
<value>
[<condition>] (optional): Non-functional requirements can be bound to a condition, too.
<subject matter>: The system or component whose property you constrain.
Legal obligation: SHALL = mandatory, SHOULD = stakeholder wish, WILL = intention for the future.
<verb>: Usually be – functional verbs belong in the FunctionalMASTER.
<property>: A specific characteristic of the subject matter, e.g. weight, color, file format, duration.
[<comparison operator>] <value>: Make the property measurable and testable – e.g. at least, no more than plus a value with a fitting unit. Vague adjectives like fast are not testable.

EnvironmentMASTER – UmgebungsMASTeR

[<condition>]
<subject matter>
SHALL
SHOULD
WILL
<verb (group)>
<environmental effect>
[<comparison expression>]
<value>
[<condition>] (optional): A condition can be added without changing the other positions.
<subject matter>: The whole system or a single component. Note: a component may face different environmental effects than the overall system.
Legal obligation: SHALL = mandatory, SHOULD = stakeholder wish, WILL = intention for the future.
<verb (group)>: Describes the life-cycle phase in which the effect applies, e.g. be operated, be cleaned, be transported.
<environmental effect>: An influence acting on the subject matter from outside – often electrical, mechanical, chemical or climatic. The requirement is put on the system, not on its environment.
[<comparison expression>] <value>: Precise values (e.g. -20 °C to 60 °C) give testers an unambiguous target.

ProcessMASTER – ProzessMASTeR

[<condition>]
<actor>
SHALL
SHOULD
WILL
<verb>
<object>
[<condition>] (optional): A conditional clause may precede the requirement.
<actor>: The key difference to all other MASTeR templates: the requirement addresses an actor – e.g. the contractor, a supplier, the marketing department – not a subject matter.
Legal obligation: SHALL = mandatory, SHOULD = stakeholder wish, WILL = intention for the future.
<verb>: The process verb carrying the meaning, e.g. create, check, deliver.
<object>: A domain term, optionally refined – e.g. an operating manual for the MP3 player.

LogicMASTER – IF <logical expression>

IF
<compared object>
<subject matter>
<actor>
IS
<verb>
<qualifying expression> <value>
<object>
THE FUNCTION <function>
IF – the logical expression: Introduces a logical statement as a condition. Tense: present – a logical expression cannot lie in the past.
<compared object>, <subject matter> or <actor>: The logical expression can be made about a compared object (comparison path, ends with a qualifying expression and value), a subject matter or an actor.
IS / <verb>: The comparison path uses IS; the other paths use a verb – which, in English, comes before the object.
<qualifying expression> <value> / <object> / THE FUNCTION <function>: The comparison path ends with a qualifying expression and a value; the other paths continue with an object or a previously identified function.

▲ Read the paths row by row: top row = comparison path, below it the subject-matter and actor paths.

If the number of borrowed items is greater than 10, …

EventMASTER – AS SOON AS <event>

AS SOON AS
THE EVENT <event>
<actor>
<subject matter>
HAPPENS
<process verb>
<object>
THE FUNCTION <function>
AS SOON AS – the event as condition: Puts the point in time into focus and expresses non-simultaneity: only after the condition has finished does the main clause apply. Recommended tense: present perfect (has entered, has received).
THE EVENT <event> HAPPENS: The name-giving path. Events are system-relevant occurrences such as switch-on, switch-off, update. This path ends with HAPPENS.
<actor> / <subject matter>: Alternatively, the condition is expressed via an actor or a subject matter.
<process verb>: In present perfect, underlining that condition and main clause do not run simultaneously.
<object> / THE FUNCTION <function>: The actor and subject-matter paths continue with an object or a previously identified function.

▲ Top path: THE EVENT <event> HAPPENS – the lower paths use a process verb in present perfect.

As soon as the event switch-on happens, …

As soon as the librarian has entered all customer data, …

TimeMASTER – AS LONG AS <time period>

AS LONG AS
THE/AN <object>
<subject matter>
<actor>
IS
<process verb>
IN THE STATE <state>
THE FUNCTION <function>
<object>
AS LONG AS – the time period as condition: Refers to a period of time and expresses simultaneity: condition and main clause run – and end – at the same time.
THE/AN <object>, <subject matter> or <actor>: The time period can be expressed via an object, a subject matter or an actor.
IS / <process verb>: The state path uses IS; the other paths use a process verb in present tense.
IN THE STATE <state> / THE FUNCTION <function> / <object>: The most important path: systems and objects stay in a state (e.g. sleep mode, flight mode) for a limited period. The other paths continue with a function or an object.

▲ Top path: THE/AN <object> IS IN THE STATE <state> – the lower paths use a process verb.

As long as an item is in the state reserved, …

Want the full method?

The complete brochure “MASTeR – Schablonen für alle Fälle” (German) is available for free at SOPHIST WISSEN-for-free – for English RE fundamentals, see The RE-Primer.

Quelle: „MASTeR – Schablonen für alle Fälle“, 6. Auflage 2024, © SOPHIST GmbH, Nürnberg. Dieser SMART TWIN basiert auf der WISSEN-for-free-Broschüre.

Die komplette Broschüre gibt es kostenfrei unter sophist.de · Kontakt: vertrieb@sophist.de · www.sophist.de

Nach oben scrollen