Utility Trees and Scenario Prioritization

Summary

The utility tree is ATAM's central prioritization artifact — a structured decomposition of system utility into quality attribute branches, sub-attributes, and leaf-level scenarios rated by importance and difficulty. This chapter teaches students to build utility trees from scratch through facilitated workshops, assign importance and difficulty scores through stakeholder negotiation, identify the high-importance, high-difficulty scenarios that demand the deepest architectural analysis, and validate the resulting tree against the full scenario catalog. These skills are applied directly in Phase 1 of a live ATAM evaluation.

Concepts Covered

This chapter covers the following 13 concepts from the learning graph:

1. Utility Tree
2. Utility Tree Root
3. Quality Attribute Branch
4. Sub-Attribute Node
5. Leaf-Level Scenario
6. Importance Rating
7. Difficulty Rating
8. HH Scenario Priority
9. Utility Tree Construction
10. Utility Tree Workshop
11. Scenario Importance vs Effort
12. Priority Negotiation
13. Utility Tree Validation

Prerequisites

This chapter builds on concepts from:

• Chapter 4: Stakeholder and Business Analysis
• Chapter 5: Quality Attributes
• Chapter 6: Quality Attribute Scenarios

---

The Utility Tree: Your ATAM Command Center

Fellow architects, if ATAM were a superhero team, the utility tree would be the situation map on the wall of the command center — the artifact that everyone consults to understand what matters most, what is hardest, and where to focus energy. Every stakeholder can see their concerns represented. Every architect can see where the hard problems are. And every risk the evaluation surfaces can be traced back to a specific scenario on the tree. This chapter gives you the power to build that map. Let's take the high-level view and start constructing!

What Is a Utility Tree?

A utility tree is a hierarchical decomposition of a system's quality attributes from a single root ("utility") through quality attribute branches to leaf-level scenarios, with each scenario rated by two dimensions: importance to stakeholders and difficulty for the architecture to achieve.

The tree structure serves four purposes simultaneously:

1. Organization: It groups scenarios by quality attribute, making it easy to see the full scope of requirements in each dimension
2. Prioritization: The importance and difficulty ratings produce a priority ordering that focuses analytical attention where it is most needed
3. Negotiation record: The tree documents the outcome of stakeholder priority negotiations, providing a traceable record of how competing concerns were resolved
4. Communication: The tree provides a visual summary of what the system must achieve that can be understood by both technical and non-technical audiences

Before building a utility tree, we need precise definitions for each structural level:

• Utility Tree Root: The root node of the tree, labeled "Utility" — representing the overarching goal of making a system that serves its stakeholders well. The root is always the same across all utility trees; it anchors the decomposition.
• Quality Attribute Branch: The second level of the tree, one branch per quality attribute being evaluated. Common branches: Performance, Availability, Security, Modifiability, Interoperability, Scalability. A utility tree typically has four to eight branches.
• Sub-Attribute Node: The third level, decomposing each quality attribute branch into more specific concerns. For example, the Performance branch might have sub-attributes of Latency and Throughput; the Availability branch might have sub-attributes of Fault Detection and Recovery.
• Leaf-Level Scenario: The fourth level, where each sub-attribute node has one or more concrete quality attribute scenarios — expressed in the six-component form from Chapter 6. Each leaf scenario carries two ratings: an importance score and a difficulty score.

The Two Ratings: Importance and Difficulty

The two dimensions that make the utility tree analytically powerful are the importance rating and the difficulty rating applied to each leaf-level scenario.

Importance reflects how much the stakeholders care about the system achieving this scenario. It is a business and operational judgment — not a technical judgment. The importance question for stakeholders is: "If this scenario is not achieved, how bad is that for the organization?" Standard importance ratings use a three-level scale: High (H), Medium (M), Low (L).

