# Quality Attribute Workshop Report: [System name]

> Report of a Quality Attribute Workshop (QAW), the facilitated method published by the Software
> Engineering Institute (SEI) at Carnegie Mellon University in *Quality Attribute Workshops (QAWs),
> Third Edition* (technical report CMU/SEI-2003-TR-016). It records the eight workshop steps: the
> business and mission drivers, the architectural plan, the agreed architectural drivers, the raw
> scenarios, their consolidation and prioritisation, and the refined scenarios in the six-part
> form (source, stimulus, environment, artifact, response, response measure), followed by issues,
> traceability and next steps. Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Run a QAW early, before the architecture is fixed. Its job is to turn vague quality goals into
  concrete, prioritised scenarios that the architect can design for and that a later evaluation
  (for example ATAM) can reuse as seed scenarios.
- The scribe fills sections 4 to 11 live during the workshop; the QAW lead cleans the record up
  within a few working days and sends it to participants for correction.
- Keep raw scenarios as stated by stakeholders. Do not merge or reword them outside step 6, and
  record who proposed each one so merges can be agreed.
- Move the refined scenarios into Non-Functional Requirements and Quality Attribute Scenarios
  (`requirements/quality-attributes`) after the workshop; section 13 maps the IDs.
- Method steps follow the SEI report; explanations, tables and examples here are original wording.
-->

## Document control

<!-- Guidance: Identify the workshop and the system. If several QAWs are held for one system (for example per region or stakeholder community), give each its own report and consolidate in section 13. -->

| Field | Value |
|---|---|
| Document ID | [QAW-YYYY-NNN] |
| System | [System name and short description] |
| Lifecycle stage | [Concept / Acquisition / Early design / Re-architecture] |
| Workshop date and location | YYYY-MM-DD, [Room or video platform] |
| Workshop format | [In person / Remote / Hybrid]; [one day / two half days] |
| Sponsor | [@sponsor] |
| QAW lead (facilitator) | [@qaw-lead] |
| QAW scribe | [@scribe] |
| Version | [0.1] |
| Status | [Draft from workshop / Reviewed by participants / Final] |
| Owner | [@qaw-lead] |
| Approvers / reviewers | [@sponsor], [@lead-architect] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Sponsor | [@name] | [Accepted / Accepted with comments] | YYYY-MM-DD |
| QAW lead | [@name] | [Prepared] | YYYY-MM-DD |
| Lead architect | [@name] | [Reviewed] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Keep the raw workshop record as version 0.1 so later edits can be compared with what stakeholders actually said. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@scribe] | Raw record from the workshop |
| 0.2 | YYYY-MM-DD | [@qaw-lead] | *Example:* Cleaned up; refinements completed for top five scenarios; sent to participants |
| 1.0 | YYYY-MM-DD | [@qaw-lead] | *Example:* Participant corrections applied; accepted by sponsor |

## Contents

