ARE Cheat-Sheet — Requirements ab Stakeholder-Ebene

Advanced Requirements Engineering · Cheat Sheet

Deutsch·English 🖼 Poster

Vom Stakeholder Requirement bis zu den Acceptance Criteria

Welche Requirement-Typen es gibt, wie sie sich auf SAFe abbilden lassen, mit welchem Format man welche Ebene beschreibt und wie die Dekomposition nach unten läuft.

Grundlage: ISO/IEC/IEEE 29148:2018 · SAFe · Cockburn · Bass/Clements/Kazman
01

Die Ebenen und die beiden Modelle

Eine Ebene tiefer heißt: konkreter, kleiner, näher an der Lösung. Alle Ebenen bis zur User Story bleiben dabei implementierungsfrei — sie sagen, was gelten soll. Erst beim System Element Requirement wird festgelegt, wie es gebaut wird.

ISO 29148 · Business Requirement (BRS) Business Goal
Mission, Ziele, Opportunities
wird nicht zerlegt Trace-Ziel

BeispielDie Take-Rate der Infotainment-Premium-Option maximieren, um die hohen lokalen Fertigungskosten auszugleichen.

Ein Business Goal hat Business Objectives — messbare Ziele, an denen sich das Goal überprüfen lässt. Business Requirements haben keine Kinder: Stakeholder Requirements werden nicht unter ihnen aufgehängt, sondern tracen auf sie. Das Trace-Ziel ist das Business Objective des Business Goal; wo keine Objectives ausformuliert sind, tracen die Anforderungen direkt auf das Goal. Dieser Trace ist der Relevanz-Nachweis — keine Verbindung ⇒ Gold-Plating. Neben dem Business Goal stehen gleichrangig Business Process Requirement, Operational Business Requirement, Business Risk und die Business Constraints (Budget, Termin, Recht).

ISO 29148 · Stakeholder Requirement (StRS) Stakeholder Requirement
SAFe: Epic
implementierungsfrei 2–6 Monate Strategic Planning

BeispielAls Fahrer möchte ich während der Fahrt telefonieren, so dass ich weiterfahren kann.

Bedürfnisse und Fähigkeiten, die Nutzer und Stakeholder verlangen. Bündelt zusammengehörige Funktionalität und trägt Business Value. Bewusst grob — nicht singular, nicht complete, bis sie verfeinert ist. Prüfung: Validation („bauen wir das Richtige?“). Größenmaß: T-Shirt — S = 1 PI, M = 1–2 PI, L > 2 PI, wobei PI = Program Increment, der Planungstakt von 8–12 Wochen bzw. 3–5 Sprints à 2–4 Wochen, in dem ein Feature fertig wird.

ISO 29148 · System Requirement (SyRS) System Requirement
SAFe: Feature
implementierungsfrei · in der Domäne 1 PI ≈ 8–12 Wochen Increment Planning

BeispielAls Fahrer möchte ich während der Fahrt eine Telefonnummer wählen, so dass ich mit einem Gesprächspartner sprechen kann.

Implementierungsfreie Beschreibung dessen, was das System leisten muss. Mit einem Release auslieferbar und verkaufbar. Muss bounded sein: vollständig in genau einem Program Increment entwickelbar und testbar. Prüfung: Verification („bauen wir es richtig?“). Auf derselben Ebene liegen außerdem zwei Sonderfälle. Der Architecture Enabler nimmt eine Developmental Quality auf: technische Arbeit, die nach außen nichts ändert. Und das Operational Feature: Betrifft eine Operational Quality nur ein Feature, wird sie dessen Acceptance Criterion — betrifft sie mehrere, gehört sie an keines von ihnen und bekommt deshalb ein eigenes Feature. Das ist unser Vorschlag, ausdrücklich anders, als SAFe es nahelegt.

kein Pendant in ISO 29148 User Story
implementierungsfrei 1 Sprint · 2–4 Wochen

BeispielAls Fahrer möchte ich während der Fahrt die Telefonfunktion und die Wähloption auswählen, so dass ich anschließend eine Rufnummer eintippen kann.

ISO 29148 kennt zu dieser Ebene kein Pendant. Die User Story ist eine SAFe-Ebene und beschreibt weiterhin, was der Nutzer tun können soll — nicht, wie es gebaut wird. Die Regel, die sie tragfähig hält: eine User Story soll die Subsysteme spannen und Nutzerinteraktion beschreiben, statt komponentenspezifisch zu werden („CAN-Message-Matrix-Layer aktualisieren“ wäre der Fehler, der den Wert verliert).

ISO 29148 · System Element Requirement System Element Requirement
SAFe: Implementation Task
implementierungsgebunden außerhalb des Kursumfangs

BeispielDer Dialer-Service soll die eingegebene Rufnummer vor der Übergabe an den Telefonie-Stack nach E.164 normalisieren.