• High (H): Failure to achieve this scenario would constitute a serious business failure — lost revenue, regulatory penalty, safety incident, or fundamental loss of customer trust
• Medium (M): Failure to achieve this scenario would be painful and costly but not existentially damaging; it is a significant gap rather than a critical failure
• Low (L): Failure to achieve this scenario would be inconvenient or suboptimal but would not significantly affect the organization's ability to meet its primary goals

Difficulty reflects how hard the architecture makes it to achieve the scenario — essentially, how much architectural work and risk is required to reach the response measure. Difficulty is a technical judgment, made by the evaluation team in consultation with the architecture owner. The difficulty question is: "Given the current architectural decisions, how challenging is it to meet this scenario's response measure?"

• High (H): The current architectural decisions make this scenario very difficult or impossible to achieve without significant rework; this scenario reveals a genuine architectural challenge
• Medium (M): The current architectural decisions make this scenario achievable but require careful attention to implementation details; it is not automatic
• Low (L): The current architectural decisions make this scenario readily achievable; implementation carries no significant architectural challenge

The combination of these two ratings produces a four-cell priority matrix:

	High Importance	Low/Medium Importance
High Difficulty	(H,H) — Critical: focus here first	(L/M, H) — Risk: address if resources permit
Low/Medium Difficulty	(H, L/M) — Confirmation: verify and document	(L, L) — Monitor: low priority

HH Scenarios: Where the Deep Analysis Lives

The scenarios rated (H, H) — high importance and high difficulty — are the analytical heart of an ATAM evaluation. These are the scenarios that the stakeholders care most about and that the architecture has the hardest time achieving. They represent the highest-risk, highest-value territory in the evaluation.

An (H, H) scenario demands the following from the evaluation team:

• Deep architectural approach analysis: Which specific architectural decisions affect this scenario? What are the sensitivity points within those decisions?
• Risk identification: Is there a credible risk that the architecture will fail to meet the response measure under the specified conditions?
• Tradeoff analysis: Do the architectural decisions that help achieve this scenario hurt other scenarios? If so, which ones, and how severely?
• Mitigation recommendations: What architectural changes, tactics, or additional mechanisms could reduce the risk?

(H, H) scenarios are also the primary driver of Phase 1's architectural approach analysis. The evaluation team uses the list of (H, H) scenarios to select which architectural approaches to probe in depth. An architectural approach that affects multiple (H, H) scenarios is a critical analysis focus.

HH Is Not a Failure Grade

An important mindset correction: a scenario rated (H, H) is not evidence that the architecture is bad. It is evidence that this scenario is strategically important AND architecturally challenging — which makes it exactly the right place to spend evaluation energy. An architecture with no (H, H) scenarios is either very simple or under-evaluated. A mature, complex system under realistic stakeholder pressure should have several (H, H) scenarios. Your ATAM superpower is identifying them precisely and giving the evaluation team a clear analytical agenda.

Diagram: Utility Tree Interactive Explorer

Utility Tree Interactive Explorer

Type: diagram sim-id: utility-tree-explorer
Library: p5.js
Status: Specified

Purpose: Provide an interactive, expandable utility tree visualization showing a complete example tree for a healthcare patient portal system, with color-coded (H,H)/(H,M)/(M,H)/(M,M) scenario ratings, and click-to-expand nodes revealing scenario details.

Bloom Level: Understand (L2) — Explain the hierarchical structure of a utility tree and interpret the importance/difficulty ratings of leaf-level scenarios. Bloom Verb: Explain

Learning Objective: Students will be able to identify each level of a utility tree (root, quality attribute branch, sub-attribute node, leaf scenario), interpret the importance and difficulty ratings, and explain why (H,H) scenarios receive priority analytical attention.

Canvas layout: - Tree visualization expanding downward from root - Root node (top center): "Utility" in gold - Level 2 branches (quality attribute names): 4 branches visible by default (Performance, Availability, Security, Modifiability), expandable to 6 - Level 3 sub-attribute nodes under each branch - Level 4 leaf scenarios with (Importance, Difficulty) rating badges - Color coding: (H,H) = red, (H,M) or (M,H) = orange, (H,L) = gold, (M,M) = blue, (L,*) = gray - Detail panel on the right showing full scenario when a leaf is clicked - "Focus Mode" button that dims all nodes except (H,H) ones

