ARE Poster — From Stakeholder Requirement to Acceptance Criteria

Advanced Requirements Engineering

Deutsch·English A1 PDF

From Stakeholder Requirement
to Acceptance Criteria

One level down means: more concrete, smaller, closer to the solution. Everything up to the User Story stays implementation-free.

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

01

The Levels

— which artifact, which format, what it is accepted against
Problem space · the WHAT
ISO 29148 · Business Requirement Business Goal Mission, goals, opportunities not decomposed

Maximize the infotainment premium option take-rate to offset high localized manufacturing costs.

Has Business Objectives, but no children. Nothing below hangs under it — everything traces to it. No link ⇒ gold-plating.

Format Direction-Metric-Impact
Elevator Pitch
quantitative or qualitative Elaborated by Business Objectives — SMART
—Trace target of the Stakeholder Requirements
ISO 29148 · Stakeholder Requirement Stakeholder Requirement SAFe: Epic implementation-freeValidation

As a driver I want to make a phone call on the road so that I can go on driving.

Deliberately coarse — a bundle of functionality, neither singular nor complete. Of SMART, only Specific and Relevant apply here.

Format User-Story format functional
Requirements-Sentence Operational Quality Elaborated by Elaboration Use Case · or Quality Scenarios
— neither one is Acceptance Criteria
2–6 monthsStrategic Planning · T-shirt: S = 1 PI, M = 1–2 PI, L > 2 PI
ISO 29148 · System Requirement System Requirement SAFe: Feature implementation-freeVerification

As a driver I want to dial a phone number while driving so that I can talk to a partner while driving.

Must be bounded: fully developable and testable within a single PI. Special cases on the same level — Architecture Enabler and Operational Feature .

Format User-Story format
+ Problem Statement, + Benefit/Value Acceptance Criteria its own, narrower Use Case
1 PI · 8–12 weeksIncrement Planning · 3–5 Sprints
no counterpart in ISO 29148 User Story SAFe only implementation-free

As a driver I want to select the phone functions and the dialing option while driving so that I can type in a phone number.

Must span the subsystems and describe user interaction. “Update the CAN message matrix layer” would be the mistake that loses the value.

Format User-Story format
a single interaction, no more Acceptance Criteria 1..n GWT statements
1 Sprint · 2–4 weekssliced from the feature’s Acceptance Criteria
Solution space
ISO 29148 · System Element Requirement System Element Requirement SAFe: Implementation Task implementation-bound

The dialer service shall normalize the entered phone number to E.164 before handing it to the telephony stack.

Technical specification for software, hardware and their interfaces. Alongside it the Sub-System Requirement, which some organizations keep as well.

Formattechnical specification Acceptance Criteria—
outside the course scopeThe course ends one level above.
02

Classification

— it drives format and refinement
CategoryFormatRefined by
Functional User-Story format Use Case → Features → User Stories → GWT
Operational Quality
external, user-visible		 Requirements-Sentence format Quality Scenarios — as AC or as its own Operational Feature
Developmental Quality
internal, for build and maintenance		 Requirements-Sentence format Architecture Enabler → architecture
Constraint
Budget, schedule, law, technology		 Requirements Sentence with “will” nothing — Constraints are not decomposed
05

Decomposition

Stakeholder Requirement SAFe: Epic · User-Story format ① ELABORATE ELABORATION USE CASE · COCKBURN Trigger User indicates call wish Success 1. dials number 2. establishes call Scenario 3. accepts 4. talk 5. hangs up Alt.Flows 2a. no network 2b. busy 2c. rejected ② EVERY PATH ⇒ ONE FEATURE Feature Feature Feature Feature Steps 1–2 Steps 3–5 Flow 2a Flow 2b/2c ③ PER FEATURE Narrower Use Case = Acceptance Criteria Interaction, not UI design ④ SLICE User Story User Story User Story ⑤ 1..n GWT STATEMENTS PER USER STORY
03

The Formats

— the mapping is our proposal

User-Story format · Value Focus

As a <role / type of user> I want <to do this>, so that <I achieve this goal>.

Check: Is there a nameable user and a value for them?

Requirements-Sentence format · System Focus

[Condition] Subject Imperative Action Object [Constraint] shall binding requirement should goal or recommendation, not binding will stated intention → Constraints

Check: Is the obligation explicit — shall, should or will?

GWT format · Acceptance Criteria of the User Story

Given state of the world before the behavior When the behavior being specified Then the expected change that follows

Check: Can a test case be derived from it directly?

06

Quality Scenario

— six parts

Source of Stimulus who or what triggers it Stimulus WHEN which event Artifact which element is affected Environment GIVEN Normal · Peak · Overload Response THEN how the element reacts Response Measure Latency · Jitter · Miss Rate …

Environment is the lever

The same quality is held to a different standard under Normal, Peak and Overload — that is what makes it negotiable instead of utopian. A Response without a Response Measure is a statement of intent.
04

The Quality Question

SAFe · COPY PROPOSAL · REFERENCE Feature A < 200 ms Feature B < 200 ms Feature C < 200 ms The same number three times in three Acceptance Criteria. The copies drift apart. Feature A Feature B Feature C Quality Scenario < 200 ms One source of truth. Several features affected ⇒ its own Operational Feature.
07

KANO

— a search tool, not just a label
− SATISFACTION + FULFILLMENT →
Categorywhen it is missing
Basic taken for grantedstrong dissatisfaction
Performance the more the betterdrops linearly
Delighter competitive advantageno dissatisfaction
Indifferent Noiselittle effect — effort wasted

The real use: finding what is missing

A new product needs delighters that pay into Business Objectives. An existing one needs enough Performance requirements per release.