Hier beginnt der Lösungsraum. Die technische Spezifikation für Software, Hardware und deren Schnittstellen — das Wie statt des Was. Auf derselben Ebene liegt das Sub-System Requirement, das manche Organisationen zusätzlich führen und weiter zerlegen. Der Kurs endet eine Ebene darüber.

Die beiden Modelle nebeneinander

Business Requirement
Goal mit Objectives
Stakeholder Requirement
SAFe: Epic
System Requirement
SAFe: Feature
User Story
nur in SAFe
System Element Requirement
SAFe: Implementation Task
Quality
Operational Quality, Quality Scenario
Constraint
nicht verhandelbar
Enabler
technische Arbeit

Das Badge markiert alles, was weder in SAFe noch in ISO 29148 steht, sondern unser Vorschlag ist.

Ansicht
SAFe ISO 29148 ENABLER EPIC ENABLER FEATURE ENABLER STORY OPERATIONAL QUALITY REQUIREMENTS SENTENCE WE QUALITY SCENARIO 6-teilige Vorlage WE 1..n n : 1 · mehrere Features teilen sie EPIC USER STORY FORMAT oder REQUIREMENTS SENTENCE FEATURE USER STORY FORMAT ACCEPTANCE CRITERIA · funktional ACCEPTANCE CRITERIA · USE CASE NFR · optional QUALITY SCENARIO bei 1:1 · optional USER STORY USER STORY FORMAT ACCEPTANCE CRITERIA · funktional ACCEPTANCE CRITERIA · 1..n GWT NFR · optional QUALITY SCENARIO bei 1:1 · optional IMPLEMENTATION TASK BUSINESS REQ STAKEHOLDER REQ STAKEHOLDER REQ · FUNCTIONAL USER STORY FORMAT (AUSNAHME: REQUIREMENTS SENTENCE) STAKEHOLDER REQ QUALITY REQUIREMENTS SENTENCE CONSTRAINT REQUIREMENTS SENTENCE „WILL“ WE SYSTEM REQ · FUNCTIONAL USER STORY FORMAT ACCEPTANCE CRITERIA · USE CASE QUALITY SCENARIO bei 1:1 · optional SYSTEM REQ QUALITY REQUIREMENTS SENTENCE CONSTRAINT CONSTRAINT REQUIREMENTS SENTENCE „WILL“ QUALITY SCENARIO 6-teilige Vorlage WE 1..n n : 1 SYSTEM ELEMENT REQ SUB-SYSTEM REQ Sub-System Req ist proprietär, weiter zerlegbar ≙ ≙ ≙

02

Die Artefakte und ihre Attribute

Stakeholder Requirement Epic

Das Bedürfnis eines Nutzers oder Stakeholders — grob, gebündelt, wertorientiert.

Attribute
Title
Kurzname
Owner
verantwortet die Realisierung
Source
hat die Anforderung eingebracht; mit ihr wird geklärt
Description
siehe Format unten
Estimate
T-Shirt: S = 1 PI · M = 1–2 PI · L > 2 PI
Business Outcome
Bezug zum Business Goal, falls es Business Goals gibt
Leading Indicators
Bezug zu den Business Objectives des referenzierten Business Goal, falls es welche gibt
… ohne Goals
Gibt es weder Business Goals noch Objectives, gehören Outcome und Leading Indicators trotzdem beschrieben — sonst fehlt die Begründung, warum die Anforderung überhaupt gebaut wird
Format
funktional → User-Story-Format
Quality → Requirements-Sentence-Format
in Ausnahmen auch funktional als Requirements Sentence
Trace
auf ein Business Objective
Elaboration
funktional → ein grober Elaboration Use Case
Quality → Quality Scenarios, typischerweise 6–7
System Requirement Feature

Ein abgegrenzter Systembeitrag, der in genau ein PI passt und ausgeliefert werden kann.

Attribute
Title
Kurzname
Severity
must · should · nice-to-have. Wer mag, führt sie zusätzlich als KANO-Kategorie — die beiden Achsen decken sich oft, aber nicht immer: eine gesetzliche Auflage ist „must“, im KANO-Sinn aber häufig indifferent.
Description
siehe Format unten
Problem Statement
welches Problem heute besteht und hier gelöst wird
Benefit/Value
wer bekommt welchen Nutzen
Acceptance Criteria
der eigene Acceptance Use Case
… darin
Dependencies (setzt ein anderes Feature voraus oder ersetzt es) und die zugehörigen Operational Qualities gehören in den Description-Block
Format
User-Story-Format
Entsteht aus
Success Scenario, Alternative Flow oder Variation des Elaboration Use Case
User Story Sprint-Item

Eine einzelne Nutzerinteraktion aus den Acceptance Criteria des Features, in einem Sprint machbar.