Example tree content (healthcare patient portal): Performance branch: - Sub-attribute: Response Latency - Leaf: Patient appointment search returns results in <800ms at p99 under peak load [H,H] - Leaf: Patient record retrieval completes in <2s for records with >500 attachments [H,M] - Sub-attribute: Batch Processing - Leaf: Nightly claim reconciliation completes within 4-hour window [M,M]

Availability branch: - Sub-attribute: Fault Tolerance - Leaf: EHR integration failure does not prevent appointment scheduling [H,H] - Leaf: Authentication service failure redirects to backup IdP within 10 seconds [H,M] - Sub-attribute: Planned Maintenance - Leaf: Maintenance window limited to 30 minutes per week, off-peak [H,L]

Security branch: - Sub-attribute: Access Control - Leaf: PHI access limited to authenticated, authorized users; all access logged [H,H] - Leaf: Admin account compromise detected and locked within 60 seconds [H,H] - Sub-attribute: Data Protection - Leaf: All PHI encrypted at rest and in transit [H,L]

Modifiability branch: - Sub-attribute: Feature Evolution - Leaf: New insurance provider integration added without changing patient-facing features [H,H] - Leaf: HIPAA regulation change implementable within one sprint cycle [M,H]

Interactive elements: - Click any node to expand its children; click again to collapse - Click any leaf node to see full six-component scenario in detail panel - Click (Importance, Difficulty) badge to see the rating rationale - "Focus (H,H)" button collapses all non-(H,H) leaves and highlights the remaining ones - Drag-and-drop: drag a leaf to a different sub-attribute to see how the tree restructures

Color scheme: Gold root, blue branches, teal sub-attribute nodes, color-coded leaves by rating. Gray background.

Responsive: Tree scales horizontally; collapses to single-column list on narrow screens.

Utility Tree Construction: A Step-by-Step Workshop

The utility tree workshop is a structured facilitation process, typically embedded within ATAM Phase 1, that builds the tree from scratch with the architecture team. The following steps describe the workshop flow:

Step 1: Identify Quality Attribute Branches

Begin by listing the quality attributes relevant to the system, drawing on the business driver analysis from Chapter 4 and the quality attribute taxonomy from Chapter 5. For most systems, this produces four to eight branches. Avoid creating branches for every possible quality attribute — branches without leaf scenarios waste tree real estate and obscure the most important concerns.

Invite the architecture team to propose branches, then validate against the stakeholder concerns documented in the evaluation planning document. Any concern that cannot be accommodated under an existing branch warrants a new one.

Step 2: Populate Sub-Attribute Nodes

For each quality attribute branch, identify the two to four sub-attributes that best decompose the quality attribute for this specific system. Sub-attributes are more granular than quality attributes but less granular than scenarios — they represent a category of scenarios under a quality attribute.

For example, the Security branch of a financial services system might decompose into: Access Control (who can do what), Data Protection (encryption and key management), Audit and Compliance (logging and reporting), and Fraud Detection (real-time anomaly detection). Each sub-attribute will have one to three leaf scenarios.

Step 3: Write Leaf-Level Scenarios

For each sub-attribute, write one to three concrete scenarios using the six-component model from Chapter 6. Start with the scenarios the architecture team considers most important. In Phase 2, additional scenarios contributed by the broader stakeholder community will extend the tree.

At this stage, use the general-to-concrete transformation: start with a general scenario template for the quality attribute, then refine it to match the specific system's context, components, and business environment.

Step 4: Assign Importance Ratings (Stakeholder Activity)

For each leaf scenario, the architecture team (and, in Phase 2, the broader stakeholder group) assigns an importance rating: H, M, or L. This is a facilitated discussion, not an individual assignment. The facilitator presents each scenario and invites stakeholders to rate it, then facilitates consensus or records the disagreement.

