Page 181 - Software and Systems Requirements Engineering in Practice

e

e
r
e
u
a
R
l
u
s
i
q
r
e
t
:
5

p
e
n
t
a
h
m
r
i
t
t
t
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 147 147
b
u
A
t
i
y

concerns in the usual sense. We normally expect requirements to state
properties of the product, whereas a factor may describe something
other than the product itself, for example, “Our programmers don’t
know application service provider (ASP) technology.” Rather than
arising from a stakeholder concern, a factor might arise from general
knowledge, from architectural experience, from legacy products,
from the history of the development organization, or from any other
source. Finally, global analysis deals simultaneously with
requirements, architecture, and project management, so some of the
factors may only bear on the product indirectly.
Here are some example factors, illustrating their diversity:
• “The product developers are spread across three locations.”
• “The license fees for a key third-party software component
will likely be around $1500 per server.”
• “There is significant market demand for both large-screen
and cell-phone versions of this type of product.”
Factors can come from anywhere. For convenience they are
grouped into three categories: product factors (typically derived from
features); technology factors, which involve the technologies available
to implement the product; and organizational factors, which involve
properties of the company or other organization that is developing
the product. These categories are further grouped into subcategories,
such as product performance, services provided, programming tools,
technical standards, staff skills, and schedule constraints. These
categories and subcategories should not be considered exhaustive;
any significant factor should be captured and addressed, whether or
not it fits neatly into one of the categories.
We try to capture the following information to describe factors:
• Category and Subcategory These are specific to the project
and are just used to help organize the factors as you collect
them.
• Name This is a short phrase that makes it easy to refer to
the factor within the team and in other documents.
• Brief statement of the factor This statement typically
consists of a single sentence, as in the preceding examples.
• Negotiability (optional) This is the “wiggle room” in the
factor today. For example, in the case of the three development
sites, one of the sites might be optional, depending on the
overall staffing needs and the skill mix required.
• Change over time (optional) This describes how the factor
might change in the future. For example, the demand for the
product on a cell phone may not be significant for another
two years. Negotiability and changeability should not be