Attribute
Title
Kurzname, optional
Description
siehe Format unten
Acceptance Criteria
ein oder mehrere GWT-Statements
Feature Parent
Link auf das Feature, aus dem sie geschnitten wurde
Format
User-Story-Format
Merke
Ein Feature darf auch auf genau eine User Story abgebildet werden. Das Entwicklungsteam darf auf Ausarbeitung bestehen und setzt darauf seine „Definition of Ready“.
Use Case nach Cockburn

Der strukturierte Interaktionsablauf. Zwei völlig verschiedene Rollen, je nachdem wo er hängt.

Attribute
Name
Name des Use Case
Actors
beteiligte Akteure
Trigger
was den Ablauf auslöst
Preconditions
was vorher gelten muss
Postconditions
was danach gilt
Success Scenario
die Schritte der Interaktion
Alternative Flows
Abweichungen und Error Cases, nummeriert am Schritt
Am Stakeholder Req.
Elaboration Use Case — genau einer, dafür grob: der ganze Ablauf mit Alternativen und Variationen
Am System Req.
Acceptance Use Case — enger gefasst, je Feature einer. Braucht ein Feature zwei, ist es meist noch nicht bounded.
GWT-Statement Given-When-Then

Das testbare Acceptance Criterion einer User Story — Vorbedingung, Aktion, erwartete Änderung.

Attribute
Given
Zustand, bevor das Verhalten beginnt
When
die spezifizierte Aktion
Then
die erwartete Änderung
Gehört zu
einer User Story, 1..n je User Story
Merke
User Stories bekommen GWT, keine Use Cases. Das GWT speist direkt den Testfall.
Quality Scenario Operational Quality

Bricht eine Operational Quality so weit herunter, dass sie messbar und damit verhandelbar wird.

Attribute
Source of Stimulus
wer oder was löst aus
Stimulus
welches Ereignis
Artifact
welches Element ist betroffen
Environment
welcher Betriebszustand
Response
wie soll reagiert werden
Response Measure
wie wird die Reaktion gemessen
Stimulus
ein einzelnes Feature bzw. eine User Story, eine ganze Feature-Menge, oder deren Error Cases
Faustregel
6–7 Szenarien, um eine Quality wirklich zu verstehen
Merke
Bei metrischen Werten ein Wertebereich, keine harte Einzelzahl.
Constraint schränkt den Lösungsraum ein

Eine bereits getroffene Entscheidung, die den Lösungsraum begrenzt — kein Verhalten, das das System zeigt.

Arten
Budget
verfügbare Mittel
Termin
fixe Zeitpunkte, Marktfenster
Recht
Gesetze, Normen, Richtlinien
Technologie
gesetzte Plattform, Sprache, Wiederverwendung
Design
physische und gestalterische Vorgaben
Organisation
Standorte, Lieferanten, Prozesse
Format
Requirements-Sentence-Format mit „will“ — der Constraint stellt eine Tatsache oder gesetzte Absicht fest und fordert kein Systemverhalten („shall“ / „should“) ein.
Einordnung
Nach ISO 29148 und IREB ist der Constraint eine der drei Requirement-Klassen — das verschweigen wir nicht. Wir behandeln ihn trotzdem gesondert: er ist nicht verhandelbar, wird nicht dekomponiert und bekommt keine Acceptance Criteria. Damit fehlt ihm das, was eine Anforderung ausmacht — er ist eine gesetzte Entscheidung, kein ausgehandelter Bedarf.
Enabler nicht nutzersichtbar

Technische Arbeit ohne unmittelbaren Nutzerwert — Vorarbeit, die Features erst möglich macht, und gezielte technische Verbesserung des Bestehenden.

Wofür
Vorarbeit
schafft die Voraussetzung für kommende Features
Verbesserung
hebt eine Developmental Quality — Modularität, Testbarkeit, Wartbarkeit, Wiederverwendbarkeit — ohne dass sich nach außen etwas ändert
Architecture Enabler
der Enabler auf System-Requirement-Ebene: Sein Ergebnis ist eine Architekturentscheidung — er verändert die Sys-, SW- oder HW-Architektur, nicht das Verhalten nach außen
Enabler Story
auch Enabler Task — auf Sprint-Ebene, neben den User Stories unter einem Feature
Verantwortung
System-/Software-Architekt und Entwicklungsteam

Die sechs Arten von Benefit/Value

Das Feld Benefit/Value am System Requirement ist die Stelle, an der über Umsetzung, Priorisierung und Release-Zuordnung entschieden wird. Es gibt sechs wiederkehrende Muster — zwei davon sind direkt KANO-Kategorien.

