Page 179 - Software and Systems Requirements Engineering in Practice

u
a
:

5
i
b
i
l
r
C
h
A
t
t
e
r
t
a
p
e
n
m
r
e
t

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 145 145
y
s
t

R
e
u
t
e
i
u
q
They are used to stimulate thinking about implicit assumptions
underpinning the architecture, which may turn out not to be
true.
We recommend using QASs, not just in workshops, but whenever
you are capturing stakeholder concerns. You will want to manage
them similarly to how you manage other high-level requirements.
However, it is important to remember that
• The QAS is only an example of the concern. It is up to you to
investigate the topic and propose good quality attribute
measures and requirements.
• The stakeholders’ priorities will change over time. The
prioritization work done in a workshop helps you know
where to focus your attention first, but the official prioritization
of concerns will need to be done later and more
systematically.
• QASs do not replace use case scenarios. A QAS generally
treats the system as a black box, with a stimulus and a response,
whereas a use case scenario is attached to a particular use case
and can be as rigorous and detailed as necessary. We
recommend that you establish trace links between QASs and
the use cases or use case scenarios they correspond to,
indicating that the QAS is part of the rationale for the quality
attribute requirements attached to the use case.
Goal Modeling
One of the challenging differences between functional requirements
and quality attribute requirements is that functional requirements
usually have a yes/no flavor to them, whereas quality attribute
requirements have a more-is-better character. For example, if an
airline reservation system is required to display a certain list of
available flights within 15 seconds, the information displayed in
the list is either correct or incorrect, but nothing very bad happens
if the list is displayed in 16 seconds instead of 15, and displaying it
in 10 seconds is even better than 15, although the additional benefit
may not be very important.
Another challenging difference is that the logical linkage between
design decisions and functional requirements is normally clear-cut,
whereas the linkage between design decisions and quality attributes
often remains subjective during development. The easiest example is
user interface design, where many design decisions affect ease of use,
but it is mainly guesswork to say which ones will have a big impact,
and whether the aggregate ease of use will be sufficient for the end
user’s needs.