Scribd
Upload
2K views

How To Create A Utility Tree

The document provides instructions for creating a utility tree to evaluate a system's architecture. The utility tree begins with an overall utility goal at the top level and then refines this into specific quality attributes, attribute goals, and concrete quality attribute scenarios at subsequent levels. Scenarios specify stimuli, environments, artifacts, responses, and response measures. Stakeholders prioritize scenarios by importance and perceived risk to identify those most crucial to analyze during evaluation.

Uploaded by

Jackson Chua
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
2K views

How To Create A Utility Tree

The document provides instructions for creating a utility tree to evaluate a system's architecture. The utility tree begins with an overall utility goal at the top level and then refines this into specific quality attributes, attribute goals, and concrete quality attribute scenarios at subsequent levels. Scenarios specify stimuli, environments, artifacts, responses, and response measures. Stakeholders prioritize scenarios by importance and perceived risk to identify those most crucial to analyze during evaluation.

Uploaded by

Jackson Chua
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

How to Create a Utility Tree?

1. Begin with UTILITY (Level 0) as the root node.


Utility is an expression of the overall goodness of the system.
2. Form the second level (Level 1) with Quality attributes. These are the components of utility. Quality
attributes are the initial or seed set of this second level.
Typically, performance, modifiability, security, usability, and availability are the children of
utility, but feel free to name their own. Sometimes different stakeholder groups use different
names for the same ideas (for example, some stakeholders prefer to speak of maintainability).
Sometimes they introduce quality attribute names that are meaningful in their own culture but
not widely used elsewhere, such as flextensibility. Any names the stakeholders introduce are
fine as long as they are able to explain what they mean through refinement at the next levels.
3. Next (Level 2), list specific quality attribute refinements under each of these quality attributes are.
For example, performance might be decomposed into data latency and transaction
throughput.
This is a step toward refining the attribute goals into quality attribute scenarios that are
concrete enough for prioritization and analysis.
Data latency might be further refined into Lower storage latency on customer database to 20
ms. and Deliver 20 frame/second video in real time because both kinds of data latency are
relevant to the system.
4. Then, form the leaves (Level 3) of the utility tree with Scenarios. They are the mechanism by which
broad (and ambiguous) statements of desired qualities are made specific and testable.
Group the Scenarios by the quality attributes they express. Their six-part form is simplified for
purposes of evaluation (Note: ATAM scenarios consist of three parts: stimulus (what condition
arrives at a system, who generated it, and what system artifact it stimulates), environment
(what is going on at the time), and response (system's reaction to the stimulus expressed in a
measurable way)):o Source of stimulus. This is some entity (a human, a computer system, or any other actuator)
that generated the stimulus.
o Stimulus. The stimulus is a condition that needs to be considered when it arrives at a
system.
o Environment. The stimulus occurs within certain conditions. The system may be in an
overload condition or may be running when the stimulus occurs, or some other condition
may be true.
o Artifact. Some artifact is stimulated. This may be the whole system or some pieces of it.
o Response. The response is the activity undertaken after the arrival of the stimulus.
o Response measure. When the response occurs, it should be measurable in some fashion so
that the requirement can be tested.
Some scenarios might express more than one quality attribute and so might appear in more
than one place in the tree. That is not necessarily a problem, but the evaluation leader should
guard against scenarios that try to cover too much diverse territory because they will be difficult
to analyze. Try to split such scenarios into constituents that each attach smaller concerns.
Not only does the team need to understand the precise goals levied on the architecture, but it
also needs to understand their relative importance. A utility tree can easily contain fifty

scenarios at its leaves, and there will not be time during the evaluation meeting to analyze them
all. Hence, utility tree generation also includes a prioritization step.
5. Assign a priority (IMPORTANCE) to each scenario by consensus among decision makers.
This prioritization may be on a 0 to 10 scale or use relative rankings such as high, medium, and
low.
Normally, high/medium/low approach works well with diverse groups and takes less time than
assigning precise numbers.
6. After that, prioritize the scenarios a second time (PERCEIVED RISK) using a different criterion.
The architect is to rank each scenario by how difficult he or she believes it will be for the
architecture to satisfy.
Again, a simple high/medium/low scheme works well here.
7. Now each scenario has an associated ordered pair: (H,H), (H,M), (H,L), and so forth.
The scenarios that are the most important and the most difficult will be the ones where
precious analysis time will be spent and the remainder will be kept as part of the record.
A scenario that is considered either unimportant (L,*) or very easy to achieve (*,L) is not likely
to receive much attention.

You might also like