Page 83 - Software and Systems Requirements Engineering in Practice

54 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

“Analytic Hierarchy Process” (AHP), is where the stakeholder or
analyst ranking the requirements looks at only two requirements,
compares them, and ranks them; e.g., the more important of the two is
placed higher in a list. This process is done iteratively until all the
requirements have been ranked. While the approach may work well
for small requirements sets, as the number of requirements N increases,
the number of rankings that must be done increases quadratically
(N(N – 1)/2) [Sheehan et al. 2000]. Since different stakeholders may
rank the same requirements set differently, an approach must be
formulated to merge the different sets of ranked requirements. We
therefore recommend that a pairwise ranking prioritization be
restricted to stakeholder requests or product features (near the top of
the pyramid), to reduce the ranking effort.
Another technique used to prioritize requirements is the “planning
game,” or PG, approach, popularized with extreme programming
[Beck 1999]. In the PG approach, stakeholder requests, features, or
requirements (depending on when prioritization takes place) are
partitioned into three sets that align with Kano qualities: “needed for
the system to function,” “add real value,” and “nice to have but not
necessary.” An informal risk analysis is done to determine the ease of
implementation effort, and a final decision is made as to which
features or requirements to implement.
Ranking cannot take place in a vacuum; e.g., the cost and risk
associated with implementation must be known. Furthermore, in
some industries additional factors such as hazards (to the consumer)
and technology shifts must be considered. For example, a novel
technique for opening and closing car windows is evaluated that uses
a light sensor; i.e., no physical contact with the switch is required. The
cost to implement is low, customers evaluate the feature very highly,
and it seems to have high positive emotional value. However, the
hazard analysis (see Chapter 11) indicates the potential for an unsafe
condition, as a child can be hurt or injured when the window rises
accidentally. As a result, the feature is not included in the next year’s
car model.
In summary, initial prioritization of stakeholder requests should
take place as early in a product life cycle as possible. Several
prioritization activities may be needed, one just for the stakeholders,
another when the architect or designers evaluate the cost and risk of
implementation, and possibly additional sessions prior to the build/
no build decision. Prioritization should be accomplished as far up the
requirements pyramid as is feasible, with ranking taking place once
the requirements are sufficiently finalized such that the cost and
resource impact of implementation is understood. Furthermore, some
techniques such as pairwise ranking may not be feasible with a large
number of requirements, e.g., rank at the feature level and not at the
system level. Prioritization (and the ranking of small sets of requests)
can be combined with the stakeholder review process where the