Page 162 - Software and Systems Requirements Engineering in Practice

128 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

A quality attribute requirement (QAR) is specified in terms of
observable, usually measurable, characteristics of the system that
indicate its fitness for use. Quality attributes may be thought of as
modifiers of the functional requirements that indicate how they are
achieved. Quality attribute requirements address all “uses” of the
system, including those where the system is a passive object rather
than an active participant, such as when the system is being sold or
when the next version of the system is being developed. Examples of
quality attributes include: capacity, security, usability, cost,
modifiability, and fault tolerance. The term nonfunctional requirement,
although still commonly used, has become a synonym for quality
attribute requirement.
A cross-cutting requirement is a requirement that applies to many
different functions of a system, often scattered across diverse
functional groups. For example, a system might require all of its “short”
interactive commands to display their results within 0.1 seconds,
whereas the “long” commands might be permitted to take time
proportional to the amount of data they process. Cross-cutting
requirements and their implications are described in Chapter 4.
An architecturally significant requirement (ASR) is any requirement
that is likely to have a substantial influence on a choice among
architectural alternatives [Bass et al. 2003]. The most significant
of these are sometimes called architectural drivers. Any sort of
requirement might be architecturally significant, but in our
experience, apart from a few “sunny day scenarios” defining the
overall functionality of the system, most architectural drivers tend
to be quality attribute requirements.
Although architecturally significant requirements are often quite
different from functional requirements, they should be analyzed and
documented in a coordinated, integrated fashion. Failure to do so can
lead to unnecessary duplication of work, or in the worst case, to
project failures due to creation of a system that does not meet the
needs of its customers [Finkelstein et al. 1996].

Quantifying Quality in Large Software Systems
by Capers Jones
Large software systems, where quality attributes become important,
have a typical size on the order of 10,000 function points.

• The failure rate of projects with applications >10,000 function
points is about 35 percent. That is, more than one application out
of three will never be finished or delivered.
• Of the applications that are delivered, more than 50 percent will
exceed their planned schedules by more than 12 calendar months.