Page 183 - Software and Systems Requirements Engineering in Practice
P. 183
149
Q
u
5
:
a
t
y
l
i
h
a
t
s
p
r
t
e
q
u
R
e
i
m
e
r
e
t
r
A
t
i
t
e
b
u
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 149
“Softness” is a hallmark of architecture-influencing factors. Softness
is inevitable because much of the analysis must be performed before
the hard facts are known. We find that factors often need to capture
four kinds of softness: range, change over time, uncertainty, and
negotiability. These can all be present in a single factor. For example,
“Customers’ networks currently have 100 to 100,000 nodes. The
upper end of this range will increase every two years by a factor
of 1.5 to 3. Our architecture may not have to cover the low end of
the range, if expected sales don’t justify the cost.”
This factor illustrates range (100 to 100,000 nodes), evolution over
time (will increase every two years), probability (factor of 1.5 to 3),
and negotiability (expected sales vs. cost). Although this example
expresses probability with numbers, a factor is permitted to use
qualitative words like “probably,” “likely,” “might,” and “could” to
express uncertainty. Negotiability links this factor to other factors,
giving some idea of how variations in one affect the other. Although
it may be tempting to split such a factor into four different factors,
each addressing one kind of softness, don’t make the split unless you
are confident that the different factors are relatively independent of
each other. Allowing softness in an architecture factor thus allows the
architect to document a factor and make plans concerning it before
the uncertainty is resolved.
Unlike requirements catalogs, the collection of architecture factors
does not have to be complete. Global analysis prioritizes them, finds
conflicts and tradeoffs between them, and finally reduces them to a
set of key issues that shape the architecture. The less important factors
will likely be ignored, for most purposes, so missing a few of them
is okay.
Issues
The purpose of documenting issues is to identify the aspects of the
project that are going to be hard to accomplish. A global analysis issue
is a potential conflict or tradeoff between two or more factors—
usually many more! For example, the issue “Aggressive Schedule”
might be described as, “The project probably can’t be completed in
the 14 months currently budgeted if we have to train our programmers
in Java, add new tools to our development environment, and
implement all 75 major features, using a novel user interface concept.”
Implicit in that statement are the factors
• Develop in 14 calendar months
• Programmers don’t know Java
• Seventy-five major features
• Novel user interface concept