ArtWorin der Wert liegt
Increase revenue Neue oder erweiterte Features, für die Kunden nachweislich zu zahlen bereit sind — auf Anfrage mehrerer Kunden oder eines großen Kunden.
Save time / avoid costs Jede Sekunde, die eine typische Transaktion kürzer wird, spart im Call-Center Agenten und damit Geld.
Improve service quality KANO Performance Bestehende Fähigkeiten verbessern. Bessere Videoqualität ist kein neues Feature, hat aber Wert: mehr Kunden bleiben, wenn die Gesprächsqualität steigt.
Meet regulations Vorgeschriebenes, etwa eine „Do Not Call“-Liste. Nicht verhandelbar, unabhängig vom Zufriedenheitsgewinn.
Build reputation KANO Delighter Sichtbarkeit im Markt und Markenbildung, etwa eine kostenlose Demo-Version — indirekt ebenfalls Umsatz.
Generate information Wir als Anbieter oder der Nutzer selbst braucht bessere Information für eine Entscheidung — etwa ein A/B-Test.
03

Die Formate — welches wofür

Welches Format auf welcher Ebene gilt, sagt weder SAFe noch ISO 29148 — die Zuordnung unten ist unser Vorschlag. Sie ist keine Geschmacksfrage: sie folgt daraus, ob hinter der Anforderung ein Nutzer mit einem Wert steht (User-Story-Format) oder eine Systemeigenschaft (Requirements-Sentence-Format) — und auf welcher Ebene sie steht.

Format der DescriptionWird verwendet fürBeantwortetPrüffrage
User-Story-Format
  • Stakeholder Requirement funktional · SAFe: Epic
  • System Requirement funktional · SAFe: Feature
  • User Story
 Wer? Was? Warum? Gibt es einen benennbaren Nutzer und einen Wert für ihn?
Requirements-Sentence-Format
  • Stakeholder Requirement Operational Quality
  • Constraint
 Was muss das System unter welcher Bedingung tun? Ist die Verbindlichkeit explizit — shall, should oder will?
Use-Case-Format
  • Elaboration Use Case am Stakeholder Requirement · SAFe: Epic
  • Acceptance Use Case am System Requirement · SAFe: Feature
 Wie interagieren Nutzer und System Schritt für Schritt? Erklärt das Success Scenario einem neuen Nutzer die Anforderung?
GWT-Format
  • Acceptance Criteria der User Story
 Ausgangszustand, Aktion, erwartete Änderung Ist daraus direkt ein Testfall ableitbar?
Quality-Scenario-Format
  • Ausformulierung einer Operational Quality
 Wer löst was aus, an welchem Artefakt, in welchem Zustand — und was ist die messbare Reaktion? Ist das Response Measure wirklich messbar, und als Bereich formuliert?

User-Story-Format — Value Focus

Als ein <Rolle / Typ von Nutzer> möchte ich <dies tun>, so dass <ich dieses Ziel erreiche>.

Beispiel: Als Fahrer möchte ich Anrufe über das Infotainment-System einleiten, so dass ich die Hände am Lenkrad behalten kann.

Zu grob — das ist ein Epic, kein Feature: Als Fahrer möchte ich unterwegs telefonieren, so dass ich weiterfahren kann. Ein Bündel von Funktionalität, das erst über den Use Case in abgegrenzte Features zerfällt.

Requirements-Sentence-Format — System Focus

[Condition] · Subject · Imperative · Action · Object · [Constraint] Condition optional — Trigger oder Kontext ("when", "while", "within") Subject das konkrete System oder der Akteur Imperative shall = verbindliche Anforderung should = Ziel oder Empfehlung, nicht bindend will = Tatsachenfeststellung oder gesetzte Absicht → Constraints Action das beobachtbare Verhalten Object das Objekt der Handlung Constraint optional — Performance- oder Qualitätskriterium

Operational Quality: Das Infotainment-System shall weniger als 5 W Leistung aufnehmen, when die Zündung ausgeschaltet ist.

Constraint mit „will“: Das Infotainment-System will die im Fahrzeug vorhandene CAN-Bus-Schnittstelle nutzen. — Eine gesetzte Technologieentscheidung, kein gefordertes Verhalten.

Use-Case-Format (nach Cockburn)

Vorlage

Name <Name des Use Case> Actors <beteiligte Akteure> Trigger <was den Ablauf auslöst> Preconditions <was vorher gelten muss> Postconditions <was danach gilt> Success Scenario <1..n Schritte der Interaktion> Alternative Flows <Abweichungen und Error Cases, nummeriert am Schritt>

Beispiel Infotainment

Name Make a Call Actors User, Call Partner Trigger User indicates call wish Preconditions Phone connected, idle Postconditions idle Success Scenario 1. User dials number 2. System establishes call 3. Call partner accepts 4. User and partner talk 5. User hangs up Alternative Flows 2a. Call cannot be established → 3a. "Network error" 2b. Partner's line is busy → 3b. "busy" 2c. Partner rejects the call → 3c. "rejected"

