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.

Document control

Approvals

Revision history

Contents

1. Workshop summary
2. Context and preparation
3. Participants and roles
4. Step 1: QAW presentation and introductions
5. Step 2: Business and mission presentation
6. Step 3: Architectural plan presentation
7. Step 4: Identification of architectural drivers
8. Step 5: Scenario brainstorming
9. Step 6: Scenario consolidation
10. Step 7: Scenario prioritisation
11. Step 8: Scenario refinement
12. Issues, assumptions and conflicts
13. Coverage and traceability
14. Next steps and use of results
15. Facilitation notes
16. Glossary and references

1. Workshop summary

[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."]

2. Context and preparation

2.1 Purpose and scope

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

3. Participants and roles

3.1 Facilitation team

3.2 Stakeholders

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

5. Step 2: Business and mission presentation

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."]

6. Step 3: Architectural plan presentation

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."]

7. Step 4: Identification of architectural drivers

8. Step 5: Scenario brainstorming

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

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

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

10. Step 7: Scenario prioritisation

10.1 Vote allocation

10.2 Results

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

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

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

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

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

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

12. Issues, assumptions and conflicts

13. Coverage and traceability

13.1 Driver coverage

13.2 Where refined scenarios go next

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

15. Facilitation notes

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

16. Glossary and references

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.