The facilitator must ensure the discussion addresses the right question: "If this scenario is NOT achieved, how bad is it for the business?" — not "is this scenario technically interesting?" (which would be the wrong axis).

Step 5: Assign Difficulty Ratings (Technical Activity)

For each leaf scenario, the evaluation team and architecture team collaboratively assign a difficulty rating: H, M, or L. This is a technical judgment about the current architectural decisions. The key question is: "Does the current architecture make this scenario easy or hard to achieve, regardless of its importance?"

Difficulty ratings often surface the most valuable insights of the workshop. A scenario that both the architecture team and the evaluation team expected to be easy but turns out to be difficult is an unexpected sensitivity point. A scenario that was expected to be hard but turns out to be straightforward (because an effective tactic is already in place) is a non-risk confirmation — valuable evidence that the architecture is doing something right.

Step 6: Identify Priority Matrix Quadrants

Once all scenarios are rated, organize them into the four priority quadrants: (H,H) critical, (H, not-H) important but achievable, (not-H, H) risky but lower priority, (not-H, not-H) monitor. The (H,H) list becomes the evaluation team's analytical agenda for the remainder of Phase 1.

The (M,H) Scenario Alert

Do not let (M, H) scenarios quietly fall off the evaluation agenda. A scenario rated medium importance and high difficulty is an architectural time bomb. Today it is merely important, not critical — but if the business context changes (the scenario becomes more important), or if the architecture gets more complex (the difficulty increases further), this scenario could rapidly become a (H, H) risk. Vista's practice: document every (M, H) scenario explicitly in the risk catalog with a note about what conditions would escalate it to (H, H). That documentation becomes the trigger for a future re-evaluation.

Diagram: Utility Tree Construction Workshop Simulator

Utility Tree Construction Workshop Simulator

Type: microsim sim-id: utility-tree-builder
Library: p5.js
Status: Specified

Purpose: Interactive tool for building a utility tree step-by-step, allowing students to add quality attribute branches, create sub-attribute nodes, write leaf scenarios, and assign importance/difficulty ratings, with real-time visualization of the tree structure.

Bloom Level: Create (L6) — Design a utility tree for a given system by constructing quality attribute branches, sub-attribute nodes, and rated leaf-level scenarios. Bloom Verb: Design

Learning Objective: Students will be able to build a complete utility tree for a provided system description, including quality attribute branches, sub-attribute nodes, rated leaf scenarios, and an identified list of (H,H) priority scenarios.

Canvas layout: - Left panel: Step-by-step construction panel with current step highlighted - Center: Live tree visualization updating as elements are added - Right panel: Scenario editor form (six fields + importance/difficulty selectors) - Bottom: (H,H) scenario counter and "Validate Tree" button

Construction steps (guided): Step 1: Select quality attribute branches from checklist (Performance, Availability, Security, Modifiability, Interoperability, Scalability, others) Step 2: For each selected branch, add 2-4 sub-attribute nodes (text input) Step 3: For each sub-attribute, add 1-3 leaf scenarios using the six-component form Step 4: Rate each leaf scenario (Importance: H/M/L, Difficulty: H/M/L) using dropdowns Step 5: Review priority matrix — system automatically groups scenarios into (H,H), (H,M/L), (M/H,H), (M,M) quadrants

Controls: - "Add Branch" button adds a new quality attribute branch - "Add Sub-Attribute" button (context-sensitive to selected branch) adds a node - "Add Scenario" button (context-sensitive to selected sub-attribute) opens scenario editor - Importance and Difficulty dropdowns per leaf scenario - "Auto-Rate" button applies suggested ratings based on scenario text keywords (demonstration mode)

Validation (when "Validate Tree" button clicked): - Minimum structure check: at least 3 branches, 2 sub-attributes per branch, 1 scenario per sub-attribute - Coverage check: at least one scenario per major quality attribute in scope - Rating check: all leaf scenarios rated on both dimensions - (H,H) check: at least 2 (H,H) scenarios exist - Provides feedback: "Tree structure complete" / "Add sub-attributes to Performance branch" / "Missing importance rating on 3 scenarios"