1. [Workshop summary](#1-workshop-summary)
2. [Context and preparation](#2-context-and-preparation)
3. [Participants and roles](#3-participants-and-roles)
4. [Step 1: QAW presentation and introductions](#4-step-1-qaw-presentation-and-introductions)
5. [Step 2: Business and mission presentation](#5-step-2-business-and-mission-presentation)
6. [Step 3: Architectural plan presentation](#6-step-3-architectural-plan-presentation)
7. [Step 4: Identification of architectural drivers](#7-step-4-identification-of-architectural-drivers)
8. [Step 5: Scenario brainstorming](#8-step-5-scenario-brainstorming)
9. [Step 6: Scenario consolidation](#9-step-6-scenario-consolidation)
10. [Step 7: Scenario prioritisation](#10-step-7-scenario-prioritisation)
11. [Step 8: Scenario refinement](#11-step-8-scenario-refinement)
12. [Issues, assumptions and conflicts](#12-issues-assumptions-and-conflicts)
13. [Coverage and traceability](#13-coverage-and-traceability)
14. [Next steps and use of results](#14-next-steps-and-use-of-results)
15. [Facilitation notes](#15-facilitation-notes)
16. [Glossary and references](#16-glossary-and-references)

## 1. Workshop summary

<!-- Guidance: Half a page for the sponsor: who took part, how many scenarios, the top priorities and the main issues. Write it last. -->

[*Example:* "On YYYY-MM-DD, twelve stakeholders of the Field Service Scheduling System took part in
a one-day QAW. They agreed nine architectural drivers, proposed 31 raw scenarios, consolidated
them to 27 and prioritised them by vote. The five highest-voted scenarios were refined: offline
operation of the technician app, schedule recalculation at morning peak, onboarding a new
subcontractor partner, recovery from loss of the dispatch database, and protection of customer
addresses. The workshop surfaced a conflict between the operations team's expectation of
24-hour offline operation and the security team's requirement to revoke devices within one hour.
Results feed the architecture design starting YYYY-MM-DD and will seed a later ATAM."]

| Measure | Value |
|---|---|
| Stakeholders participating (voting) | [*Example:* 12] |
| Architectural drivers agreed | [*Example:* 9 (AD-01 to AD-09)] |
| Raw scenarios proposed | [*Example:* 31] |
| Scenarios after consolidation | [*Example:* 27] |
| Votes per stakeholder | [*Example:* 8] |
| Scenarios refined | [*Example:* 5 (QAW-SC-01 to QAW-SC-05)] |
| Issues raised | [*Example:* 6 (ISS-01 to ISS-06)] |

## 2. Context and preparation

<!-- Guidance: Record why the workshop was held and what was prepared. A QAW without a participants handbook and pre-briefed presenters spends the morning on basics. -->

### 2.1 Purpose and scope

| Item | Value |
|---|---|
| Reason for the workshop | [*Example:* Replace a 15-year-old scheduling system; quality goals stated only as "fast, secure, reliable"] |
| System scope | [*Example:* Job intake, scheduling engine, technician mobile app, partner portal, customer notifications] |
| Out of scope | [*Example:* Billing, stock replenishment] |
| Decisions the results inform | [*Example:* Architecture style, offline strategy, partner integration approach, request for proposal quality requirements] |
| Earlier work used | [*Example:* Business case v1.1, current-state assessment, incident history] |

### 2.2 Preparation checklist

- [ ] Sponsor agreed purpose, scope and date; stakeholder list confirmed (section 3).
- [ ] Participants handbook sent at least one week before, with example quality attributes, questions and scenarios adapted to the domain.
- [ ] Business and mission presenter briefed on the content expected in step 2 (about one hour).
- [ ] Technical presenter briefed on the content expected in step 3 (plans, constraints, context diagrams).
- [ ] Scribe has this template open and a shared screen or wall for the raw scenario list.
- [ ] Voting method chosen (dots, cards or an online poll) and tested for remote participants.

### 2.3 Agenda

| Time *(Example)* | Step | Duration |
|---|---|---|
| 09:00 | Step 1: QAW presentation and introductions | 30 min |
| 09:30 | Step 2: Business and mission presentation | 60 min |
| 10:30 | Step 3: Architectural plan presentation | 45 min |
| 11:15 | Break while facilitators consolidate driver notes | 15 min |
| 11:30 | Step 4: Identification of architectural drivers | 30 min |
| 12:00 | Lunch | 45 min |
| 12:45 | Step 5: Scenario brainstorming (at least two round-robin passes) | 90 min |
| 14:15 | Step 6: Scenario consolidation | 30 min |
| 14:45 | Step 7: Scenario prioritisation (two voting passes) | 30 min |
| 15:15 | Step 8: Scenario refinement, highest priority first | 105 min |
| 17:00 | Close: next steps and how the report will be circulated | 15 min |

## 3. Participants and roles

<!-- Guidance: The SEI report describes a workshop of roughly 5 to 30 stakeholders (check the report for its exact guidance) and at least two facilitators in the lead and scribe roles. Check that every stakeholder class that uses, builds, runs, pays for or is affected by the system is present. -->

### 3.1 Facilitation team

| Role | Name | Responsibilities |
|---|---|---|
| QAW lead | [@name] | Runs the steps on time, keeps discussion on quality attributes, guides voting and refinement |
| QAW scribe | [@name] | Captures drivers, raw scenarios, votes, refinements and issues in this report |
| Timekeeper *(optional, local addition)* | [@name] | Signals time per step; supports remote participants |

### 3.2 Stakeholders

| ID | Name | Role and organisation | Stakeholder class | Present for |
|---|---|---|---|---|
| P-01 *(Example)* | [@name] | Head of field operations (business presenter) | Business owner | All steps |
| P-02 *(Example)* | [@name] | Lead architect (technical presenter) | Architect | All steps |
| P-03 *(Example)* | [@name] | Dispatcher team lead | End user | All steps |
| P-04 *(Example)* | [@name] | Senior field technician | End user | All steps |
| P-05 *(Example)* | [@name] | Partner manager | Business user, partner liaison | All steps |
| P-06 *(Example)* | [@name] | Security architect | Security | All steps |
| P-07 *(Example)* | [@name] | Data protection officer | Compliance | Steps 1 to 7 |
| P-08 *(Example)* | [@name] | Platform operations lead | Operator | All steps |
| P-09 *(Example)* | [@name] | Service desk manager | Support | All steps |
| P-10 *(Example)* | [@name] | Customer experience manager | Customer proxy | All steps |
| P-11 *(Example)* | [@name] | Mobile engineering lead | Developer | All steps |
| P-12 *(Example)* | [@name] | Procurement lead | Acquirer | All steps |
| [P-nn] | [@name] | [Role] | [Class] | [Steps] |

Stakeholder classes not represented, and how their concerns were covered: [*Example:* Trainers
were not available; the service desk manager (P-09) represented training concerns, and training
scenarios are to be validated with the training lead after the workshop (ISS-06).]

## 4. Step 1: QAW presentation and introductions

<!-- Guidance: Record that the method was explained and who introduced themselves. Note any participant who joined late, because they missed the scenario rules. -->

| Item | Record |
|---|---|
| Method briefing given by | [@qaw-lead] |
| Ground rules agreed | [*Example:* Phones away; one conversation at a time; parking lot for out-of-scope topics; facilitators may cut discussions to keep time] |
| Late arrivals or early departures | [*Example:* P-07 left after step 7; votes recorded] |
| Notes | [Any questions about the method] |

## 5. Step 2: Business and mission presentation

<!-- Guidance: Capture business context, high-level functions, constraints and the quality attribute expectations the presenter states or implies. Most refined quality attributes later come from here. -->

Presenter: [@P-01]. Summary of the business and mission context: [*Example:* "The company runs
2,400 field technicians across four countries and plans to grow subcontractor capacity to 30% of
jobs within two years. Same-day service is the main differentiator. The current system fails
on Monday mornings and offers no partner access."]

| ID | Business or mission driver | Quality attributes implied | Notes from presentation |
|---|---|---|---|
| BD-01 *(Example)* | Offer same-day appointments in all regions | Performance, availability | Morning reschedule must finish before technicians leave depots |
| BD-02 *(Example)* | Grow subcontractor share to 30% of jobs | Interoperability, modifiability, security | Partners use their own tools |
| BD-03 *(Example)* | Technicians work in areas with no mobile coverage | Availability (offline), usability | Basements, rural sites |
| BD-04 *(Example)* | Comply with data protection law for customer addresses and access codes | Security, privacy | Access codes for buildings are sensitive |
| BD-05 *(Example)* | Cut support calls about lost jobs by half | Reliability, observability | Current top complaint |
| [BD-nn] | [Driver] | [Attributes] | [Notes] |

## 6. Step 3: Architectural plan presentation

<!-- Guidance: A detailed architecture may not exist yet. Capture plans, key technical constraints and any context diagram shown. Note uncertainties; they often become exploratory scenarios. -->

Presenter: [@P-02]. Summary: [*Example:* "The plan is a cloud-hosted scheduling service with a
native mobile app, an event backbone for job state changes, and a partner API. The optimisation
engine is a commercial solver. The current system stays read-only for two years for history."]

```mermaid
flowchart LR
  CUST[Customers] --> INT[Job intake]
  DISP[Dispatchers] --> SCH[Scheduling service with solver]
  INT --> SCH
  SCH --> EVT[(Job event backbone)]
  EVT --> APP[Technician mobile app, offline capable]
  EVT --> PAPI[Partner API]
  PAPI --> PART[Subcontractor systems]
  EVT --> NOTIF[Customer notifications]
  SCH --> LEG[(Legacy system, read-only history)]
```

| ID | Technical constraint or plan element | Source | Effect on quality attributes |
|---|---|---|---|
| TC-01 *(Example)* | Must run on the company's existing cloud landing zone | IT policy | Limits hosting options; inherits identity and network controls |
| TC-02 *(Example)* | Commercial solver licensed per CPU core | Procurement | Performance scaling has a direct licence cost |
| TC-03 *(Example)* | Technician devices are company-managed phones | Mobile policy | Enables device revocation; limits app storage |
| TC-04 *(Example)* | Partners connect over a public API with OAuth 2.0 client credentials | Security standard | Partner onboarding effort and security model |
| [TC-nn] | [Constraint] | [Source] | [Effect] |

## 7. Step 4: Identification of architectural drivers

<!-- Guidance: During the break, the facilitators merge their notes from steps 2 and 3 into a draft list. Stakeholders then correct, add and delete until they agree. Keep the list short (typically 5 to 12); it is the coverage check for brainstorming. -->

| ID | Architectural driver | Type | From | Stakeholder changes during step 4 |
|---|---|---|---|---|
| AD-01 *(Example)* | Morning reschedule of all jobs completes before depot departure | Quality attribute (performance) | BD-01 | Time window confirmed as 06:00 to 06:30 by P-03 |
| AD-02 *(Example)* | Technicians keep working through coverage gaps | Quality attribute (availability, offline) | BD-03 | Added "including job completion and photos" by P-04 |
| AD-03 *(Example)* | New partners connect without core changes | Quality attribute (modifiability, interoperability) | BD-02 | None |
| AD-04 *(Example)* | Customer addresses and access codes are protected end to end | Quality attribute (security, privacy) | BD-04 | P-07 added retention limits |
| AD-05 *(Example)* | No job is lost between intake, scheduling and the technician | Quality attribute (reliability) | BD-05 | None |
| AD-06 *(Example)* | Operations can see where a job is stuck | Quality attribute (observability) | BD-05 | Added by P-08 |
| AD-07 *(Example)* | Run on existing landing zone | Constraint | TC-01 | None |
| AD-08 *(Example)* | Solver licence cost scales with cores | Constraint | TC-02 | None |
| AD-09 *(Example)* | Support four languages and regional date and address formats | High-level requirement | Step 2 discussion | Added by P-10 |
| [AD-nn] | [Driver] | [Quality attribute / Constraint / High-level requirement / Business driver] | [BD-nn, TC-nn] | [Changes] |

## 8. Step 5: Scenario brainstorming

<!-- Guidance: Collect scenarios round-robin, at least two passes so each stakeholder contributes at least two. Each scenario needs at least a stimulus, environment and response. Cover all three scenario types and every driver in section 7. Pitfall: accepting "the system must be secure" as a scenario; ask for a concrete example. -->

Scenario types: **use case** (expected use of the system), **growth** (expected change to the
system), **exploratory** (unexpected stress, use or change).

| ID | Raw scenario (as stated) | Proposed by | Type | Drivers |
|---|---|---|---|---|
| RS-01 *(Example)* | A dispatcher drags a job to another technician and sees the new route within two seconds | P-03 | Use case | AD-01 |
| RS-02 *(Example)* | A customer cancels online and the technician's app removes the job before they set off | P-10 | Use case | AD-05 |
| RS-03 *(Example)* | At 06:00 on a Monday, 9,000 jobs are re-optimised and every technician has a route by 06:30 | P-01 | Use case | AD-01, AD-08 |
| RS-04 *(Example)* | A technician in a basement completes a job with photos and signature, and it syncs when signal returns | P-04 | Use case | AD-02 |
| RS-05 *(Example)* | A partner sends 500 job updates in one minute after a system outage on their side | P-05 | Exploratory | AD-03, AD-05 |
| RS-06 *(Example)* | The solver vendor is replaced by another solver within six months | P-12 | Growth | AD-03, AD-08 |
| RS-07 *(Example)* | A technician works a full shift with no coverage and nothing is lost | P-04 | Use case | AD-02 |
| RS-08 *(Example)* | A lost phone is revoked and its stored access codes become unreadable | P-06 | Use case | AD-04 |
| RS-09 *(Example)* | Operations finds the cause of a stuck job within 15 minutes of a support call | P-08 | Use case | AD-06 |
| RS-10 *(Example)* | A new country with a fifth language is added | P-10 | Growth | AD-09 |
| RS-11 *(Example)* | A partner's API credentials leak and are used from an unknown network | P-06 | Exploratory | AD-04 |
| RS-12 *(Example)* | A new subcontractor goes live using only the published API and sandbox | P-05 | Growth | AD-03 |
| RS-13 *(Example)* | A technician with an old phone model opens the job list | P-11 | Use case | AD-02 |
| RS-14 *(Example)* | Job volume doubles during a heatwave | P-01 | Growth | AD-01, AD-08 |
| RS-15 *(Example)* | The primary dispatch database fails at 07:00 on a weekday | P-08 | Exploratory | AD-05 |
| RS-16 *(Example)* | A customer asks for all data held about them | P-07 | Use case | AD-04 |
| [RS-17 to RS-31] | [Remaining raw scenarios, one row each] | [P-nn] | [Type] | [AD-nn] |

Driver coverage check: every driver AD-01 to AD-09 has at least one raw scenario: [Yes / No; list
gaps and the scenarios added to close them].

## 9. Step 6: Scenario consolidation

<!-- Guidance: Merge only scenarios that are very similar, and only when their proposers agree. Merging prevents votes being split between near-duplicates. Most scenarios should stay as they are. -->

| Merged scenario | Raw scenarios merged | Agreed by | Merged wording |
|---|---|---|---|
| RS-07 *(Example)* | RS-04, RS-07 | P-04 | A technician works a full shift with no coverage, completes jobs with photos and signatures, and nothing is lost when signal returns |
| RS-03 *(Example)* | RS-03, RS-19 | P-01, P-03 | At 06:00 on a Monday, 9,000 jobs are re-optimised and every technician has a route by 06:30 |
| RS-12 *(Example)* | RS-12, RS-23 | P-05, P-12 | A new subcontractor goes live using only the published API, documentation and sandbox |
| RS-21 *(Example)* | RS-21, RS-28 | P-06, P-07 | An attacker with a stolen dispatcher session tries to export customer addresses in bulk |
| [RS-nn] | [RS-nn, RS-nn] | [P-nn] | [Wording] |

Result: [*Example:* 31 raw scenarios consolidated to 27 by four merges, each removing one
scenario.]

## 10. Step 7: Scenario prioritisation

<!-- Guidance: The SEI method gives each stakeholder a number of votes equal to about 30% of the consolidated scenarios, rounded to an even number by the facilitators, and votes in two round-robin passes using half the votes each time. Stakeholders may place several votes on one scenario. Facilitators do not vote. -->

### 10.1 Vote allocation

| Item | Value |
|---|---|
| Scenarios after consolidation (N) | [*Example:* 27] |
| 30% of N | [*Example:* 8.1] |
| Votes per stakeholder (even number) | [*Example:* 8, four per pass] |
| Voting stakeholders | [*Example:* 12] |
| Total votes cast | [*Example:* 96] |

### 10.2 Results

| Rank | Scenario | Short description | Type | Votes |
|---|---|---|---|---|
| 1 *(Example)* | RS-07 | Full shift with no coverage, nothing lost | Use case | 14 |
| 2 *(Example)* | RS-03 | Monday 06:00 re-optimisation of 9,000 jobs by 06:30 | Use case | 12 |
| 3 *(Example)* | RS-12 | New subcontractor live using only API and sandbox | Growth | 11 |
| 4 *(Example)* | RS-21 | Bulk export attempt with stolen dispatcher session | Exploratory | 10 |
| 5 *(Example)* | RS-15 | Dispatch database fails at 07:00 | Exploratory | 9 |
| 6 *(Example)* | RS-02 | Customer cancellation reaches technician before departure | Use case | 7 |
| 7 *(Example)* | RS-09 | Cause of stuck job found within 15 minutes | Use case | 6 |
| 8 *(Example)* | RS-25 | Solver licence cost stays within budget when volume doubles | Growth | 5 |
| 9 to 27 *(Example)* | 19 other scenarios | Listed in the appendix of the raw record | Mixed | 22 |
| | | | Total | 96 |

Observations: [*Example:* "Offline operation and the morning peak dominate. The security
scenario RS-21 ranked fourth although only two security specialists attended, which shows broad
concern. No modifiability scenario except partner onboarding reached the top eight, so solver
replacement (RS-06, 2 votes) may need sponsor attention outside the vote."]

## 11. Step 8: Scenario refinement

<!-- Guidance: Refine the highest-priority scenarios, in rank order, until time runs out (usually four or five). For each, record the six parts, the business goals affected, the quality attributes, and the stakeholders' questions and issues. Make the response measure testable: how long, how much, how often, under what conditions. -->

### 11.1 QAW-SC-01 Full shift offline *(Example)*

| Field | Content |
|---|---|
| Raw scenario | RS-07 (merged with RS-04) |
| Business goals | BD-03, BD-05 |
| Quality attributes | Availability (offline operation), reliability, usability |
| Source of stimulus | Field technician |
| Stimulus | Loses mobile data coverage at the start of the shift and regains it at the end |
| Environment | Normal working day; up to 10 jobs assigned; device battery above 20% |
| Artifact | Technician mobile app and its synchronisation service |
| Response | The technician views, starts and completes all assigned jobs, captures photos and signatures; on reconnection all changes upload and conflicts with dispatcher changes are shown to the dispatcher |
| Response measure | 100% of job completions and attachments preserved; upload of a full day's data (up to 200 MB) completes within 10 minutes on 4G; conflicts presented within 1 minute of sync |
| Questions | How long can a revoked device keep cached access codes? What happens if the dispatcher reassigns an offline job? |
| Issues | ISS-01 (conflict with lost-device revocation, RS-08) |

### 11.2 QAW-SC-02 Monday morning re-optimisation *(Example)*

| Field | Content |
|---|---|
| Raw scenario | RS-03 (merged with RS-19) |
| Business goals | BD-01 |
| Quality attributes | Performance, scalability, cost |
| Source of stimulus | Scheduled job at 06:00 |
| Stimulus | Full re-optimisation of all open jobs for the day |
| Environment | Peak day: 9,000 jobs, 2,400 technicians, overnight cancellations and new urgent jobs |
| Artifact | Scheduling service and solver |
| Response | Routes are computed and pushed to every technician app and dispatcher screen |
| Response measure | All routes available by 06:30; solver cost for the run within the licensed core count |
| Questions | Can the run be split by region to start earlier? Is a near-optimal answer at 06:20 better than an optimal one at 06:35? |
| Issues | ISS-02 (licence model limits scaling) |

### 11.3 QAW-SC-03 Self-service partner onboarding *(Example)*

| Field | Content |
|---|---|
| Raw scenario | RS-12 (merged with RS-23) |
| Business goals | BD-02 |
| Quality attributes | Interoperability, modifiability, usability of the API |
| Source of stimulus | New subcontractor's developer |
| Stimulus | Wants to receive jobs and send status updates from the partner's own system |
| Environment | Production API published; sandbox available; no core team engineer assigned |
| Artifact | Partner API, documentation, sandbox and onboarding process |
| Response | The partner registers, tests in the sandbox, passes conformance checks and goes live |
| Response measure | Live within 10 working days; zero changes to core scheduling code; at most one support ticket |
| Questions | Who approves a partner for production? Are partner-specific job fields allowed? |
| Issues | ISS-03 (partner contract terms not yet defined) |

### 11.4 QAW-SC-04 Bulk export with a stolen session *(Example)*

| Field | Content |
|---|---|
| Raw scenario | RS-21 (merged with RS-28) |
| Business goals | BD-04 |
| Quality attributes | Security, privacy, auditability |
| Source of stimulus | External attacker holding a valid dispatcher session token |
| Stimulus | Requests customer addresses and access codes for all jobs in a region |
| Environment | Normal operation, office hours |
| Artifact | Dispatcher web application and job data API |
| Response | The request is limited to the dispatcher's assigned region and page size; anomalous volume is blocked, the session revoked and the security team alerted; the event is logged |
| Response measure | No more than 50 records disclosed; alert raised within 2 minutes; session revoked within 5 minutes; access codes never returned in list views |
| Questions | Should the same volume limit apply to partner API tokens (RS-11)? Which roles may ever see access codes in full? |
| Issues | ISS-04 |

### 11.5 QAW-SC-05 Dispatch database failure *(Example)*

| Field | Content |
|---|---|
| Raw scenario | RS-15 |
| Business goals | BD-01, BD-05 |
| Quality attributes | Availability, reliability, recoverability |
| Source of stimulus | Infrastructure fault |
| Stimulus | The primary dispatch database becomes unavailable |
| Environment | Weekday 07:00, technicians already on the road, peak job updates |
| Artifact | Dispatch database and the services that write to it |
| Response | Service fails over to a replica; technician apps keep working offline; no committed job update is lost; dispatchers see a degraded-mode banner |
| Response measure | Dispatcher functions restored within 5 minutes; zero committed updates lost; technician apps unaffected |
| Questions | Does the event backbone buffer updates during failover? |
| Issues | ISS-05 |

## 12. Issues, assumptions and conflicts

<!-- Guidance: Record every issue raised during refinement or discussion with an owner. Conflicts between scenarios are valuable outputs: they are the first tradeoffs the architect must resolve. -->

| ID | Issue, assumption or conflict | Scenarios | Raised by | Owner | Resolution path |
|---|---|---|---|---|---|
| ISS-01 *(Example)* | Conflict: 24-hour offline operation vs revocation of a lost device within one hour | QAW-SC-01, RS-08 | P-06 | [@lead-architect] | Design option study; decision record by YYYY-MM-DD |
| ISS-02 *(Example)* | Solver licence per core may make peak scaling too costly | QAW-SC-02 | P-12 | [@procurement] | Ask vendors for burst pricing |
| ISS-03 *(Example)* | Partner contract does not yet define API service levels | QAW-SC-03 | P-05 | [@partner-manager] | Draft terms with legal |
| ISS-04 *(Example)* | Assumption: dispatchers only need their own region's data | QAW-SC-04 | P-03 | [@head-of-operations] | Confirm with regional leads |
| ISS-05 *(Example)* | Unclear whether the event backbone is in scope of the platform team's on-call | QAW-SC-05 | P-08 | [@platform-lead] | Clarify in operations model |
| ISS-06 *(Example)* | Training stakeholders absent | All | QAW lead | [@qaw-lead] | Validate scenarios with training lead |
| [ISS-nn] | [Issue] | [QAW-SC-nn / RS-nn] | [P-nn] | [@owner] | [Path] |

## 13. Coverage and traceability

<!-- Guidance: Show that drivers are covered by prioritised scenarios and where each refined scenario goes next. Drivers with no scenario in the top ranks need a decision: accept the gap, or refine more scenarios after the workshop. -->

### 13.1 Driver coverage

| Driver | Raw scenarios | Highest rank | Refined scenario | Coverage |
|---|---|---|---|---|
| AD-01 *(Example)* | RS-01, RS-03, RS-14 | 2 | QAW-SC-02 | Covered |
| AD-02 *(Example)* | RS-07, RS-13 | 1 | QAW-SC-01 | Covered |
| AD-03 *(Example)* | RS-05, RS-06, RS-12 | 3 | QAW-SC-03 | Covered |
| AD-04 *(Example)* | RS-08, RS-11, RS-16, RS-21 | 4 | QAW-SC-04 | Covered |
| AD-05 *(Example)* | RS-02, RS-05, RS-15 | 5 | QAW-SC-05 | Covered |
| AD-06 *(Example)* | RS-09 | 7 | None | Gap: refine RS-09 after the workshop |
| AD-07 *(Example)* | None (constraint) | n/a | None | Constraint only |
| AD-08 *(Example)* | RS-03, RS-06, RS-14, RS-25 | 2 | QAW-SC-02 (cost measure) | Partly covered |
| AD-09 *(Example)* | RS-10 | Not in top 8 | None | Gap: accepted by sponsor |
| [AD-nn] | [RS-nn] | [Rank] | [QAW-SC-nn] | [Covered / Partly / Gap] |

### 13.2 Where refined scenarios go next

| Refined scenario | Requirements catalogue ID | ATAM seed scenario | Fitness function or test | Evaluation |
|---|---|---|---|---|
| QAW-SC-01 *(Example)* | QAS-RE-03 | S-01 | Offline end-to-end test on device farm | Seed for ATAM |
| QAW-SC-02 *(Example)* | QAS-PE-04 | S-02 | FF-nn: nightly re-optimisation benchmark against 06:30 deadline | Seed for ATAM |
| QAW-SC-03 *(Example)* | QAS-CO-02 | S-03 | Partner conformance test suite | Seed for ATAM |
| QAW-SC-04 *(Example)* | QAS-SE-05 | S-04 | Abuse-case test; rate-limit alert drill | Threat model input |
| QAW-SC-05 *(Example)* | QAS-RE-04 | S-05 | Failover game day | Seed for ATAM |
| [QAW-SC-nn] | [QAS-xx-nn] | [S-nn] | [FF-nn / test] | [Use] |

Target documents: Non-Functional Requirements and Quality Attribute Scenarios
(`requirements/quality-attributes`) for the catalogue IDs, Architecture Evaluation Report (ATAM)
(`architecture/atam-evaluation`) for seed scenarios, Architecture Fitness Functions
(`architecture/fitness-functions`) for automated checks, Threat Model (`security/threat-model`)
for abuse cases, and Architecture Evaluation Plan and Report (`architecture/architecture-evaluation-42030`)
where the scenarios support a formal evaluation.

## 14. Next steps and use of results

<!-- Guidance: The SEI report lists several uses for QAW results, from refining requirements to driving prototypes and tests. Pick the ones that apply, give each an owner and a date. -->

| ID | Action | Uses result | Owner | Due |
|---|---|---|---|---|
| NXT-01 *(Example)* | Circulate this report for participant corrections within five working days | All | [@qaw-lead] | YYYY-MM-DD |
| NXT-02 *(Example)* | Add QAW-SC-01 to QAW-SC-05 to the requirements catalogue with acceptance criteria | Refine requirements | [@business-analyst] | YYYY-MM-DD |
| NXT-03 *(Example)* | Refine RS-09 and RS-02 in a 90-minute follow-up session | Close coverage gaps | [@qaw-lead] | YYYY-MM-DD |
| NXT-04 *(Example)* | Prototype offline sync with conflict handling to test ISS-01 options | Guide prototypes | [@mobile-lead] | YYYY-MM-DD |
| NXT-05 *(Example)* | Use the scenarios to order architecture work: offline and scheduling first | Influence architecture order | [@lead-architect] | YYYY-MM-DD |
| NXT-06 *(Example)* | Include the refined scenarios as quality requirements in the request for proposal | Acquisition | [@procurement] | YYYY-MM-DD |
| NXT-07 *(Example)* | Plan an ATAM once a candidate architecture exists, seeded with these scenarios | Later evaluation | [@sponsor] | YYYY-MM-DD |
| [NXT-nn] | [Action] | [Use] | [@owner] | YYYY-MM-DD |

## 15. Facilitation notes

<!-- Guidance: Lessons for the next QAW. Keep them practical; they improve the method in your organisation over time. -->

### 15.1 What to watch for during the steps

- **Requirements disguised as scenarios.** When a stakeholder says "the system shall send notifications", ask which quality matters: how fast, how reliably, under what load. Keep the requirement and add the quality angle.
- **Attribute name debates.** Do not spend time arguing whether something is "reliability" or "availability". A precise scenario matters more than the label.
- **Missing types.** If brainstorming yields only use case scenarios, prompt for growth ("what will change in two years?") and exploratory ones ("what would break you?").
- **Over-merging.** Merge only near-duplicates, with the proposers' consent. Over-merging hides distinct concerns.
- **Vote stacking.** Stakeholders may put several votes on one scenario; that is allowed and signals intensity.
- **Refinement without measures.** A refined scenario without a number in the response measure is not finished.

### 15.2 Remote and multi-site variants

For dispersed stakeholder groups, hold several shorter QAWs at different sites or time zones,
each with its own report, then consolidate. Use one shared scenario list with stable IDs,
time-boxed silent brainstorming in a shared document before each round-robin pass, and an
online poll for voting that shows results only after each pass closes. Record which session
each scenario came from so consolidation can be checked.

### 15.3 Lessons from this workshop

| ID | Observation | Change next time |
|---|---|---|
| LSN-01 *(Example)* | Step 2 overran by 25 minutes | Send the presenter a 45-minute slide limit |
| LSN-02 *(Example)* | Only five scenarios refined; RS-09 missed | Book a 90-minute refinement follow-up in advance |
| [LSN-nn] | [Observation] | [Change] |

## 16. Glossary and references

<!-- Guidance: Define terms in your own words for participants who are new to the method. -->

| Term | Meaning in this document |
|---|---|
| Quality attribute | A measurable property of the system, such as performance, availability or security, that shows how well it serves its stakeholders |
| Quality attribute scenario | A short, concrete story of an interaction that exercises one quality attribute, with a measurable response |
| Architectural driver | A requirement, constraint, business goal or quality attribute that strongly shapes the architecture |
| Raw scenario | A scenario as first stated by a stakeholder during brainstorming |
| Refined scenario | A high-priority scenario worked out into its six parts, with goals, attributes, questions and issues |
| Use case, growth and exploratory scenarios | Expected use; expected change; unexpected stress or change |
| Seed scenario | A scenario carried into a later evaluation, such as ATAM, as a starting point |

| ID | Reference | Version | Use |
|---|---|---|---|
| REF-01 | Barbacci, Ellison, Lattanze, Stafford, Weinstock, Wood, *Quality Attribute Workshops (QAWs), Third Edition*, SEI technical report CMU/SEI-2003-TR-016, Carnegie Mellon University | August 2003 (SEI library record dated October 2003) | Method steps, roles, voting rule, six scenario parts |
| REF-02 | Kazman, Klein, Clements, *ATAM: Method for Architecture Evaluation*, SEI technical report CMU/SEI-2000-TR-004 | August 2000 | Later evaluation using QAW scenarios |
| REF-03 | ISO/IEC 25010, *Product quality model* | 2023 | Quality characteristic names in the requirements catalogue |
| [REF-nn] | [Title] | [Version] | [Use] |

## Standard and licence note

Structure aligned with the Quality Attribute Workshop method described by the Software
Engineering Institute in *Quality Attribute Workshops (QAWs), Third Edition* (CMU/SEI-2003-TR-016,
2003): the eight steps, the lead and scribe roles, the 30% voting rule and the six-part scenario
refinement. Step names and scenario part names are used to keep the method recognisable; all
explanations, tables, examples and facilitation notes are original text written for this
collection, and no text or template of the report is reproduced. Read the SEI report for the
full method. Carnegie Mellon, SEI and ATAM may be trademarks or service marks of Carnegie Mellon
University; this template is not affiliated with or endorsed by the SEI. Template licence: MIT.