Page 161 - Software and Systems Requirements Engineering in Practice

e

A
b
u
t
t
a
l
t
t
i
i
r
e
t
:
5

e
q
u
p
a
h
u
e
m
r
r
y
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 127 127
t
e
n
R
i

• They come from many more sources than just the customer,
such as stakeholders within the development organization,
regulatory agencies, available implementation technologies,
and implementations of previous products.
• They have a longer-term impact on the product than most
functional requirements, because a good architecture is
expected to remain stable through several releases of the
product.
• Some of them are highly subjective or difficult to articulate.
• Many have a continuous, quantitative nature, in contrast to
discrete, logical functional requirements. Instead of being
pass/fail criteria, they are often expressed as measures of the
goodness of a system, which must be calibrated to the
stakeholders’ expectations. Different measures must be
traded off against each other to reach an architecture that is
“good enough” according to each of the measures.
• They have nonobvious interactions with each other, due to
(future) implementation decisions. Many stakeholders don’t
understand the architectural implications of what they need,
so they are likely to overlook some of their quality attribute
requirements, i.e., until an architect asks the right question.
• The architecture must anticipate change: in the functional
requirements, in business conditions, in available
technologies, in the development organization itself, etc.
The architecture must also be stabilized while many
functional and business requirements are still unstable.
• Architecturally significant requirements (ASRs) can be
difficult to test before the system is operational.
• Some ASRs are passive in nature, such as cost and ease of use.
Feedback on these may emerge gradually instead of being
directly testable.
• They often have cross-cutting impact, making shortcomings
difficult to correct after development has progressed, and
thus making them high risk.
Terminology
Several different terms are commonly used to refer to requirements
that determine the architecture of a system. A functional requirement
is “a requirement that specifies a function that a system or system
component must be able to perform” [IEEE 1990]. In other words,
the functional requirements define what the system is supposed
to do.