Management-Zusammenfassung dieses Beitrags:
Satzschablonen sind ein Hilfsmittel, um Einzelanforderungen so zu strukturieren und zu formulieren, dass sie eine hohe → Qualität aufweisen.
In diesem Beitrag werden Satzschablonen und deren Einsatz im → Requirements Engineering beschrieben.
Satzschablonen (auch Anforderungsschablonen, englisch Phrase Templates oder Requirement Templates) dienen der natürlichsprachlichen Erfassung von (einzelnen) Anforderungen. Durch den Einsatz von Satzschablonen erhalten die Formulierungen in den Sätzen eine gleichartige Struktur, die den Interpretationsspielraum reduzieren und damit Missverständnisse vermeiden. Ursprünglich entwickelt wurden sie von Chris Rupp /Rupp14, Rupp20, #Sophist-Wissen-For-Free/, inzwischen sind sie in der Requirements-Engineering-Welt verankert und auch für die englische Sprache vorhanden.
Hinweis:
Ein Großteil der hier beschriebenen Vorgehensweisen stammt von Chris Rupp und den Sophisten /Rupp14, Rupp20, #Sophist-Wissen-For-Free, #Sophist-MASTeR-Broschüre-24/.
Die Einordnung (der Verwendung) der Satzschablonen ist in Abbildung 0.1 dargestellt: Satzschablonen dienen der natürlichsprachlichen Beschreibung von einzelnen Anforderungen. Sie basieren auf → Vorlagen, die eine Struktur vorgeben.
Abbildung 0.1: Einordnung von Satzschablonen im Requirements-Engineering-Kontext
1. Einleitung und Grundlagen
Bei Rupp /Rupp14, #Sophist-MASTeR-Broschüre-24/ wird definiert:
“Eine Anforderungsschablone ist ein Bauplan, der die Struktur eines einzelnen Anforderungssatzes festlegt.”
Im → Glossar des → IREB /#IREB-Glossar-24/ steht:
Satzschablone (Phrase template): “A template for the syntactic structure of a phrase that expresses an individual requirement or a → user story in natural language. (→ requirements template).“
Eigene Übersetzung: “Eine Schablone für die syntaktische Struktur eines Satzes, die eine individuelle Anforderung oder eine User Story in natürlicher Sprache ausdrückt.”
Im Lehrplan zum CPRE-FL (Certified Professional for Requirements Engineering — Foundation Level) steht /IREB-24/:
“Satzschablonen bieten eine vordefinierte syntaktische Struktur für einen Satz, der eine Anforderung ausdrückt, insbesondere eine individuelle Anforderung oder eine User Story.”
In Abbildung 1.1 ist die Struktur einer einfachen Satzschablone dargestellt.
Abbildung 1.1: Die Satzschablone
Zur Darstellung der einzelnen Elemente in Abbildung 1.1:
- Alle Elemente der Schablone sind verpflichtend auszufüllen
- Die in Großbuchstaben geschriebenen Bestandteile sind genauso “unverändert” zu benutzen
- Die in “<…>”-Klammern verwendeten Elemente sind Platzhalter und müssen entsprechend ausgefüllt werden
- Die Reihenfolge der Elemente ist durch die Schablone festgelegt, die Bearbeitungsfolge jedoch nicht
2. Die Satzschablone im Einsatz
Betrachtet man die Satzschablone aus der Einleitung (Abbildung 1.1), so stellt sich die Frage, wie man die einzelnen Bestandteile am sinnvollsten zusammenstellt. Durch Chris Rupp /Rupp14/ wurde hierzu eine Reihenfolge und Vorgehensweise festgelegt (Abbildung 2.1), die aufgrund der Verbreitung als → Standard bezeichnet werden kann.
Abbildung 2.1: Die Satzschablone ohne Bedingung
Die Formulierung der einzelnen Anforderungen geschieht dann in einzelnen Schritten.
Diese sind:
- System benennen
- Rechtliche → Verbindlichkeit (auch: Verbindlichkeit oder Wichtigkeit) festlegen
- Funktionalität identifizieren
- Art der Funktionalität bestimmen
- Objekt identifizieren
2.0 System benennen
Auch wenn es trivial klingt: Es muss klar benannt sein, für welches System oder Subsystem eine Anforderung erfasst werden soll. Da es immer einen → Systemkontext gibt, findet das System oder Subsystem auch immer dort statt.
2.1 Rechtliche Verbindlichkeit festlegen
Das Festlegen der rechtlichen Verbindlichkeit erfolgt im zweiten Schritt. Über die drei Schlüsselwörter MUSS, SOLLTE und WIRD ist diese beschrieben (Abbildung 2.2).
Dabei werden gilt:
- Mit “MUSS” werden alle Anforderungen klassifiziert, die umgesetzt werden müssen. Werden MUSS-Anforderungen nicht umgesetzt, so kann das entstehende Produkt nicht freigegeben / abgenommen werden
- Mit “SOLLTE” werden alle Anforderungen klassifiziert, die umgesetzt werden sollten
- Mit “WIRD” werden alle Anforderungen klassifiziert, die zukünftig umgesetzt werden könnten
Abbildung 2.2: Die rechtliche Verbindlichkeit
In Abbildung 2.3 sind die Schlüsselwörter genauer beschrieben / definiert.
Abbildung 2.3: Die rechtliche Verbindlichkeit mit Erläuterungen
Anmerkung:
Die Verwendung der Schlüsselwörter sollte mit allen Beteiligten vorab besprochen werden. Insbesondere darf — bei diesem Schema — das Wort KANN nicht zur Beschreibung der rechtlichen Verbindlichkeit verwendet werden.
2.2 Funktionalität identifizieren
Über Prozesswörter wird bestimmt, was das betrachtete System macht. Prozesswörter sind diejenigen Wörter, die in einer separaten Tabelle erfasst und definiert werden. Alle Anforderungen sollten nur diese Prozesswörter verwenden.
2.3 Art der Funktionalität bestimmen
In Schritt 3 wird hinzugefügt, welche “Art” erfasst werden soll. Generell wird zwischen drei Arten der Funktionalität unterschieden (Abbildung 2.5):
- Selbsttätige Systemaktivität
- Benutzerinteraktion
- Schnittstellenanforderung
Abbildung 2.5: Die Art der Funktionalität (bei der Satzschablone)
2.4 Objekt identifizieren
Abschließend wird das Objekt identifiziert und mit einer Konjunktion eingeleitet. Dabei sind folgende Konjunktionen häufig zu finden (Abbildung 2.6):
- FALLS: Hierüber wird eine logische Aussage eingeleitet
- SOBALD: Mit “sobald” wird der → Zeitpunkt für das Eintreten des Ereignisses gekennzeichnet
- SOLANGE: Die Zeitdauer wird durch “solange” erfasst
Abbildung 2.6: Signalwörter der Bedingungen (aus /Rupp14/)
3. Ergänzungen und Erweiterungen der Satzschablonen
Die einfache Satzschablone aus Abbildung 2.1 kann durch eine Bedingung (Punkt 5 in Abbildung 3.1) erweitert werden. Die Bedingung gibt vor, unter welchen Umständen die Anforderung Gültigkeit besitzt.
Abbildung 3.1: Die Satzschablone mit Bedingung
4. Stärken und Schwächen von Satzschablonen
Auch wenn Satzschablonen im Requirements Engineering einfach eingesetzt werden können, so sollten vorab deren Stärken und Schwächen und damit deren Grenzen bekannt sein.
Stärken:
- Satzschablonen lassen sich schnell einsetzen, um “gute” Anforderungssätze zu erhalten
- Satzschablonen tragen (wie → Glossare) zu einer gemeinsamen Fachsprache bei
- Satzschablonen helfen dabei, → Fehler in Beschreibungen aufzudecken
Schwächen:
- Ohne Schulung der Mitarbeiter (und Einübung) ist das Ergebnis häufig mangelhaft
- Fügt man die einzelnen, mit Satzschablonen erstellten Anforderungssätze aneinander, um beispielsweise ein → Lastenheft zu erstellen, so ist das Ergebnis schwer zu lesen, da durch die Gleichförmigkeit eine Tristesse entsteht
5. Hier nicht betrachtete Aspekte
Folgende Aspekte wurden in diesem Beitrag nicht betrachtet:
- → Nicht-funktionale Anforderungen: Für nicht-funktionale Anforderungen gibt es eigenständige Satzschablonen
- Englische Satzschablonen: Auch für die englische Sprache gibt es eigenständige Schablonen, die aber im Wesentlichen wie die deutschen aufgebaut sind
- “Agile Satzschablonen”: → User Stories verwenden ebenfalls Satzschablonen, die allerdings in erster Linie nur in agilen Kontexten zum Einsatz kommen
6. Häufig gestellte Fragen und Antworten (FAQ) zu den Satzschablonen
Einige Fragen zu den Satzschablonen werden häufig gestellt – diese werden hier wiedergegeben.
- F: Ist der Einsatz der Satzschablonen kostenfrei?
A: Ja. Es fallen keine Lizenzgebühren an. - F: Reicht es für ein Requirements-→ Vorhaben aus, nur Satzschablonen zu arbeiten und auf ergänzende Beschreibungen zu verzichten?
A: Generell kann man die Anforderungen für ein Produkt nur über Satzschablonen erfassen. Allerdings ist es motivierend, auch grafische Elemente (wie → UML-Diagramme) einzusetzen. - F: Wie oder durch wen kann die Qualität der mit Hilfe von Satzschablonen formulierten Sätze überprüft werden?
A: Im Zweifel durch denjenigen oder diejenigen, die die Anforderungen in Nachhinein verwenden müssen. Sind die Inhalte verständlich und eindeutig, so ist dies ein Qualitätsmerkmal.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
A.1 Meine öffentliche Präsentation zu den Satzschablonen
Die Satzschablonen werden (kurz) in der Präsentation zum Requirements Engineering beschrieben.
Inhalt | Typ |
---|---|
Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) |
A.2 Literatur
In folgenden Büchern werden als Teilaspekt die Satzschablonen erläutert:
- /Ebert19/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 6. Auflage 2019, ISBN 978–3‑86490–562‑9
- /Hruschka19/ Peter Hruschka: → Business Analysis und Requirements Engineering: Prozesse und Produkte nachhaltig verbessern, Hanser, München 2. Auflage 2019, ISBN 978–3‑446–45589‑4
- /IREB15/ siehe /Pohl15a/
- /IREB21/ siehe /Pohl21/
- /Pohl15a/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering – Foundation Level, dpunkt, Heidelberg 4. Auflage 2015, ISBN 978–3‑89864–771‑7
- /Pohl15b/ Klaus Pohl, Chris Rupp: Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam – Foundation Level – IREB compliant, Rocky Nook, Santa Barbara, California 2nd Edition 2015, ISBN 978–1‑937538–77‑4
- /Pohl21/ auch /IREB21/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt, Heidelberg 5. Auflage 2021, ISBN 978–3‑86490–814‑9
- /Rupp14/ Chris Rupp: Requirements-Engineering und ‑Management. Aus der Praxis von klassisch bis agil, Hanser, München 6. Auflage 2014, ISBN 978–3‑446–43893‑4
- /Rupp20/ Chris Rupp: Requirements-Engineering und ‑Management. Das Handbuch für Anforderungen in jeder Situation, Hanser, München 7. Auflage 2020, ISBN 978–3‑446–45587‑0
A.3 Weblinks
Auf folgende Weblinks (zu den Satzschablonen) wird hier Bezug genommen:
- /IREB-24/, /#IREB-24/, /#IREB-CPRE-FL-24/ IREB – International Requirements Engineering Board: Lehrplan / Syllabus zum CPRE-FL, Version 3.2.0 vom Februar 2024 (deutsch, pdf-Datei, 51 Seiten)
- /#IREB-Glossar-24/ IREB – International Requirements Engineering Board: Glossar des IREB, Version 2.1.1 vom April 2024 (deutsch, englisch, pdf-Datei, 65 Seiten)
- /#IREB-CPRE-FL-Handbuch-24/ IREB – International Requirements Engineering Board: Handbuch für das CPRE Foundation Level nach dem IREB-Standard, Version 1.2.0 vom Mai 2024 (deutsch, pdf-Datei, 174 Seiten)
- /#Rupp-RE-MASTeR-Plakat-19/ Chris Rupp (Fa. Sophist): Plakat zu den Satzschablonen
- /#Sophist-MASTeR-Broschüre-24/ Fa. Sophist: Satzschablonen für alle Fälle, 6. Auflage 2024, (deutsch, pdf-Datei, 52 Seiten)
- /#Sophist-Wissen-For-Free/ Fa. Sophist: Webseite mit einigen Broschüren und Postern rund um das RE
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 18.05.2021 © Peterjohann Consulting, 2005–2024