Quelle: Alistair Cockburn, Writing Effective Use Cases.

GWT-Format — Acceptance Criteria der User Story

Given der Zustand der Welt, bevor das Verhalten beginnt (Vorbedingung) When das Verhalten / die Aktion, die spezifiziert wird Then die erwartete Änderung als Folge dieser Aktion

Beispiel: Given das System läuft in einer anderen Funktion als Telefonie, when der Fahrer die Telefonoption wählt, then kann er unmittelbar danach eine Rufnummer eintippen.

Quality-Scenario-Format — sechs Teile

Vorlage

Source of Stimulus wer oder was löst aus (intern / extern) Stimulus WHEN welches Ereignis (periodisch / stochastisch / sporadisch) Artifact welches Element ist betroffen (System, Komponente, Speicher, Kommunikation) Environment GIVEN welcher Betriebszustand (Normal / Peak / Overload / Degraded / Wartung) Response THEN wie soll das Element reagieren Response Measure wie wird die Reaktion gemessen (Latency, Deadline, Jitter, Throughput, Miss Rate, Repair Time, Verfügbarkeitsrate)

Beispiel Telemedizin — Performance unter Normal Load

Source of Stimulus Intern Stimulus Periodisches Ereignis: Patienten-Gesundheitsdaten alle 60 s Artifact System Environment Normal Load Response Daten persistieren, potenziellen Notfall erkennen Response Measure Persistenz: Latenz 1–10 s, Jitter < 1 s · Notfallerkennung: Latenz 2–5 s

Zweites Szenario derselben Quality — Notfallmeldungen, hier unter Normal Load

Source of Stimulus Intern Stimulus Stochastisches Ereignis: Notfall für 75.000 Geräte innerhalb 10 s Artifact System Environment Normal Load Response Notfall persistieren, Rettungsdienst informieren Response Measure Persistenz: Latenz 1–10 s · Rettungsdienst informieren: Latenz 10–20 s

Dasselbe Szenario unter Overload — Environment, Ereignismenge und Measure verschieben sich gemeinsam

Stimulus Stochastisches Ereignis: Notfall für > 125.000 Geräte innerhalb 10 s Environment Overload Response Measure Persistenz: Latenz 1–30 s · Rettungsdienst informieren: 60–120 s Miss Rate: darf überhaupt ein Notfall verloren gehen?

Die drei Teile, auf die es ankommt

  • Environment ist der Hebel: dieselbe Quality wird unter Normal Load, Peak Load und Overload unterschiedlich streng — erst dadurch wird sie verhandelbar statt utopisch.
  • Artifact stellt scharf, worauf sich die Quality bezieht: das Gesamtsystem, ein Prozess, der Speicher, die Kommunikationsstrecke.
  • Response Measure ist die Brücke zur Testbarkeit. Ein Response ohne Measure ist eine Absichtserklärung.
04

Dekomposition — wie man nach unten kommt

Der Use Case ist das Werkzeug, das aus einem groben Stakeholder Requirement mehrere abgegrenzte Features macht. Nicht raten, sondern ableiten: jeder Pfad des Use Case ist ein Kandidat für ein eigenes Feature.

BUSINESS OBJECTIVE wird nicht zerlegt STAKEHOLDER REQ · EPIC „Unterwegs telefonieren“ traced auf ELABORATION USE CASE Success Scenario Alternative Flows Variationen einer je Epic — grob elaborated by FEATURE ← SUCCESS SCENARIO „Nummer wählen“ FEATURE ← ALTERNATIVE FLOW „Letzte Nummer erneut wählen“ FEATURE ← VARIATION A „Aus dem Telefonbuch wählen“ FEATURE ← VARIATION B „Über das Lenkrad wählen“ jeder Pfad = ein Feature-Kandidat ACCEPTANCE CRITERIA · EIGENER USE CASE enger gefasst, je Feature einer USER STORY · „Telefonfunktion wählen“ USER STORY · „Laufenden Anruf beenden“ broken into 1..n GWT · ACCEPTANCE CRITERIA DER USER STORY Given … When … Then … 1..n je User Story · speist den Testfall

