Information Technology Reference
In-Depth Information
unique name and brief description that clearly describes the goals for each use
case. If the candidate use case does not have goals, ask yourself why it exists, and
then either identify a goal or eliminate the use case. The following process
describes a technique that can be used to identify use cases:
First, prioritize the candidate list based on user input and importance to the
release being built and begin describing the use cases. Define the use case, con-
sidering the system as a black box, and focus on the interaction of the actors with
the system. Remember that use cases can be represented both textually and
graphically.
Next, describe the main interactions with the system. Focus on the priority use
cases and on the basic course. These priority use cases are sequences of events and
interactions that contain fundamental information about the system functions.
Consider each primary function of the system in order to properly document
decisions made about the actions and sequence, provide an effective communi-
cation vehicle for requirements, and serve as a set of instructions for the final
implementation. Focus on the main interactions in the system. Start with an
external user's interactions with the system (e.g., for a bank, start with deposit
cash, withdraw cash). Create a narrative that describes what happens as the system
responds to the event. Use a checklist of questions to help build a complete
description. Assess your descriptions using the guidelines for use case descriptions
and the use case quality checklist. Use a sequence diagram to show the messages
and responses of the objects with each other to complete the sequence. In analysis,
describe the message with descriptive text. As the model is refined, use message
names and parameter lists. Remember that use cases do not define the object
model. Return to the object model to review inheritance, examine state transitions,
or document flow of control.
The next step is to structure the use case. Use cases most often deal with
varying degrees of complexity. Each use case considers only those objects relevant
to the use case itself. An individual object may participate in many use cases. All
responsibilities of an object are easily identified by considering all of the use cases
in which it participates. Even the most complex systems can usually be described
with a modest number of high-level use cases. These high-level use-cases, of
course, can be used for organization as many more detailed use cases as are
required by the given project. As the object model gets larger and more complex,
use cases may be identified for subsets of the entire model, in an effort to refine the
interactions and responsibilities of objects at a more detailed level.
Finally, the use case should be extended to subordinate use cases. A subordinate
use case is a sequence of events and interactions that contains supplemental
information about the system functions. The subordinate use case is used to
document the following:
• Alternate paths through the sequence.
• Exceptions.
• Variations in the main functionality.
