Utility Tree
A structured decomposition of quality attributes into concrete, prioritised scenarios, used to focus architectural analysis on what actually matters.
Quality attributes stated as words — "performant", "secure", "maintainable" — cannot be designed for, tested, or traded off. A utility tree converts them into things that can.
Structure: utility at the root; quality attributes as branches (performance, availability, security, modifiability); refinements beneath each (transaction latency, peak throughput); and concrete scenarios as leaves.
A scenario states a stimulus, an environment and a response measure: "During the annual sale, with traffic at five times normal, the checkout completes within 500 ms at the 95th percentile." That can be designed for, measured, and argued about with evidence.
Each leaf is then rated on two axes: business importance and technical difficulty or risk. The high-importance, high-difficulty scenarios are where architectural analysis is worth spending, and usually there are fewer than ten.
Two things the exercise produces beyond the priorities: it surfaces direct conflicts between attributes — security controls that add latency, availability mechanisms that weaken consistency — as specific opposing scenarios rather than as vague tension. And it gives an acceptance basis: the scenarios become the tests, the fitness functions and the SLO definitions, which is what stops them from being an artefact nobody revisits.