Das Vorgehen in fünf Schritten

  1. Stakeholder Requirement prüfen. Steht ein Nutzer mit einem Wert dahinter? Dann User-Story-Format. Sonst Requirements-Sentence-Format. Und: Auf welches Business Objective traced es?
  2. Den groben Use Case schreiben — einen je Stakeholder Requirement: komplettes Success Scenario, die Alternative Flows und die Error Cases.
  3. Features ableiten — aus dem Success Scenario, aus jedem Alternative Flow, aus jeder Variation. Jedes abgeleitete Feature muss in ein PI passen und wird auf den Schritt bzw. Flow zurückgemappt, aus dem es stammt.
  4. Je Feature einen eigenen, engeren Use Case als Acceptance Criteria schreiben — Interaktion, kein UI-Design. Auf bereits vorhandene Bedienelemente darf man sich dabei beziehen („über die Tasten am Lenkrad“); neue zu entwerfen ist Sache der Umsetzung.
  5. Features in User Stories schneiden — je eine oder mehrere Interaktionen aus diesen Acceptance Criteria — und je User Story GWT-Statements formulieren.
05

System Boundaries

Spätestens bevor die ersten System Requirements geschrieben werden, muss die Grenze stehen: Was gehört zum System, was ist Nachbar — und welche Schnittstellen liegen dazwischen? Ohne diese Antwort schreibt man Anforderungen an etwas, dessen Umfang niemand kennt.

DIESES CHEAT SHEET eine eigenständige HTML-Seite TEILNEHMER TRAINER BROWSER GITHUB PAGES DRUCKER KURSUNTERLAGEN SYSTEM-THEME HTML / CSS HTTPS DRUCK FOLIENDECKS prefers-color-scheme rot umrandet = technisches Risiko — Druckbild und fremdbestimmte Quelle
  • Was hineingehört: das System als eine Black Box, die Akteure und die Nachbarsysteme.
  • Wozu: Die Black Box legt den Umfang fest — alles außerhalb ist gegeben.
  • Nebenprodukt: Schnittstellen, deren Verhalten unklar oder fremdbestimmt ist, sind die technischen Risiken — sie gehören markiert, solange der Zuschnitt noch änderbar ist.
06

Domain Model

Ein Bild der Begriffe: Entitäten mit ihren Attributen und den Beziehungen dazwischen — ausdrücklich kein UML. Es dient der gemeinsamen Sprache und deckt dabei verlässlich Anforderungen auf, die im Text niemand aufgeschrieben hatte.

SYSTEM: DIESES CHEAT SHEET 1..n beschreibt 1 ABSCHNITT Nummer · Titel BAUSTEIN TABELLE DIAGRAMM KARTE Name · Icon Attributliste REQUIREMENT-TYP Substantive aus dem Use Case sind gute Kandidaten für Entitäten, Verben für Beziehungen — und die dürfen selbst Attribute tragen.

Wann wir modellieren — und mit wem

ZeitpunktMit wemWozu
Bei den Stakeholder Requirements Kunde und Nutzer Gemeinsame Sprache und Glossar — bevor über Anforderungen gestritten wird, wird über Begriffe geeinigt.
Bei den System Requirements Product Owner, Product Manager Klärung und Ableitung: das Modell deckt Zustände, Sonderfälle und fehlende Anforderungen auf. Oder es dient der Klärung von Anforderungen und der Beseitigung von Unklarheiten bzw. Ungereimtheiten.
In Architektur und Umsetzung Product Owner, Architekt, Entwicklungsteam Keine weitere Ableitung mehr — das Modell wird in der Software gespiegelt.
07

Klassifikation und was sie steuert

Ein Requirement ist entweder funktional oder eine Quality; Qualities teilen sich in Operational Qualities (extern, vom Nutzer erlebbar) und Developmental Qualities (intern). Die Kategorie entscheidet über das Format und über das weitere Refinement.

KategorieAuch bekannt alsFormatWird verfeinert durchPrüfung
Functional Functional Requirement User-Story-Format Use Case → System Requirements (Features) → User Stories → GWT Validation gegen das Business Objective
Operational Quality External Non-Functional Requirement — vom Nutzer erlebbar: Performance, Verfügbarkeit, Usability, Security, Kompatibilität Requirements-Sentence-Format Quality Scenarios — als AC eines Features/einer User Story oder als eigenes Operational Feature Response Measure, messbar als Wertebereich
Developmental Quality Internal Non-Functional Requirement — für Entwicklung und Wartung: Modularität, Testbarkeit, Wiederverwendbarkeit, Analysierbarkeit Requirements-Sentence-Format Architecture Enabler → Sys/SW/HW-Architektur Architekturentscheidung
Constraint
nach ISO eine Requirement-Klasse, aber nicht verhandelbar		 Budget, Termin, Recht, Technologie, Design, Organisation Requirements-Sentence-Format mit „will“ nichts — Constraints werden nicht zerlegt Wird er eingehalten?

Qualitätskriterien auf Stakeholder-Ebene

Die ISO-29148-Kriterien greifen auf dieser Ebene nur teilweise: ein Stakeholder Requirement ist per Konstruktion ein Bündel, also weder singular noch complete, und noch nicht verifizierbar. SMART passt besser — aber auch davon sind nur zwei Kriterien hier wirklich anwendbar:

