Page 177 - Software and Systems Requirements Engineering in Practice

C
n
t
h
t
p
a
u
R
i
b

s
t
e
y
t
i

t
t
A
l

r
e
5
a
u
:
r
r
i
e
e
m
u
C h a p t e r 5 : Q Q u a l i t y A t t r i b u t e R e q u i r e m e n t s 143 143
e
q
Quality Attribute Workshop
A quality attribute workshop (QAW) [Bachmann et al. 2002], [Barbacci
et al. 2000] brings together a diverse set of stakeholders in a one- or
two-day meeting to elicit their quality attribute concerns and help
them understand one another’s concerns. As a concern is being
described, the facilitator helps the stakeholder write a quality attribute
scenario (QAS) that describes what he wants (and thinks might be
hard to achieve). Each stakeholder captures at least two of his or her
biggest concerns in the form of QASs and presents them to the group.
The group then selects a handful of QASs to explore in more detail. The
facilitator helps them see some of the architectural significance of the
QASs, and begins the process of trading them off against each other.
A QAS is a structured textual description of how a piece of a
system responds to a stimulus, including measuring the quality of the
response. It was invented by software architecture researchers at the
Software Engineering Institute (SEI) as a medium of communication
between stakeholders and the architecture team [Bass et al. 2003].
A QAS is typically structured to have the following parts:
• A stimulus
• A stimulus source
• An artifact being stimulated
• An environment in which the stimulus occurs
• A response to the stimulus
• A response measure (to quantitatively define a satisfactory
response)
For example, a configurability scenario might be written as
“A customer requests support for a new type of sensor after the
software has been installed and activated. The customer support
engineer reconfigures the system to support the new sensor without
writing any new source code, without extraordinary downtime, and
commencing operation with the new sensor within one calendar
week of receiving the necessary documentation on the sensor.”
For this example, we can define
• Stimulus Requests support for a new type of sensor
• Stimulus source The customer
• Artifact The system and the customer support organization
• Environment After the software has been installed and
activated
• Response The customer support engineer reconfigures the
system to support the new sensor