Instructional Rationale: Step-by-step construction with guided prompts is appropriate for the Create objective because it scaffolds the complex task of tree building while requiring students to supply all system-specific content. The validation feedback closes the loop on correctness.

Color scheme: Gold for root, Blue for branches, Teal for sub-attributes, color-coded leaves by (I,D) rating. Green for validated elements.

Responsive: Layout reflows to vertical on narrow screens.

Priority Negotiation: When Stakeholders Disagree

The utility tree workshop is not always a harmonious exercise. Stakeholders with different organizational roles and concerns will often disagree about importance ratings — and those disagreements, if not facilitated well, can derail the evaluation or produce a tree that no one trusts.

Priority negotiation is the facilitated process by which disagreements about importance ratings are resolved. The goal is not to determine who is "right" but to reach a documented, defensible consensus (or documented disagreement with explicit escalation) that the evaluation can proceed on.

Effective negotiation techniques for utility tree workshops include:

Stakes escalation: When two stakeholders disagree on importance (e.g., one rates a performance scenario H and another rates it M), ask each to articulate the business consequence of failing the scenario. Often, the disagreement is about different assumptions about failure consequences — once these are made explicit, consensus often follows.

Temporal framing: Sometimes the disagreement is about time horizon. A scenario that is M importance today might become H importance in twelve months if a planned business expansion materializes. Document both the current and anticipated future ratings, and note the trigger that would change the rating.

Authority invocation: When genuine disagreement remains after facilitated discussion, the facilitator identifies the appropriate decision-making authority (from Chapter 4) and records the disagreement as an open issue requiring that authority's resolution. This prevents the workshop from stalling on unresolvable disagreements while ensuring the disagreement is not simply swept under the rug.

Coalition weighting: In workshops with many stakeholders, dot voting (from Chapter 6) can be applied to importance rating disagreements — effectively letting the stakeholder community as a whole adjudicate the priority rather than having it determined by the loudest voice.

Utility Tree Validation

A completed utility tree must be validated before it drives the evaluation's analytical phase. Validation checks that the tree is complete, balanced, and accurately represents stakeholder priorities.

The following checklist guides utility tree validation:

Structural completeness:

• All major quality attributes in scope have branches
• Each branch has at least two sub-attributes (avoiding over-aggregation)
• Each sub-attribute has at least one leaf scenario (avoiding empty branches)
• All leaf scenarios are expressed in complete six-component form
• All leaf scenarios have both importance and difficulty ratings

Coverage balance:

• No single quality attribute dominates more than 40% of the leaf scenarios
• All stakeholder groups' primary concerns are represented by at least one (H,H) scenario
• Cross-cutting concerns (security, observability) are not absent from branches

Rating consistency:

• Importance ratings are consistent with the business driver analysis — scenarios connected to high-priority business drivers should not be rated L importance
• Difficulty ratings are consistent with the architectural analysis — scenarios that the evaluation team's initial assessment flagged as challenging should not be rated L difficulty without explanation

Analytical tractability:

• The (H,H) scenario list contains a manageable number of scenarios for deep analysis — typically 5 to 12 for a full evaluation. A tree with 30 (H,H) scenarios suggests that the importance ratings have not been sufficiently differentiated.
• The (H,H) scenarios span multiple quality attributes — a tree where all (H,H) scenarios are performance scenarios suggests incomplete elicitation of other concerns

When validation reveals gaps, the evaluation team uses targeted prompts to fill them before proceeding to the architectural approach analysis phase.

Diagram: Priority Matrix and Analytical Roadmap

Priority Matrix and Analytical Roadmap

Type: diagram sim-id: priority-matrix-explorer
Library: p5.js
Status: Specified

Purpose: Interactive 2×2 priority matrix (Importance vs. Difficulty) showing a populated utility tree's scenarios distributed across quadrants, with click-to-explore and drag-to-reclassify interaction.

