Page 78 - Software and Systems Requirements Engineering in Practice

50 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

Bicycle
Attractive to
Customers
+
+ +
High Quality Low Cost Low Weight
+ +
–
Titanium
Gears

FIGURE 3.5 Simple goal model fragment

the optimal goal set can be calculated. However, the reality is that the
contribution of many high-level requirements cannot be calculated for
a variety of reasons, including changing demographics, rapid shifts in
technology, etc. Sometimes, difficulties associated with conflicting
goals are not recognized until the requirements have gone through a
complete review cycle. The refinement of nonfunctional requirements
can bring to light issues that may otherwise remain hidden. The
importance and impact that nonfunctional requirements can have
warrant their consideration and elicitation as early as possible in
the product development cycle.
Goal models can be as simple or as complex as necessary.
Figure 3.6 shows some of the goals for a nuclear power plant
simulator. Such simulators, mandated by regulation, are used to
train the operators of nuclear power plants and must have high
fidelity and reliability. The figure shown identifies quality assessment
methods, or QAMs, that are used to determine how well the business
goals meet the desired quality [Cleland-Huang 2005]. For example,
QAM 5 states that when any action is taken, the simulator indicator
light response shall be within 200 milliseconds of the response in the
real plant. That is, if a button is pressed in the power plant closing a
valve and an indicator light comes on in three tenths of a second,
then in the simulator, that light must come on within three to five
tenths of a second. The actual QAM was evaluated by randomly
connecting an oscilloscope to button/light pairs (there were
thousands of such pairs) in the simulator and determining that the
response was within specification by measuring the step wave on
the oscilloscope. Goal models with QAMs can be used as checklists
to ensure that important nonfunctional requirements have not been
overlooked. If a QAM cannot be defined for a nonfunctional
requirement, then it may not be possible to test that the requirement
has been met, and the requirement should then not be part of a
contract or requirements specification, as it may not be feasible to
implement.