Page 143 - Software and Systems Requirements Engineering in Practice

110 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

Every actor must communicate with at
least one concrete use case via a
boundary. Actors can only communicate
with use cases through boundaries
(except for the context diagram).

Teller Account Information Provide Banking
User Interface Services

Teller Account Information View Account
User Interface Balance
FIGURE 4.22 Illustrating the correct and incorrect way for an actor to
communicate with a use case

We prefer the use of boundaries in the analysis model to distinguish
them from interfaces in the design model. A boundary symbol and an
interface symbol are different, and, depending on the modeling tool,
can be selected by choosing the artifact stereotype. Actors should be
shown communicating with concrete use cases through actors at the
lowest possible level. For example, instead of having a boundary
“Bank_Computer_Boundary,” there would be “Find_Customer_
Boundary,” “View_Customer_Account_Boundary,” “Cash_Customer_
Check_Boundary,” and so on. While this may appear to be a lot of
extra work, in reality it saves a significant amount of time in that when
the analysis model is complete, the architect will have a complete
inventory of every form, partial form, or other interface type needed
for each function (see Figure 4.23).

Report
Interface Actors Diagrams
Account for Cost Account for Cost
Interface [Use Case]
Add Location IS Worker Add Location
Generates Interface [Use Case]
Allocate Payment Cashier Allocate Payment
Interface [Use Case]
Approve Adjustment Collection Approve Adjustment
Interface Supervisor [Use Case]
Archive Encounter IS Worker Archive Encounter
Interface [Use Case]
… … …
FIGURE 4.23 Creating a boundary report