Page 167 - Software and Systems Requirements Engineering in Practice

a
p
u
h
r

t
e
i
m

R
q
e
r
e
e
t
r
A
t
u
t
i
b

u
a
5
:
t
y
l
i
e
n
t
s
C 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 133 133
the “process” in “process quality” includes not only software
development, but all the business functions surrounding the product,
including marketing, sales, planning, maintenance, installation,
customer support, and preparing to develop the next version.
Naturally, quality in use is the most important area of quality, but
it is also the latest one to measure, because it cannot be measured
until the product is delivered. Fortunately, quality attributes in the
other topic areas give us useful indications of what the quality in use
will be; i.e., we say that such quality attributes are “indicative of”
quality in use.
As an example, consider a web-based, self-service airline
reservation system. We’ll focus first on the completeness of the system,
which is one aspect of its fitness for use. For quality in use,
completeness might be measured, in part, by “the percentage of
actual reservations that are made successfully without involving
airline personnel.” This, after all, is a primary goal of such a system:
reduce personnel costs for reservations. This percentage will be
affected by many things, including bugs, unimplemented use cases,
ease of use, response time, server capacity, etc. It will also be affected
by the proportions of different kinds of reservations that customers
want to make. Figure 5.2 illustrates the many quality attributes, from
the four quality areas, that are indicative of the percent of unassisted
reservations in actual use.
Before the system is deployed, it has gone through system testing,
where testers, acting the part of customers, try to accomplish specified
travel reservation tasks. Completeness, here, might be measured by
“percentage of use cases passing system test,” which would be an
external quality measure. It is obviously indicative of the percent of
unassisted reservations, but it is different in several ways, including
these:
• It attaches equal weight to each use case, instead of accounting
for the frequency with which each use case is needed by
actual customers.
• Paid testers quickly become experts in using the software
they are testing, whereas many real-world customers remain
only casual users of the software. So, a tester might complete
a task successfully via a user interface that is too frustrating
for the typical customer.
• A use case that fails system testing might still work most of
the time under real-world conditions.
Before the system even reaches system testing, the development
team is tracking their progress toward completing coding. To measure
completeness at a finer grain than use cases, they count the requirements
associated with the use cases and measure the “percentage of