Page 142 - Software and Systems Requirements Engineering in Practice

109
R e q u i r e m e n t s M o d e l i n g
C h a p t e r 4 :
C h a p t e r 4 : R e q u i r e m e n t s M o d e l i n g 109
In this “Cash Check” scenario, we
discover that a business object is
needed that can retrieve a
customer’s account information.
?
Customer
: Bank Teller
Cash a check
Can I see your ID? Discovered
ID
Get account information
(customer name)

FIGURE 4.21 Using scenarios to discover needed business objects

Discover Business Objects and Their Services Through Use Case
Definition with Sequence Diagrams
Modelers with a development background sometimes start building
a model by defining classes and then drawing class diagrams. This
skews the model and makes it data-centric. Sequence diagrams
consist of objects and messages. When objects are placed on diagrams,
they initially will not belong to a class. The objects needed are
discovered by identifying services that have to be provided, and then
identifying who will provide them (see Figure 4.21).

Every Service in a Business Object Should Have Defined
Pre- and Post-Conditions
In an analysis model, services are discovered using sequence
diagrams, usually as messages. The messages are then incorporated
into the servicing object as services or methods. Pre- and post-
conditions are then attached. In order to distinguish “none” from an
oversight, an entry can be made indicating that there are no pre-post-
conditions.

A Boundary or Interface Should Only Communicate
with a Concrete Use Case
An abstract use case is an arbitrary container for a set of features, some
of which may not require an interface. Consequently interfaces or
boundaries permitting communication between an actor and a use
case should only be associated with concrete use cases (Figure 4.22).