Bloom Level: Evaluate (L5) — Assess the priority distribution of a utility tree's scenarios and determine whether the analytical roadmap appropriately focuses on (H,H) scenarios. Bloom Verb: Assess

Learning Objective: Students will be able to interpret the priority matrix distribution of a utility tree, evaluate whether the (H,H) scenario count and distribution is appropriate for a complete evaluation, and identify which scenarios the evaluation team should address first.

Canvas layout: - Large 2×2 matrix with axes: Importance (H/M/L, vertical, increasing upward) and Difficulty (L/M/H, horizontal, increasing rightward) - Quadrant labels: Top-right = "Critical — Analyze First (H,H)", Top-left = "Confirm — Verify and Document (H,L)", Bottom-right = "Watch — Address If Resources Permit (L,H)", Bottom-left = "Monitor (L,L)" - Scenario dots placed within appropriate quadrant, colored by quality attribute - "Analytical sequence" arrows showing the recommended order of attention - A legend panel listing each quality attribute and its color - Detail panel showing scenario summary when a dot is clicked

Populated example scenarios (from healthcare patient portal utility tree): (H,H) quadrant: - Patient appointment search <800ms under peak load [Performance, red] - EHR integration failure doesn't prevent scheduling [Availability, blue] - PHI access only for authenticated/authorized users [Security, green] - Admin account compromise detected within 60 seconds [Security, green] - New insurance provider integration without patient-facing changes [Modifiability, purple]

(H,L) quadrant: - Patient record retrieval <2s for large records [Performance, red] - Maintenance window <30 min per week [Availability, blue] - All PHI encrypted at rest and in transit [Security, green]

(M,H) quadrant: - HIPAA regulation change implementable in one sprint [Modifiability, purple] - Authentication failover to backup IdP within 10 seconds [Availability, blue]

(L,L) quadrant: - Nightly claim reconciliation within 4-hour window [Performance, red]

Interactive elements: - Click any dot to see full scenario summary - Drag dots between quadrants to explore how reclassification changes the analytical focus - "Show Critical Path" button draws arrows connecting (H,H) scenarios in order of evaluation priority - Filter button to show only a specific quality attribute's scenarios - "(H,H) Count: N" badge updates when dots are moved

Color scheme: Red for Performance, Blue for Availability, Green for Security, Purple for Modifiability, Teal for Scalability. Quadrant backgrounds in distinct light tints.

Responsive: Matrix scales proportionally to container width.

The Utility Tree as Communication Artifact

Beyond its role in the evaluation's analytical phase, the utility tree serves as a powerful communication artifact for presenting evaluation context to stakeholders who were not present during Phase 1. When Phase 2 opens, the evaluation leader presents the initial utility tree to the full stakeholder community — not as a final document but as a starting point for validation and extension.

This presentation serves two communication goals:

1. Validation: Stakeholders confirm that the tree accurately represents their priorities. Scenarios missing from the tree are added; scenarios misrated are corrected.
2. Alignment: Stakeholders see — often for the first time — the full map of everyone's quality attribute concerns. The relative weights of different stakeholders' concerns become visible. This is frequently when the most productive conversations about priority tradeoffs happen.

The utility tree also travels beyond the evaluation. Executive audiences respond well to the tree's visual structure — it shows that the evaluation is not a vague "architecture audit" but a structured, stakeholder-anchored analysis of specific, measurable requirements. A utility tree presented to an executive sponsor communicates: "We know exactly what we evaluated, why we evaluated it, and how important each dimension was to your own team." That kind of transparency builds the organizational credibility that makes evaluation findings actionable.

You've Built the Architecture Situation Map!

Look at what you can do now! You can build a utility tree from scratch — identifying branches, creating sub-attributes, writing leaf scenarios, running a priority negotiation, and producing the (H,H) analytical agenda that tells the evaluation team exactly where to dig. You've also learned to validate and communicate the tree to both technical and executive audiences. The utility tree is one of the most powerful organizational communication artifacts in the ATAM toolkit — and you now know how to build it. Onward to the patterns and tactics that address the scenarios you've just prioritized!

