Page 145 - Software and Systems Requirements Engineering in Practice

112 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

Avoid Passive Objects
A passive object is one that receives messages but never sends any
(including replies). Broadcasting messages where there is no
mechanism for determining whether the message was received may
cause instabilities or unreliable behavior and is not recommended.
Avoid Loquacious Objects
Loquacious objects are those that send many messages to other objects
without receiving any. Although sometimes necessary, they can lead
to instability and poor performance.
Coherent Low-Level Processes Should Be Defined
with State or Activity Diagrams
As previously mentioned, a concrete use case is defined by showing
temporal behavior with sequence, state chart, or activity diagrams. If
the use case does not include and is not extended by use cases, then it
is a “leaf” or terminal use case and should be defined with a state or
activity diagram or perhaps with just a paragraph of text. If there are
many possible scenarios associated with the use case, then an
overview activity diagram should be used and each individual
scenario can hyperlink from the “all paths” activity diagram associated
with the use case.

Elicit Requirements and Processes by Starting
at Boundaries and Modeling Inward
The static relationships between processes and their associated
requirements are defined first using use case diagrams. As concrete
use cases are exposed, their communication with actors is discovered
and boundaries (e.g., a class with a boundary stereotype) are defined.
Hide Complexity by Using Compound Business Objects
On a high-level sequence diagram a compound object such as a
“Master Schedule” will hide complexity. On a lower-level diagram,
“Master Schedule” will be decomposed into the objects that contribute
to processes (such as an inventory object that could determine if an
item is in stock and, if so, which warehouse it is in).

Initiate Prototyping Efforts Quickly
Prototyping is an extremely valuable way of eliciting requirements
from subject matter experts. There are normally two types of
prototypes. The marketing prototype is a “throwaway” tool to elicit
customer interest and define potential product features. It is treated
as a background reference when modeling. The requirements
prototype may be reusable; prototype development and model
development are synchronized such that each provides information
that assists in defining the other (see Chapter 9).