Page 172 - Software and Systems Requirements Engineering in Practice

138 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

Besides making reservations, there are many other “uses” of an
airline reservation system. It is used to make money for the software
house that built it. It is used to make a better airline reservation
system later. In fact, each major class of stakeholders will have a
different idea of what “fitness for use” means for them. For example,
• The business team cares about process speed and efficiency:
time to market and value for money spent on development.
They also care about the product’s capacity and efficiency.
• The development manager cares about code understandability
and modifiability.
• The IT department at the customer site cares about the product’s
resistance to viruses and other penetration attempts.
Choosing a good set of quality attribute requirements requires a
judicious blend of stakeholder focus and expert knowledge. You have
to satisfy the stakeholders in the short term, to keep the project going.
But, you also have to anticipate problems that the stakeholders
haven’t thought about yet. For that, you draw on your own experience
and the experience of other architecture experts. Be careful not to
bloat your requirements database with every conceivable quality
attribute, but you might want to keep a private list of attributes that
you think will become important later.

Setting Performance Targets Too Soon
Timing can be important when setting quality attribute targets. In a
recent project, the leadership team had an estimate for the throughput
needed from a certain subsystem but decided to withhold the
information from the subsystem team because
• They lacked confidence in the throughput estimate.
• The estimate would demand a high-performance design, which
would be costly and take a long time to develop.
As it turned out, the throughput estimate was correct, but the
subsystem designer had chosen a simpler design that could not provide
the required throughput. Major rework was performed, delaying the
project.
In retrospect the leadership team could have
• Documented the risk associated with uncertainty in the estimate,
and managed it along with other risks.
• Mitigated the risk, by giving the subsystem designer two
throughput estimates, and asking for a quick-and-dirty analysis
of the implications of choosing one over the other.