Was vorher fertig sein muss
Relevante Stakeholder mit Anforderungen an Qualitaetsattribute sind identifiziert (Business, Operations, Security, Compliance, Nutzer).
Eine grobe Architekturskizze und ein Architekturziel sind dokumentiert, sodass Quality Attribute Scenarios konkret werden koennen.
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit Spalten (Stakeholder, Quality Attribute, Szenario, Prioritaet); Vorlage fuer Quality Attribute Scenario (Source, Stimulus, Environment, Artifact, Response, Response Measure); Liste etablierter QA-Kategorien (Performance, Availability, Security, Usability, Modifiability, Testability, Interoperability).
Ein Facilitator mit QAW-Erfahrung; Architekt; ein Vertreter pro Stakeholder-Gruppe; Scribe; Decider mit Mandat fuer Prioritaeten.
Architekturkontext, geplante oder bestehende Systemskizze; bekannte SLA/SLO; rechtliche und Compliance-Constraints; Geschaeftsziele; Erkenntnisse aus aehnlichen Systemen.
1 Tag (6-8 h) fuer ein mittleres System
Quadrantenboard fuer Szenarien. Definition von Quality Attributes sichtbar machen. Szenario-Schablone gross drucken. Regel: Szenarien sind messbar und konkret, keine Wunschlisten.
Die eine Frage, die diese Methode beantwortet
Welche Quality Attributes mit welchen konkreten Szenarien sind fuer das System architekturkritisch, und in welcher Reihenfolge muessen sie adressiert werden?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Geschaeftskontext und Treiber | 45 min | Architekt praesentiert Systemkontext und Architekturziele (max 30 min). Stakeholder ergaenzen Geschaeftstreiber (Wachstum, Risiken, Compliance, Cost). Diese werden zur Quelle fuer Quality Attributes. | Wenn die Praesentation 90 min dauert, ist das Architekturpaket noch nicht reif. Workshop pausieren und Inception-Canvas nachholen. |
2Phase 2: Quality Attribute Brainstorm | 45 min | Pro Stakeholder Quality Attributes priorisieren (z. B. mit Quality Tree). Mindestens 7 Kategorien durchgehen, fokussieren auf 4-6 architekturrelevante. | Wenn alle 7 Attribute „hoch“ gewichtet werden, sind sie nicht priorisiert. Forcierte Verteilung (z. B. 2 High, 2 Medium, Rest Low) erzwingt Entscheidung. |
3Phase 3: Szenarien generieren | 120 min | Pro Top-Attribut 3-5 Szenarien. Strikte Schablone: Source, Stimulus, Environment, Artifact, Response, Response Measure. Beispiel: „Bei 5x Last-Spike (Stimulus) im Peak (Environment) reagiert Checkout-API (Artifact) mit p95 unter 800 ms (Response Measure).“ | Wenn Response Measure fehlt, ist es kein Szenario, sondern eine Hoffnung. Messbarkeit erzwingt Klarheit. |
4Phase 4: Priorisierung | 60 min | Szenarien gegen Geschaeftspriorisierung und Technikrisiko bewerten (z. B. High/Medium/Low x High/Medium/Low Matrix). Top-10-Szenarien als architekturkritisch markieren. | Decider muss sichtbar entscheiden. Konsensentscheidung in dieser Phase fuehrt zu Verwaesserung. Wenn unsicher, separate Vorbereitung und zweite Session. |
5Phase 5: Followups und Tactics | 60 min | Pro Top-Szenario erste architektonische Tactics skizzieren (Caching, Replikation, Auth-Pattern, Decoupling). Owner und Frist fuer Detailausarbeitung. Verknuepfung zu Architecture Decision Records. | QAW liefert kein Design, sondern Anforderungen plus erste Hinweise. ADRs entstehen separat, mit den Szenarien als Eingabe. |
Was am Ende rauskommt
QAW-Bericht mit Geschaeftstreibern, Quality Tree, priorisierter Szenarioliste (je nach Schablone), Bewertungsmatrix, Tactics-Skizzen und Followup-Tabelle mit ADR-Verweisen, Owner und Frist.
Pro Architekturzyklus eigener QAW-Bericht mit Datum. Szenarien als persistente Anforderungen, ueber Releases verfolgt. Aenderungen an Prioritaeten mit Begruendung und Decider-Signatur.
Kompakte Arbeitsvorlage für Quality Attribute Workshop mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Quality Attribute Workshop Arbeitsvorlage
## Ziel
Strukturierter Workshop für architekturkritische Quality Attributes und Szenarien.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Quality Scenarios:
- Priority List:
- Architecture Concerns:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Quality Attribute Workshop - Buchungs-Plattform Workspot, 15.05.2026
**Geschaeftstreiber**: Wachstumsziel 5x Buchungen in 12 Monaten. Erweiterung auf EU-weit. SLA 99.9%.
**Top Quality Attributes (priorisiert)**
1. Availability (High)
2. Performance (High)
3. Security (High)
4. Modifiability (Medium)
5. Interoperability (Medium)
**Architekturkritische Szenarien (Auszug)**
- QAS-01 (Performance): Bei 5x Standardlast (Stimulus) im Peak Friday 17-19 Uhr (Environment) antwortet die Buchungs-API (Artifact) mit p95 unter 600 ms (Response Measure).
- QAS-02 (Availability): Bei Ausfall einer AZ (Stimulus) im laufenden Betrieb (Environment) bleibt die Plattform (Artifact) mit max 2 min Recovery-Zeit verfuegbar (Response Measure).
- QAS-03 (Security): Bei Brute-Force-Versuch (Stimulus) auf Anmeldung (Artifact) sperrt das System nach 5 Fehlversuchen pro IP fuer 15 min (Response Measure).
- QAS-04 (Modifiability): Hinzufuegen einer neuen Zahlungsmethode (Stimulus) durch Backend-Team (Environment) ist in maximal 3 Personentagen ohne Aenderung anderer Module moeglich (Response Measure).
**Tactics-Skizzen**
- QAS-01: Edge-Caching, Read-Replicas. ADR-014 in Vorbereitung. Owner: @lisa.
- QAS-02: Multi-AZ-Deployment, Health-Probe-Threshold senken. ADR-015. Owner: @marcus.
- QAS-03: Rate Limiter mit IP-basierter Sperre. ADR-016. Owner: @ben.
**Decider**: @julia (CTO). Naechster Review: 30.06.2026.Symptome erkennen, gegensteuern
Eintraege sind „muss schnell sein“ oder „muss skalieren“ ohne Schwellwerte.
Schablone strikt erzwingen. Pro Szenario alle sechs Felder. Wenn Response Measure fehlt, nicht ins Artefakt aufnehmen.
Stakeholder priorisieren nichts, alles ist gleich wichtig.
Forcierte Verteilung. Maximal zwei Attribute auf High. Decider muss bei Patt entscheiden. Konsens ist nicht das Ziel.
Keine Business- oder Operations-Stakeholder dabei, Szenarien sind techniklastig.
Workshop nur mit mindestens einem Business-, Operations- und Security-Vertreter. Sonst vertagen oder Telefonkonferenz nachholen.
Diskussion springt in Loesungsdesign, Szenarien werden nicht zu Ende geschrieben.
Phase 5 erst nach abgeschlossener Priorisierung. Loesungsideen werden in Parkplatz gesammelt, nicht in Szenarien gemischt.
Szenarien bleiben im Bericht, Architektur-Entscheidungen referenzieren sie nicht.
Jede ADR enthaelt Verweise auf adressierte Szenarien. Bei Inkonsistenz Szenario aktualisieren oder ADR begruenden, warum es abweicht.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.