From Stakeholder Requirement to Acceptance Criteria
Which requirement types there are, how they map onto SAFe, which format describes which level, and how decomposition works its way down.
Based on: ISO/IEC/IEEE 29148:2018 · SAFe · Cockburn · Bass/Clements/Kazman
01
The levels and the two models
One level down means: more concrete, smaller, closer to the solution. Every level down to the User Story stays implementation-free — they say what shall hold. Only at the System Element Requirement is it settled how it gets built.
ISO 29148 · Business Requirement (BRS)Business Goal Mission, goals, opportunities
not decomposedtrace target
ExampleMaximize the infotainment premium option take-rate to offset high localized manufacturing costs.
A Business Goal has Business Objectives — measurable goals the goal can be checked against. Business Requirements have no children: Stakeholder Requirements are not hung underneath them, they trace to them. The trace target is the Business Objective of the Business Goal; where no objectives are written out, requirements trace directly to the goal. That trace is the proof of relevance — no link ⇒ gold-plating. Alongside the Business Goal, at the same rank, sit Business Process Requirement, Operational Business Requirement, Business Risk and the Business Constraints (budget, schedule, law).
ISO 29148 · Stakeholder Requirement (StRS)Stakeholder Requirement SAFe: Epic
implementation-free2–6 monthsStrategic Planning
ExampleAs a driver I want to make a phone call on the road so that I can go on driving.
Needs and capabilities that users and stakeholders ask for. Bundles related functionality and carries business value. Deliberately coarse — not
singular, not complete, until it is refined. Check:
Validation (“did we build the right thing?”). Sizing: T-shirt — S = 1 PI, M = 1–2 PI, L > 2 PI, where PI = Program Increment, the planning cadence of 8–12 weeks, or 3–5 sprints of 2–4 weeks, in which a feature is finished.
ISO 29148 · System Requirement (SyRS)System Requirement SAFe: Feature
implementation-free · in the domain1 PI ≈ 8–12 weeksIncrement Planning
ExampleAs a driver I want to dial a phone number while driving so that I can talk to a partner while driving.
Implementation-free description of what the system has to do. Shippable and sellable with one release. Must be bounded : fully developable and testable within exactly one Program Increment. Check: Verification
(“did we build it right?”). Two special cases sit on the same level. The
Architecture Enabler takes up a Developmental Quality: technical work that changes nothing on the outside. And the Operational Feature: if an Operational Quality affects only one feature, it becomes that feature’s acceptance criterion — if it affects several, it belongs to none of them and therefore gets a feature of its own. That is our proposal, deliberately different from what SAFe suggests.
no counterpart in ISO 29148User Story
implementation-free1 Sprint · 2–4 weeks
ExampleAs a driver I want to select the phone functions and the dialing option while driving so that I can type in a phone number.
ISO 29148 has no counterpart for this level. The User Story is a SAFe level and still describes what the user should be able to do — not how it is built. The rule that keeps it sound: a User Story should span the subsystems and describe user interaction rather than turning component-specific (“update the CAN message matrix layer” would be the mistake that loses the value).
ISO 29148 · System Element Requirement System Element Requirement SAFe: Implementation Task
implementation-boundoutside the course scope
ExampleThe dialer service shall normalize the entered phone number to E.164 before handing it to the telephony stack.
This is where the solution space begins. The technical specification for software, hardware and their interfaces — the how instead of the what. On the same level sits the Sub-System Requirement, which some organizations keep in addition and decompose further. The course ends one level above.
The two models side by side
Business Requirement goal with objectives
Stakeholder Requirement SAFe: Epic
System Requirement SAFe: Feature
User Story SAFe only
System Element Requirement SAFe: Implementation Task
Quality Operational Quality, Quality Scenario
Constraint not negotiable
Enabler technical work
The badge marks everything that is in neither SAFe nor ISO 29148 but is our proposal.
View
02
The artifacts and their attributes
Stakeholder RequirementEpic
What a user or stakeholder needs — coarse, bundled, value-oriented.
Attributes
Title
short name
Owner
owns delivery
Source
brought the requirement in; open questions are settled with them
Description
see format below
Estimate
T-shirt: S = 1 PI · M = 1–2 PI · L > 2 PI
Business Outcome
reference to the Business Goal, if there are Business Goals
Leading Indicators
reference to the Business Objectives of the referenced Business Goal, if there are any
… without goals
If there are neither Business Goals nor Objectives, outcome and leading indicators still belong in writing — otherwise the reason the requirement is being built at all is missing
Format
functional → User-Story format quality → Requirements-Sentence format in exceptional cases functional as a Requirements Sentence
Trace
to a Business Objective
Elaboration
functional → one coarse Elaboration Use Case quality → Quality Scenarios, typically 6–7
System RequirementFeature
A bounded contribution to the system that fits into exactly one PI and can be shipped.
Attributes
Title
short name
Severity
must · should · nice-to-have. If you like, track it additionally as a KANO category — the two axes often coincide, but not always: a legal obligation is a “must”, yet in KANO terms often indifferent.
Description
see format below
Problem Statement
which problem exists today and is solved here
Benefit/Value
who gets which benefit
Acceptance Criteria
its own Acceptance Use Case
… within it
Dependencies (requires another feature, or replaces it) and the associated Operational Qualities belong in the description block
Format
User-Story format
Comes from
success scenario, alternative flow or variation of the Elaboration Use Case
User Storysprint item
A single user interaction from the feature’s Acceptance Criteria, doable in one sprint.
Attributes
Title
short name, optional
Description
see format below
Acceptance Criteria
one or more GWT statements
Feature Parent
link to the feature it was sliced from
Format
User-Story format
Note
A feature may also map to exactly one User Story. The development team may insist on elaboration and builds its “Definition of Ready” on that.
Use Caseafter Cockburn
The structured interaction sequence. Two entirely different roles, depending on where it hangs.
Attributes
Name
name of the use case
Actors
actors involved
Trigger
what starts the sequence
Preconditions
what must hold beforehand
Postconditions
what holds afterwards
Success Scenario
the steps of the interaction
Alternative Flows
deviations and error cases, numbered against the step
At the Stakeholder Req.
Elaboration Use Case — exactly one, and coarse: the whole sequence with alternatives and variations
At the System Req.
Acceptance Use Case — narrower, one per feature. If a feature needs two, it usually is not bounded yet.
GWT-StatementGiven-When-Then
The testable acceptance criterion of a User Story — precondition, action, expected change.
Attributes
Given
state before the behavior starts
When
the specified action
Then
the expected change
Belongs to
one User Story, 1..n per User Story
Note
User Stories get GWT, not Use Cases. The GWT feeds the test case directly.
Quality ScenarioOperational Quality
Breaks an Operational Quality down far enough to be measurable, and with that negotiable.
Attributes
Source of Stimulus
who or what triggers it
Stimulus
which event
Artifact
which element is affected
Environment
which operating state
Response
how it should react
Response Measure
how the reaction is measured
Stimulus
a single feature or User Story, a whole set of features, or their error cases
Rule of thumb
6–7 scenarios to really understand a quality
Note
For metric values a range, not one hard number.
Constraintnarrows the solution space
A decision already taken that bounds the solution space — not behavior the system exhibits.
Kinds
Budget
available funds
Schedule
fixed dates, market windows
Law
statutes, standards, guidelines
Technology
mandated platform, language, reuse
Design
physical and styling requirements
Organization
sites, suppliers, processes
Format
Requirements-Sentence format with “will” — the constraint states a fact or a settled intention; it does not demand system behavior (“shall” / “should”).
Where it fits
Under ISO 29148 and IREB the constraint is one of the three requirement classes — we do not hide that. We still treat it separately: it is not negotiable, is not decomposed and gets no Acceptance Criteria. That leaves it without what makes a requirement — it is a settled decision, not a negotiated need.
Enablernot user-visible
Technical work without immediate user value — groundwork that makes features possible in the first place, and deliberate technical improvement of what already exists.
What for
Groundwork
creates the precondition for coming features
Improvement
raises a Developmental Quality — modularity, testability, maintainability, reusability — without anything changing on the outside
Architecture Enabler
the enabler at System Requirement level: its result is an architecture decision — it changes the system, software or hardware architecture, not the outward behavior
Enabler Story
also Enabler Task — at sprint level, alongside the User Stories under a feature
Responsibility
system/software architect and development team
The six kinds of benefit/value
The field Benefit/Value on the System Requirement is where delivery, prioritization and release assignment are decided. There are six recurring patterns — two of them are KANO categories.
Kind
Where the value lies
Increase revenue
New or extended features customers demonstrably will pay for — at the request of several customers, or of one large one.
Save time / avoid costs
Every second a typical transaction gets shorter saves agents in the call center, and with them money.
Improve service qualityKANO Performance
Improving existing capabilities. Better video quality is not a new feature, but it has value: more customers stay when call quality goes up.
Meet regulations
What is prescribed, such as a “do not call” list. Not negotiable, regardless of the satisfaction it buys.
Build reputationKANO Delighter
Visibility in the market and brand building, such as a free demo version — indirectly revenue as well.
Generate information
We as the vendor, or the user, need better information for a decision — an A/B test, for instance.
03
The formats — which one for what
Neither SAFe nor ISO 29148 says which format applies at which level — the mapping below is our proposal. It is not a matter of taste: it follows from whether there is a
user with a value behind the requirement (User-Story format) or a system property
(Requirements-Sentence format) — and which level it sits on.
Format of the description
Used for
Answers
Check
User-Story format
Stakeholder Requirement functional · SAFe: Epic
System Requirement functional · SAFe: Feature
User Story
Who? What? Why?
Is there a nameable user and a value for them?
Requirements-Sentence format
Stakeholder Requirement Operational Quality
Constraint
What must the system do under which condition?
Is the obligation explicit — shall, should or will?
Use-Case format
Elaboration Use Case on the Stakeholder Requirement · SAFe: Epic
Acceptance Use Case on the System Requirement · SAFe: Feature
How do user and system interact, step by step?
Does the success scenario explain the requirement to a new user?
GWT format
Acceptance Criteria of the User Story
Initial state, action, expected change
Can a test case be derived from it directly?
Quality-Scenario format
Spelling out an Operational Quality
Who triggers what, on which artifact, in which state — and what is the measurable reaction?
Is the response measure really measurable, and stated as a range?
User-Story format — value focus
As a <role / type of user>
I want <to do this>,
so that <I achieve this goal>.
Example: As a driver I want to place calls through the infotainment system, so that I can keep my hands on the wheel.
Too coarse — this is an epic, not a feature:
As a driver I want to make phone calls on the road so that I can go on driving. A bundle of functionality that only falls apart into bounded features by way of the use case.
Requirements-Sentence format — system focus
[Condition] · Subject · Imperative · Action · Object · [Constraint]
Condition optional — trigger or context ("when", "while", "within")
Subject the concrete system or actor
Imperative shall = binding requirement
should = goal or recommendation, not binding
will = statement of fact or settled intention → Constraints
Action the observable behavior
Object the object of the action
Constraint optional — performance or quality criterion
Operational Quality: The infotainment system shall draw less than 5 W, when the ignition is switched off.
Constraint with “will”: The infotainment system will use the CAN bus interface present in the vehicle. — A settled technology decision, not required behavior.
Use-Case format (after Cockburn)
Template
Name <name of the use case>
Actors <actors involved>
Trigger <what starts the sequence>
Preconditions <what must hold beforehand>
Postconditions <what holds afterwards>
Success Scenario <1..n steps of the interaction>
Alternative Flows <deviations and error cases, numbered against the step>
Infotainment example
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"
Source: Alistair Cockburn, Writing Effective Use Cases.
GWT format — Acceptance Criteria of the User Story
Given the state of the world before the behavior starts (precondition)
When the behavior / action being specified
Then the expected change that follows from that action
Example:Given the system is running a function other than telephony, when the driver selects the phone option, then they can type in a phone number immediately afterwards.
Quality-Scenario format — six parts
Template
Source of Stimulus who or what triggers it (internal / external)
Stimulus WHEN which event (periodic / stochastic / sporadic)
Artifact which element is affected (system, component, storage, communication)
Environment GIVEN which operating state (normal / peak / overload / degraded / maintenance)
Response THEN how the element should react
Response Measure how the reaction is measured (latency, deadline, jitter, throughput,
miss rate, repair time, availability rate)
Telemedicine example — performance under normal load
Source of Stimulus Internal
Stimulus Periodic event: patient health data every 60 s
Artifact System
Environment Normal Load
Response Persist the data, detect a potential emergency
Response Measure Persistence: latency 1–10 s, jitter < 1 s · Emergency detection: latency 2–5 s
Second scenario of the same quality — emergency alerts, here under normal load
Source of Stimulus Internal
Stimulus Stochastic event: emergency for 75,000 devices within 10 s
Artifact System
Environment Normal Load
Response Persist the emergency, alert the emergency service
Response Measure Persistence: latency 1–10 s · Alerting the service: latency 10–20 s
The same scenario under overload — environment, event volume and measure shift together
Stimulus Stochastic event: emergency for > 125,000 devices within 10 s
Environment Overload
Response Measure Persistence: latency 1–30 s · Alerting the service: 60–120 s
Miss rate: may an emergency be lost at all?
The three parts that matter
Environment is the lever: the same quality is held to a different standard under normal load, peak load and overload — that is what makes it negotiable instead of utopian.
Artifact brings into focus what the quality refers to: the whole system, a process, storage, the communication path.
Response Measure is the bridge to testability. A response without a measure is a statement of intent.
04
Decomposition — how you get down
The use case is the tool that turns one coarse Stakeholder Requirement into several bounded features. Do not guess, derive: every path through the use case is a candidate for a feature of its own.
The procedure in five steps
Check the Stakeholder Requirement. Is there a user with a value behind it? Then User-Story format. Otherwise Requirements-Sentence format. And: which Business Objective does it trace to?
Write the coarse use case — one per Stakeholder Requirement: the complete success scenario, the alternative flows and the error cases.
Derive features — from the success scenario, from every alternative flow, from every variation. Every derived feature has to fit into one PI and is mapped back to the step or flow it came from.
Write a narrower use case per feature as its Acceptance Criteria — interaction, not UI design. Referring to controls that already exist is fine (“via the buttons on the steering wheel”); designing new ones is up to delivery.
Slice features into User Stories — one or more interactions from those Acceptance Criteria each — and write GWT statements per User Story.
05
System Boundaries
The boundary has to stand before the first System Requirements are written, at the latest: what belongs to the system, what is a neighbour — and which interfaces lie between? Without that answer you are writing requirements for something whose scope nobody knows.
What belongs in it: the system as one black box, the actors and the neighbouring systems.
What for: The black box fixes the scope — everything outside it is given.
By-product: Interfaces whose behavior is unclear or outside our control are the technical risks — they belong marked while the cut can still be changed.
06
Domain Model
A picture of the vocabulary: entities with their attributes and the relationships between them —
explicitly not UML. It serves the shared language, and reliably uncovers requirements nobody had written down.
When we model — and with whom
When
With whom
What for
At the Stakeholder Requirements
customer and users
Shared language and glossary — before anyone argues about requirements, agree on the terms.
At the System Requirements
product owner, product manager
Clarification and derivation: the model uncovers states, special cases and missing requirements. Or it serves to clarify requirements and remove ambiguities and inconsistencies.
In architecture and delivery
product owner, architect, development team
No further derivation — the model is mirrored.
07
Classification and what it drives
A requirement is either functional or a quality; qualities split into Operational Qualities (external, experienced by the user) and Developmental Qualities (internal). The category decides the format and the further refinement.
Category
Also known as
Format
Refined by
Check
Functional
Functional Requirement
User-Story format
Use Case → System Requirements (Features) → User Stories → GWT
Validation against the Business Objective
Operational Quality
External Non-Functional Requirement — experienced by the user: performance, availability, usability, security, compatibility
Requirements-Sentence format
Quality Scenarios — as AC of a feature or User Story, or as its own Operational Feature
Response Measure, measurable as a range
Developmental Quality
Internal Non-Functional Requirement — for development and maintenance: modularity, testability, reusability, analyzability
Requirements-Sentence format
Architecture Enabler → sys/SW/HW architecture
architecture decision
Constraint a requirement class under ISO, but not negotiable
The ISO 29148 criteria only partly apply at this level: a Stakeholder Requirement is by construction a bundle, so neither singular nor complete, and not yet verifiable. SMART fits better — but even of those,
only two criteria really apply here:
SMART
ISO 29148
What actually holds at the stakeholder level
Specificapplicable
Unambiguous / Singular
The User-Story format forces who, what, why and squeezes out vague wording. Here the requirement can be checked and improved immediately.
Relevantapplicable
Necessary
Is the requirement traced to a Business Objective? If not: gold-plating.
Decidable immediately as well, without any refinement.
Measurable
Verifiable
At this level not testable. Measurable only in the indirect sense that certain System Requirements have to be met.
Attainable
Feasible
The reality check only arrives with the refinement to System Requirements and below.
Time-bound
— not part of ISO
Only follows from the estimate: if it does not fit into a sprint or increment, it has to be split.
Why Stakeholder Requirements break the ISO criteria — and why that is fine
Complete / Singular: a bundle of functionality. Only refinement makes it singular and complete.
Unambiguous: broad by nature. The ambiguity is resolved by refining to System Requirements, not by rewording at this level.
Verifiable: Stakeholder Requirement ⇒ Validation (built the right thing?). System Requirement ⇒ Verification (built it right?).
08
The quality question
This is where we depart most clearly from both standards. SAFe hangs qualities into the Acceptance Criteria as NFRs; ISO 29148 does carry a quality type at system level but never elaborates it. Neither holds up once a quality affects several features — and that is the normal case.
The rule for which applies when
Exactly one affected feature — copying is fine. The quality belongs in that one feature’s Acceptance Criteria, just as SAFe intends.
Several affected features or User Stories — the Operational Quality becomes a type of its own, broken into Quality Scenarios that the affected features and User Stories reference.
The test: if changing one value would mean searching in more than one place, copying was the wrong call.
Where the departure comes from
Model
What it says about qualities
Where it does not hold
SAFe
NFRs are hung onto features and User Stories as Acceptance Criteria; they constrain the features but are not features themselves.
If a quality affects several features, its description is copied into every one of them.
ISO 29148
At System Requirement level the type Quality exists alongside
Functional and Constraint.
The standard does not spell out how a quality becomes concrete and checkable.
Our proposal
Operational Quality as a type of its own, broken into Quality Scenarios following the 6-part template — referenceable from features and User Stories.
Assumes the tool can hold references to several targets.
09
KANO — the second classification
Functional / Operational Quality / Developmental Quality says what kind a requirement is. KANO says something entirely different: what meeting it does to customer satisfaction. Both axes hold at once — a functional requirement can be basic, performance, delighter or indifferent.
Each curve shows how satisfaction rises as the same requirement moves from “not at all” to “fully implemented”. Basic starts at the very bottom and saturates without ever producing satisfaction · Performance runs linearly through the origin ·
Delighter starts close to zero — its absence bothers practically nobody — and then rises steeply. The Decayarrow shows how a feature sinks over time from delighter, through performance, down to basic.
The four categories
Category
When present
When missing
Smartphone example
Basic / Must-be Foundation
does not raise satisfaction — customers take it for granted
strong dissatisfaction
Being able to make calls; basic safety functions
Performance Linear Value
the more the better — directly and linearly
falling satisfaction, linear as well
Battery life; processor speed; storage
Delighter Wow factor
unexpected delight, competitive advantage
no dissatisfaction — it was not expected in the first place
AI integration; a fold-out projector; a free premium subscription
Indifferent Noise
little effect — the resources invested are wasted
little effect
pre-installed apps nobody uses
KANO as a search tool, not just a label
KANO is applied above all to Stakeholderand System Requirements. The real use is not only sorting what exists, but finding what is missing. A new product, for instance, should deliver Delighterrequirements that in turn contribute to particular Business Goals and Objectives. An existing product, conversely, will deliver several Performancerequirements over further releases. If too few are planned and delivered, the new version may find little favour with customers and users.
What the category means for the work
Basic: no prioritization discussion. If it is missing, the product is broken — the effort is to be spent, not negotiated.
Performance: belongs in a Quality Scenario with a response measure. “More is better” only becomes steerable once a range is attached.
Delighter: needs the trace to a Business Objective, otherwise it cannot be told apart from gold-plating.
Indifferent: drop it. The only category that comes with an unambiguous recommendation.
10
Format finder for the description
Pick level and classification — out comes the format, the refinement path and the attribute template.
Artifact
Format of the description
Parent reference
Acceptance Criteria
Attributes
Note
11
Structure & derivation at a glance
Where each artifact comes from, what it hangs on, what it is accepted against, and in what timeframe it should be finished.
Artifact
Comes from
Parent reference
Acceptance Criteria
Timeframe
Stakeholder Requirement SAFe: Epic
customer request, market requirement, standards and regulations
traces to a Business Objective
functional: Elaboration Use Case · quality: Quality Scenarios neither one is Acceptance Criteria
2–6 months
System Requirement SAFe: Feature
success scenario · alternative flow · variation of the stakeholder use case
belongs to the Stakeholder Requirement from whose use case it was derived
its own, narrower use case
1 PI, 8–12 weeks
User Story
one or more interactions from the feature’s Acceptance Criteria
Feature Parent
1..n GWT statements
1 Sprint, 2–4 weeks
Quality Scenario
of an Operational Quality, applied to a set of features or User Stories
the Operational Quality; plus the features and User Stories that form the stimulus