Key Takeaways

The utility tree is ATAM's central prioritization artifact, organizing quality attribute scenarios from abstract root to concrete, rated leaves:

• Utility tree structure: Root ("Utility") → Quality Attribute Branches → Sub-Attribute Nodes → Leaf-Level Scenarios with Importance and Difficulty ratings
• Importance is a business/stakeholder judgment — how bad is it if this scenario is not achieved?
• Difficulty is a technical/architectural judgment — how hard does the current architecture make it to achieve this scenario?
• (H,H) scenarios (high importance + high difficulty) receive the deepest analytical attention — they represent the evaluation's highest-risk, highest-value territory
• (M, H) scenarios are architectural time bombs — medium importance today but potentially critical if the business context changes
• Utility tree construction is a facilitated, multi-step workshop process: identify branches, populate sub-attributes, write leaf scenarios, assign ratings, validate
• Priority negotiation uses stakes escalation, temporal framing, authority invocation, and coalition weighting to resolve stakeholder disagreements
• Utility tree validation checks structural completeness, coverage balance, rating consistency, and analytical tractability before the tree drives analysis
• The utility tree is also a communication artifact — it presents the complete analytical agenda to executive audiences in a visual, intuitive format

Self-Check: Utility Tree Mastery — Click to Reveal Answers

Q1: You are building a utility tree for an online banking system. Under the Security branch, you have sub-attribute "Access Control" with one leaf scenario: "Only authenticated users can access account data." The architecture team rates this (H, L) — high importance, low difficulty. What does this rating tell you about this scenario's role in the evaluation?

Answer: A rating of (H, L) places this scenario in the "Confirm" quadrant — high importance but the current architecture makes it readily achievable. This is a non-risk confirmation finding. The evaluation should still verify the scenario is met (perhaps through a review of the authentication implementation and test evidence), but it does not warrant deep architectural analysis. Instead, documenting it as a non-risk is valuable evidence that the architecture is handling this critical security concern well. The evaluation team's attention should focus on the (H,H) scenarios, not on revisiting this one.

---

Q2: During the utility tree workshop, the operations lead rates a scenario "H" importance and the CFO rates the same scenario "M" importance. How would you facilitate this disagreement?

Answer: Apply the stakes escalation technique: ask each stakeholder to articulate the business consequence of failing this scenario from their perspective. The operations lead likely sees it as H because they will be paged at 2am when it fails; the CFO may see it as M because the financial impact is not visible from their vantage point. Once the consequences are explicit and shared, one of three outcomes is likely: (1) the CFO recognizes the operational severity and upgrades to H, (2) the operations lead realizes the financial impact is lower than expected and accepts M, or (3) genuine disagreement remains and you record it as a dispute requiring resolution by a defined decision-making authority (e.g., the CTO who manages both stakeholders). What you must NOT do: average the ratings to produce "H+M/2 = MH" — ambiguous composite ratings undermine the tree's analytical value.

---

Q3: A colleague argues that any system with fewer than five (H,H) scenarios probably hasn't been evaluated thoroughly enough. Do you agree? Why or why not?

Answer: This is a reasonable heuristic for complex enterprise systems but not a universal rule. The number of (H,H) scenarios depends on the system's complexity, the breadth of quality attribute concerns, and the stakeholder community's diversity. A simple internal tool with limited scope and homogeneous stakeholders might legitimately have two or three (H,H) scenarios. However, for the kinds of systems evaluated in this course — distributed, multi-stakeholder, enterprise systems — fewer than five (H,H) scenarios usually indicates either incomplete scenario elicitation (the brainstorming missed important concerns) or overly conservative difficulty ratings (the evaluation team underestimated how hard the architecture makes certain scenarios). The more important validation is not the count but the coverage: do the (H,H) scenarios span multiple quality attributes and represent the concerns of multiple stakeholder groups?