Page 186 - Software and Systems Requirements Engineering in Practice

152 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

Instead of being verifiable, factors are only expected to be
arguable, meaning that someone can make a convincing case that the
factor is true. This relaxation of rigor is important for capturing
assumptions before the “true facts” are known.
Modifiability is less important than readability, because the number
of important factors should remain small (under 100), making them
relatively easy to maintain in any case. In the customer network
example given earlier under “Factors: Beyond Requirements,”
conventional wisdom on modifiability would recommend breaking
the factor into three or four separate factors, but in truth it is a single
factor that varies in four dimensions. We also prefer not to restrict the
sentence structure of factors (as some requirements standards do), in
favor of greater expressiveness. For example, is it clearer to write, “The
architecture shall facilitate developing the framework and products
using programmers whose previous experience does not include ASP
technology” or “Our programmers don’t know ASP”? The first
alternative is verbose, vague, and might actually be incorrect, if there
is an option to hire a few ASP developers. The second alternative
succinctly captures one fact that constrains the architecture.
We expect to record contradictory factors, both because they can
represent different points of view and because one purpose of global
analysis is to discover conflicting factors and find ways to reconcile
them. For example, one stakeholder may ask for a fast, powerful
system, while another asks for a low-cost, small-footprint system.
Only later analysis will determine whether one of the stakeholder
requests is rejected, a good compromise is found, or two system
family members are produced, where one is fast and powerful and
the other is cheap and small.
The collection of factors will be incomplete because only the most
important ones can be addressed. Experience has shown that, in
practice, architects address only the top 5–10 concerns when defining
the architecture principles. So, the process of collecting factors needs
to be systematic but limited in duration, ending when the team is
reasonably confident that they have reached a point of diminishing
returns (or time has run out). Completeness has a secondary meaning
here as well: some factor descriptions will be left incomplete if they
are deemed not important enough to finish, but will not be deleted so
that they can be revisited later.
Finally, traceability of factors is important, both backward and
forward. Each factor that is deemed important must eventually be
traceable back to a source, which is typically an expert or a stakeholder.
Without such a trace, the factor has no authority over the project, either
because it isn’t true or because no stakeholder thinks it is relevant.