Skip to content

Commit 6383c31

Browse files
rdmuellerrdmueller
authored
Merge pull request #526 from raifdmueller/feat/quality-attribute-scenario-anchor
Add Quality Attribute Scenario anchor + wire into architecture contract
2 parents 7fa4ab0 + 701ec04 commit 6383c31

12 files changed

Lines changed: 165 additions & 11 deletions

File tree

‎docs/anchors/atam.adoc‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
= ATAM
22
:categories: software-architecture
33
:roles: software-architect, team-lead, product-owner
4-
:related: arc42, adr-according-to-nygard
4+
:related: arc42, adr-according-to-nygard, quality-attribute-scenario
55
:proponents: Rick Kazman, Mark Klein, Paul Clements
66
:tags: architecture evaluation, quality attributes, tradeoffs, utility tree, SEI, risk analysis
77
:tier: 3
@@ -44,4 +44,5 @@ Key Proponents:: Rick Kazman, Mark Klein, Paul Clements (SEI / Carnegie Mellon U
4444

4545
* <<arc42,arc42 Architecture Documentation>>
4646
* <<adr-according-to-nygard,ADR according to Nygard>>
47+
* <<quality-attribute-scenario,Quality Attribute Scenario>>
4748
====

‎docs/anchors/atam.de.adoc‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
= ATAM
22
:categories: software-architecture
33
:roles: software-architect, team-lead, product-owner
4-
:related: arc42, adr-according-to-nygard
4+
:related: arc42, adr-according-to-nygard, quality-attribute-scenario
55
:proponents: Rick Kazman, Mark Klein, Paul Clements
66
:tags: architecture evaluation, quality attributes, tradeoffs, utility tree, SEI, risk analysis
77

@@ -43,4 +43,5 @@ Schlüsselvertreter:: Rick Kazman, Mark Klein, Paul Clements (SEI / Carnegie Mel
4343

4444
* <<arc42,arc42 Architekturdokumentation>>
4545
* <<adr-according-to-nygard,ADR nach Nygard>>
46+
* <<quality-attribute-scenario,Quality Attribute Scenario>>
4647
====

‎docs/anchors/quality-attribute-scenario.adoc‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
= Quality Attribute Scenario
2+
:categories: software-architecture, requirements-engineering
3+
:roles: software-architect, business-analyst, product-owner, team-lead
4+
:related: atam, arc42, iso-25010, ears-requirements
5+
:proponents: Len Bass, Paul Clements, Rick Kazman
6+
:tags: quality attributes, quality requirements, scenarios, SEI, testable requirements, response measure
7+
:tier: 3
8+
9+
[%collapsible]
10+
====
11+
Full Name:: Quality Attribute Scenario
12+
13+
Also known as:: Quality Scenario, Six-Part Scenario
14+
15+
[discrete]
16+
== *Core Concepts*:
17+
18+
Purpose:: Turn a vague quality goal ("the system must be fast") into a concrete, testable statement. A scenario without a measurable response is a wish, not a requirement.
19+
20+
Six Parts:: Every scenario is specified through six elements: *Source* (the entity generating the stimulus), *Stimulus* (the condition arriving at the system), *Artifact* (the part of the system stimulated), *Environment* (the conditions under which it occurs — normal load, overload, startup, degraded mode), *Response* (the activity that results), *Response Measure* (the response quantified so the requirement is verifiable).
21+
22+
Response Measure:: The decisive part. Without a measure — a latency, a percentile, a throughput, a recovery time — a scenario cannot be tested and is not a requirement.
23+
24+
General vs. Concrete Scenarios:: A general scenario is a reusable template for a quality attribute; a concrete scenario instantiates it for one specific system with literal values.
25+
26+
Relation to Quality Attributes:: Scenarios make ISO/IEC 25010 characteristics operational — each characteristic (performance efficiency, reliability, security...) is expressed as one or more concrete scenarios.
27+
28+
Key Proponents:: Len Bass, Paul Clements, Rick Kazman ("Software Architecture in Practice", SEI / Carnegie Mellon University)
29+
30+
[discrete]
31+
== *When to Use*:
32+
33+
* Writing arc42 Chapter 10 quality requirements as testable statements rather than adjectives
34+
* Building an ATAM utility tree, where each leaf is a prioritized concrete scenario
35+
* Specifying non-functional requirements that QA must later verify
36+
* Recovering quality requirements from a brownfield codebase — deriving the response measure from a literal threshold, timeout, or budget in the code
37+
38+
[discrete]
39+
== *Related Anchors*:
40+
41+
* <<atam,ATAM>> — uses quality attribute scenarios as the leaves of its utility tree
42+
* <<arc42,arc42 Architecture Documentation>> — Chapter 10 quality requirements are expressed as scenarios
43+
* <<iso-25010,ISO/IEC 25010>> — the quality characteristics that scenarios make concrete
44+
* <<ears-requirements,EARS Requirements>> — a comparable discipline of making requirements precise and testable
45+
====

‎docs/anchors/quality-attribute-scenario.de.adoc‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
= Quality Attribute Scenario
2+
:categories: software-architecture, requirements-engineering
3+
:roles: software-architect, business-analyst, product-owner, team-lead
4+
:related: atam, arc42, iso-25010, ears-requirements
5+
:proponents: Len Bass, Paul Clements, Rick Kazman
6+
:tags: quality attributes, quality requirements, scenarios, SEI, testable requirements, response measure
7+
:tier: 3
8+
9+
[%collapsible]
10+
====
11+
Vollständiger Name:: Quality Attribute Scenario (Qualitätsattribut-Szenario)
12+
13+
Auch bekannt als:: Qualitätsszenario, Sechs-Teile-Szenario
14+
15+
[discrete]
16+
== *Kernkonzepte*:
17+
18+
Zweck:: Ein vages Qualitätsziel („das System muss schnell sein") in eine konkrete, testbare Aussage überführen. Ein Szenario ohne messbare Reaktion ist ein Wunsch, keine Anforderung.
19+
20+
Sechs Teile:: Jedes Szenario wird über sechs Elemente spezifiziert: *Source* (die auslösende Entität), *Stimulus* (das beim System ankommende Ereignis), *Artifact* (der angesprochene Systemteil), *Environment* (die Bedingungen — Normallast, Überlast, Start, degradierter Betrieb), *Response* (die resultierende Aktivität), *Response Measure* (die Reaktion quantifiziert, sodass die Anforderung prüfbar ist).
21+
22+
Response Measure:: Der entscheidende Teil. Ohne ein Maß — eine Latenz, ein Perzentil, einen Durchsatz, eine Recovery-Zeit — lässt sich ein Szenario nicht testen und ist keine Anforderung.
23+
24+
Allgemeine vs. konkrete Szenarien:: Ein allgemeines Szenario ist eine wiederverwendbare Schablone für ein Qualitätsattribut; ein konkretes Szenario instanziiert sie für ein bestimmtes System mit literalen Werten.
25+
26+
Bezug zu Qualitätsattributen:: Szenarien machen ISO/IEC-25010-Merkmale operationalisierbar — jedes Merkmal (Performance, Zuverlässigkeit, Sicherheit ...) wird als eines oder mehrere konkrete Szenarien ausgedrückt.
27+
28+
Schlüsselvertreter:: Len Bass, Paul Clements, Rick Kazman („Software Architecture in Practice", SEI / Carnegie Mellon University)
29+
30+
[discrete]
31+
== *Wann zu verwenden*:
32+
33+
* arc42-Kapitel 10 (Qualitätsanforderungen) als testbare Aussagen statt als Adjektive schreiben
34+
* Aufbau eines ATAM-Utility-Tree, dessen Blätter priorisierte konkrete Szenarien sind
35+
* Spezifikation nicht-funktionaler Anforderungen, die QA später verifizieren muss
36+
* Wiederherstellung von Qualitätsanforderungen aus einem Brownfield-Codebase — das Response Measure aus einem literalen Schwellwert, Timeout oder Budget im Code ableiten
37+
38+
[discrete]
39+
== *Verwandte Anker*:
40+
41+
* <<atam,ATAM>> — nutzt Qualitätsattribut-Szenarien als Blätter seines Utility Tree
42+
* <<arc42,arc42 Architekturdokumentation>> — Kapitel 10 (Qualitätsanforderungen) wird als Szenarien ausgedrückt
43+
* <<iso-25010,ISO/IEC 25010>> — die Qualitätsmerkmale, die Szenarien konkretisieren
44+
* <<ears-requirements,EARS Requirements>> — eine vergleichbare Disziplin, Anforderungen präzise und testbar zu machen
45+
====

‎docs/changelog.adoc‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,16 @@
22

33
A chronological record of all semantic anchors added to the catalog. Community contributors are credited with thanks.
44

5+
== 2026-05-22
6+
7+
*New anchors:*
8+
9+
* *Quality Attribute Scenario* — Bass, Clements & Kazman's six-part scenario format (SEI, *Software Architecture in Practice*) that turns a vague quality goal into a testable statement: Source, Stimulus, Artifact, Environment, Response, Response Measure; the Response Measure is what makes it verifiable. The format underlies arc42 Chapter 10 quality requirements and the leaves of an ATAM utility tree.
10+
11+
*Contract updates:*
12+
13+
* *Architecture Documentation* — now references the Quality Attribute Scenario anchor and requires Chapter 10 quality scenarios to be written in the six-part form with a literal Response Measure.
14+
515
== 2026-05-21
616

717
*Contract updates:*

‎plugins/semantic-anchors/skills/semantic-anchor-translator/references/catalog.md‎

Lines changed: 5 additions & 0 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

‎skill/semantic-anchor-translator/references/catalog.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -141,6 +141,11 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors
141141
- **Proponents:** Rick Kazman, Mark Klein, Paul Clements (SEI/CMU)
142142
- **Core:** Scenario-driven evaluation of software architectures against quality attributes; elicits stakeholder quality-attribute scenarios, maps them to architectural decisions, identifies sensitivity points, tradeoff points, and risks; produces a documented risk list and tradeoff catalog
143143

144+
### Quality Attribute Scenario
145+
- **Also known as:** Quality Scenario, Six-Part Scenario
146+
- **Proponents:** Len Bass, Paul Clements, Rick Kazman (SEI/CMU)
147+
- **Core:** Six-part template that turns a vague quality goal into a testable statement — Source, Stimulus, Artifact, Environment, Response, Response Measure; the Response Measure (a latency, percentile, throughput, recovery time) is what makes it verifiable; expresses arc42 Chapter 10 quality requirements and the leaves of an ATAM utility tree
148+
144149
### LASR by Toth/Zörner
145150
- **Also known as:** Layers–Aspects–Solution Strategy–Rationale
146151
- **Proponents:** Stefan Toth, Stefan Zörner

‎website/public/data/anchors.json‎

Lines changed: 37 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -79,7 +79,8 @@
7979
],
8080
"related": [
8181
"arc42",
82-
"adr-according-to-nygard"
82+
"adr-according-to-nygard",
83+
"quality-attribute-scenario"
8384
],
8485
"proponents": [
8586
"Rick Kazman",
@@ -2814,6 +2815,41 @@
28142815
"filePath": "docs/anchors/pyramid-principle.adoc",
28152816
"tier": 3
28162817
},
2818+
{
2819+
"id": "quality-attribute-scenario",
2820+
"title": "Quality Attribute Scenario",
2821+
"categories": [
2822+
"software-architecture",
2823+
"requirements-engineering"
2824+
],
2825+
"roles": [
2826+
"software-architect",
2827+
"business-analyst",
2828+
"product-owner",
2829+
"team-lead"
2830+
],
2831+
"related": [
2832+
"atam",
2833+
"arc42",
2834+
"iso-25010",
2835+
"ears-requirements"
2836+
],
2837+
"proponents": [
2838+
"Len Bass",
2839+
"Paul Clements",
2840+
"Rick Kazman"
2841+
],
2842+
"tags": [
2843+
"quality attributes",
2844+
"quality requirements",
2845+
"scenarios",
2846+
"SEI",
2847+
"testable requirements",
2848+
"response measure"
2849+
],
2850+
"filePath": "docs/anchors/quality-attribute-scenario.adoc",
2851+
"tier": 3
2852+
},
28172853
{
28182854
"id": "red-green-tdd",
28192855
"title": "Red/Green TDD",

‎website/public/data/categories.json‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -151,6 +151,7 @@
151151
"moscow",
152152
"prd",
153153
"problem-space-nvc",
154+
"quality-attribute-scenario",
154155
"user-story-mapping"
155156
]
156157
},
@@ -172,6 +173,7 @@
172173
"lasr",
173174
"lehmans-classification",
174175
"madr",
176+
"quality-attribute-scenario",
175177
"tracer-bullet",
176178
"vertical-slice-architecture",
177179
"walking-skeleton"

0 commit comments

Comments
 (0)