Page 193 - Software and Systems Requirements Engineering in Practice

159

A
t
y
r
i
t
t
i

5
e
r
a
l
:
u
e
m
i
r
t
s
e
n
u
t
e
b
u
e
q

R
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 159
a
h
p
C
t
Field Facilities System
Engineer Manager Administrator
Monitoring
Client
Monitor building
Field system Automation Alarm Public
Field System
data Server notification Safety System
Store/access
field system data
Database
KEY
Components Connectors
X Y Call-Return (X calls Y)
Software Component A B Data Access (A accesses/stores data
to A from B)
Database
X Y X interacts with Y
External Entity System Boundary
FIGURE 5.5 Building automation system context
Some of the use cases related to the goals of the actors of the
building automation system are shown in Figure 5.6. These use cases
are grouped by product features they realize and provide a broad
functional context of the system under development.
Forces That Shape the Architecture
The business goals also correspond to quality attributes the system
must exhibit. In order to support a multitude of hardware devices and
consider different languages and cultures, the system must be
modifiable. In order to support different regulations in different
geographic markets, the system must respond to life-threatening
events in a timely manner. It is, therefore, critical that the business
goals and their implied quality concerns be fully understood.
One way to do this is to employ the SEI’s Quality Attribute
Workshop (QAW) [Bachmann et al. 2002], [Barbacci et al. 2000]. As
we have discussed, this is a technique for eliciting quality attribute
requirements that are mapped to business goals. Through workshops,
the business goals provided by management and technical
stakeholders are used to elicit concrete scenarios for the quality