SMARTISO 29148Was auf Stakeholder-Ebene tatsächlich gilt
Specific anwendbar Unambiguous / Singular Das User-Story-Format erzwingt wer, was, warum und drängt vage Formulierungen heraus. Hier lässt sich die Anforderung sofort prüfen und verbessern.
Relevant anwendbar Necessary Ist die Anforderung auf ein Business Objective getraced? Wenn nein: Gold-Plating. Ebenfalls sofort und ohne Refinement entscheidbar.
MeasurableVerifiable Auf dieser Ebene nicht testbar. Messbar nur in dem indirekten Sinn, dass bestimmte System Requirements erfüllt sein müssen.
AttainableFeasible Der Realitätscheck kommt erst beim Refinement zu System Requirements und tiefer.
Time-bound— in ISO nicht enthalten Ergibt sich erst aus dem Estimate: passt es nicht in Sprint bzw. Increment, muss geteilt werden.

Warum Stakeholder Requirements die ISO-Kriterien reißen — und das in Ordnung ist

  • Complete / Singular: ein Bündel von Funktionalität. Wird erst durch Refinement singular und vollständig.
  • Unambiguous: von Natur aus breit. Die Mehrdeutigkeit wird durch das Refinement zu System Requirements aufgelöst, nicht durch Umformulieren auf dieser Ebene.
  • Verifiable: Stakeholder Requirement ⇒ Validation (das Richtige gebaut?). System Requirement ⇒ Verification (richtig gebaut?).
08

Die Quality-Frage

Hier weichen wir am deutlichsten von beiden Standards ab. SAFe hängt Qualities als NFR in die Acceptance Criteria; ISO 29148 führt zwar einen Quality-Typ auf System-Ebene, führt ihn aber nicht weiter aus. Beides trägt nicht, sobald eine Quality mehrere Features betrifft — und das ist der Normalfall.

SO WIE SAFe ES VORSIEHT · KOPIE UNSER VORSCHLAG · REFERENZ FEATURE A ACCEPTANCE CRITERIA … „Antwort < 2 s“ … FEATURE B ACCEPTANCE CRITERIA … „Antwort < 2 s“ … USER STORY C ACCEPTANCE CRITERIA … „Antwort < 2 s“ … Dieselbe Aussage steht dreimal da. Ändert sich der Wert, ändert man ihn dreimal — oder eben nicht. FEATURE A ACCEPTANCE CRITERIA … … FEATURE B ACCEPTANCE CRITERIA … … USER STORY C ACCEPTANCE CRITERIA … … OPERATIONAL QUALITY REQUIREMENTS SENTENCE WE QUALITY SCENARIO „Antwort < 2 s“ WE 1..n n : 1 Der Punkt in den Acceptance Criteria zeigt auf das Szenario, statt seinen Text zu wiederholen. Ändern: an einer Stelle.

Die Regel, wann was gilt

  • Genau ein betroffenes Feature — kopieren ist in Ordnung. Die Quality gehört in die Acceptance Criteria dieses einen Features, so wie SAFe es vorsieht.
  • Mehrere betroffene Features oder User Stories — die Operational Quality wird ein eigener Typ, aufgebrochen in Quality Scenarios, die von den betroffenen Features und User Stories referenziert werden.
  • Der Test: Müsstest du beim Ändern eines Wertes an mehr als einer Stelle suchen, war Kopieren die falsche Entscheidung.

Woher die Abweichung kommt

ModellWas es zu Qualities sagtWo es nicht trägt
SAFe NFRs werden als Acceptance Criteria an Features und User Stories gehängt; sie beschränken die Features, sind aber selbst keine. Betrifft eine Quality mehrere Features, wird ihre Beschreibung in jedes davon kopiert.
ISO 29148 Auf System-Requirement-Ebene existiert der Typ Quality neben Functional und Constraint. Wie eine Quality konkret und prüfbar wird, führt die Norm nicht aus.
Unser Vorschlag Operational Quality als eigener Typ, aufgebrochen in Quality Scenarios nach der 6-teiligen Vorlage — referenzierbar aus Features und User Stories. Setzt voraus, dass das Werkzeug Referenzen auf mehrere Ziele führen kann.
09

KANO — die zweite Klassifikation

Functional / Operational Quality / Developmental Quality sagt, welcher Art eine Anforderung ist. KANO sagt etwas völlig anderes: was ihre Erfüllung mit der Zufriedenheit des Kunden macht. Beide Achsen gelten gleichzeitig — ein funktionales Requirement kann Basic, Performance, Delighter oder Indifferent sein.

ZUFRIEDEN UNZUFRIEDEN GAR NICHT UMGESETZT VOLL UMGESETZT DELIGHTER — WOW PERFORMANCE — LINEAR INDIFFERENT BASIC / MUST-BE

