Page 185 - Software and Systems Requirements Engineering in Practice

i
t
a
l
y
t
t

A
u
p
t
h
a
e
5
:
r

r
e
u
i
m
t
s
e
n
q
b
u
r
i
t
R
e
e

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 151 151
To document a strategy, record
• Name A short phrase
• Brief description One or two sentences
• Issues and factors affected Names of, and links to, the
issues and factors that are addressed by this strategy
• Explanation A lengthier description of the strategy
• Why it works Why the strategy satisfices the factor-goals
and issue-goals
• Expert The subject matter expert
• Unique ID, owner, status, priority, etc. The usual
requirements management attributes
• Discussion Additional information about the strategy,
including references to additional reading
Factors vs. Requirements
Although a factor is similar to a requirement, there are important
differences, as summarized in Table 5.2.
We expect both factors and requirements to be correct. However,
a requirement is supposed to be a true statement about a set of
products, whereas a factor is a true statement related to the architecture
of a product family. “Related to” is important because an architecture
is constrained by many stakeholders, not just the market requirements.
“Product family” implies that the architecture should reflect “family
planning,” leaving room for family members to grow and for new
ones to be added.
Although they must be unambiguous, factors are allowed to be
explicitly variable. The idea is that a factor expresses a multidimensional
region of values within which a combination of product requirements
will fall.
Requirement Factor
True of the product(s) True and related to the architecture
of a product family
Unambiguous Explicitly variable
Verifiable Arguable
Modifiable Readable
Consistent Conflicting
Complete Important
Traceable Yes, eventually
TABLE 5.2 Requirements and Factors