1. Quality Attribute Workshop

2. Goal: To identify requirements Held early in development Includes stakeholders Outputs: Business Goals Quality Attribute Scenarios and Use Cases Scenarios are six fold (stimulus, source of the stimulus, artifact, environment, response, and response measure)

3. Attribute Driven Design Goal: To localize the effects of design changes Focuses on the overall system structure that the quality attributes shape Choice of architectural tactics to satisfy quality scenarios Outputs: Course Grain Architectural Structure Generate and Test architectural design model

4. Architecture Trade-off Analysis Method (ATAM) Goal: Assess architectural decisions’ consequences with respect to requirements and business goals Helps stakeholders ask the right questions to discover problematic architectural decisions

5. Cost-Benefit Analysis Method (CBAM) Goal: To make the decisions made during the ATAM part of the roadmap by assigning priorities, costs and benefits with each architectural decision Business consequences allow the dev team to make informed choices among architectural options

6. Sample Example: Bank ATM From XP’s user stories we receive Feature requirements From the QAW process we identify additional quality attributes that need to be satisfied: Modifiability Extensibility Performance

7. Sample Example: Bank ATM Quality Attribute Workshop Modifiability Attribute Scenario I: A developer wants to add a new auditing business rule at design time in 10 person-days without affecting other functionality Modifiability Attribute Scenario II: A system administrator wants to employ a new database in 18 person-months without affecting other functionality

8. Sample Example: Bank ATM Quality Attribute Workshop Modifiability Attribute Scenario III A developer needs to add a Web-based client in 90 person-days without affecting the existing ATM client’s functionality

9. Modifiability Scenario I Stimulus – Adding a Business Rule Source – The Developer Artifact – Business Rule System Environment – New Business Rule Response – Business Rule added within 10 Days Response Measure – Business Rule is added and Existing functionality is unchanged

10. Modifiability Scenario II Stimulus – Employing a new Database Source – A System Administrator Artifact – Data Organization and Storage Environment – New Platform Response – Database employed within 18 person- months Response Measure – Database Deployed and In Use. Existing functionality is unchanged

11. Modifiability Scenario III Stimulus – Adding an Additional Client Source – The Developer Artifact – User Interface Environment – New Capability Response – Business Rule added within 10 Days Response Measure – Business Rule is added and Existing functionality is unchanged