Page 169 - Software and Systems Requirements Engineering in Practice

A
t
h
t
y
b
u
t
t
r
i
a
u
Q
:
i
l
a
e
t
p
5

r
e
e
m
e
n
C C h a p t e r 5 : 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 135 135
s
t
r
q
u
i

R
e
completeness. For example, the process may define how to count use
cases for purposes of measuring the percentage of use cases that have
passed their system tests. The project manager needs to update this
statistic at regular intervals to keep track of progress. If he doesn’t,
then the executed process is incomplete, because it does not do
everything that the defined process says it should. If the defined
process does not specify how to determine whether the set of use
cases is sufficiently complete to satisfy the stakeholders, then the
defined process itself may be considered to be incomplete as well,
which could result in lack of completeness-in-use.
When it comes to defining actual quality attribute requirements,
it helps to distinguish two types:
• Requirements that define quality attribute measures and how
and when to measure them. For example, “The system shall
measure and report ‘reservation completion time,’ starting
from the display of the first flight query screen and ending
with the display of the screen giving the reservation
confirmation number.”
• Requirements that specify what values of the quality attribute
measures indicate sufficient quality. For example, “The
‘reservation completion time’ for an experienced tester on a
lightly loaded system making a Type 3 reservation shall be
less than two minutes.”
From these examples, you can see that functional requirements
and quality attribute requirements complement each other, and
neither is sufficient without the other. It is not enough to specify all
the kinds of reservation functions (the use cases) that the product
supports, without specifying how quickly a customer should be able
to make a reservation; e.g., it should be much faster than phoning the
airline. Conversely, it is not enough to specify that a customer can
make a reservation in three minutes, without specifying the kinds of
information the customer will be able to examine, the complexity of
the itinerary that can be handled, and all the other functional details.
Nonetheless, the functional requirements are the basic stuff—the
“nouns and verbs”—of the requirements, whereas the quality
attribute requirements are typically modifiers of the functional
requirements—the “adjectives and adverbs.”
Also note that the completeness-in-use of the airline reservation
system will be affected by other quality attributes, such as ease of use,
because from the user’s viewpoint there is little difference between a
function being unimplemented and being too hard to use, too slow,
etc. In general, quality attributes will overlap within each of the
quality topic areas, and each quality attribute in one area will be
indicative of multiple quality attributes in other areas.