Jede Kurve zeigt, wie die Zufriedenheit steigt, wenn dieselbe Anforderung von „gar nicht“ nach „voll umgesetzt“ wandert. Basic beginnt ganz unten und sättigt, ohne je Zufriedenheit zu erzeugen · Performance läuft linear durch den Ursprung · Delighter startet dicht an der Null — Fehlen stört praktisch niemanden — und steigt dann steil. Der Decay-Pfeil zeigt, wie ein Feature über die Zeit vom Delighter durch Performance hindurch zu Basic absackt.

Die vier Kategorien

KategorieWenn vorhandenWenn sie fehltBeispiel Smartphone
Basic / Must-be
Foundation		 hebt die Zufriedenheit nicht — Kunden setzen es voraus starke Unzufriedenheit Telefonieren können; grundlegende Sicherheitsfunktionen
Performance
Linear Value		 je mehr, desto zufriedener — direkt und linear sinkende Zufriedenheit, ebenfalls linear Akkulaufzeit; Prozessorgeschwindigkeit; Speicherplatz
Delighter
Wow-Faktor		 unerwartete Begeisterung, Wettbewerbsvorteil keine Unzufriedenheit — es wurde ja nicht erwartet KI-Integration; ausklappbarer Projektor; Premium-Abo gratis
Indifferent
Noise		 kaum Wirkung — investierte Ressourcen sind verschwendet kaum Wirkung vorinstallierte Apps, die niemand benutzt

KANO als Suchwerkzeug, nicht nur als Etikett

Angewandt wird KANO vor allem auf Stakeholder- und System Requirements. Der eigentliche Nutzen liegt nicht nur im Einsortieren des Vorhandenen, sondern auch im Finden des Fehlenden. Zum Beispiel sollte ein neues Produkt Delighter-Requirements umsetzen, die wiederum zu bestimmten Business Goals/Objectives beitragen. Umgekehrt wird ein bestehendes Produkt mehrere Performance-Requirements mit weiteren Versionen umsetzen. Falls zu wenige geplant und umgesetzt sind, könnte die neue Version wenig Anklang bei Kunden und Benutzern finden.

KANO STAKEHOLDER REQUIREMENTS SYSTEM REQUIREMENTS einordnen und Fehlendes suchen DELIGHTER-KANDIDATEN was würde überraschen? BUSINESS OBJECTIVE qualitativ formuliert traced auf ERST DIESER TRACE MACHT AUS DER IDEE EINEN WETTBEWERBSVORTEIL Passt kein Objective, kann ein neues entstehen — dann schärft die Anforderung das Geschäftsziel, nicht umgekehrt.

Was die Kategorie für die Arbeit bedeutet

  • Basic: keine Priorisierungsdiskussion. Fehlt es, ist das Produkt kaputt — der Aufwand ist zu leisten, nicht zu verhandeln.
  • Performance: gehört in ein Quality Scenario mit Response Measure. „Mehr ist besser“ wird erst steuerbar, wenn ein Wertebereich dransteht.
  • Delighter: braucht den Trace auf ein Business Objective, sonst ist er nicht von Gold-Plating zu unterscheiden.
  • Indifferent: streichen. Die einzige Kategorie mit einer eindeutigen Handlungsempfehlung.
10

Format-Finder für die Description

Ebene und Klassifikation wählen — heraus kommt das Format, der Refinement-Weg und die Attributvorlage.

Artefakt

Format der Description

Bezug nach oben

Acceptance Criteria

Attribute

Merke

11

Struktur & Ableitung auf einen Blick

Woher jedes Artefakt kommt, woran es hängt, womit es abgenommen wird und in welchem Zeitrahmen es fertig sein soll.

ArtefaktEntsteht ausBezug nach obenAcceptance CriteriaZeitrahmen
Stakeholder Requirement
SAFe: Epic		 Kundenwunsch, Marktanforderung, Standards und Regularien traced auf ein Business Objective funktional: Elaboration Use Case · Quality: Quality Scenarios
beides keine Acceptance Criteria		 2–6 Monate
System Requirement
SAFe: Feature		 Success Scenario · Alternative Flow · Variation des Stakeholder-Use-Case gehört zum Stakeholder Requirement, aus dessen Use Case es abgeleitet wurde eigener, engerer Use Case 1 PI, 8–12 Wochen
User Story eine oder mehrere Interaktionen aus den Acceptance Criteria des Features Feature Parent 1..n GWT-Statements 1 Sprint, 2–4 Wochen
Quality Scenario einer Operational Quality, angewandt auf eine Feature- oder User-Story-Menge die Operational Quality; zusätzlich die Features/User Stories, die den Stimulus bilden ist selbst das Acceptance Criterion —
Constraint Recht, Budget, Termin, Technologie, Design — — wird nicht zerlegt —