Quality Attribute Scenario

Details

Kernkonzepte:

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.
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).
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.
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.
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.
Schlüsselvertreter: Len Bass, Paul Clements, Rick Kazman („Software Architecture in Practice", SEI / Carnegie Mellon University)

arc42-Kapitel 10 (Qualitätsanforderungen) als testbare Aussagen statt als Adjektive schreiben
Aufbau eines ATAM-Utility-Tree, dessen Blätter priorisierte konkrete Szenarien sind
Spezifikation nicht-funktionaler Anforderungen, die QA später verifizieren muss
Wiederherstellung von Qualitätsanforderungen aus einem Brownfield-Codebase — das Response Measure aus einem literalen Schwellwert, Timeout oder Budget im Code ableiten