• Actors
  • Use Cases
  • Questions to help identify use cases[11]
  • Use case diagrams
  • Use case diagrams - include and extend
  • Wrapping Up Use Case Modeling
  • .

Use case modeling

Actors

• An actor is anyone or anything that must interact with the system.
• An actor is not part of the system.
• Actors are typically found in the problem statement, and by conversations with customers and domain experts.
• Actors are drawn as a stick figures.
• When dealing with actors it is important to think about roles.

Questions to help identify actors

• Who is interested in a certain requirement?
• Who installs the system?
• Who starts and stops the system?
• Where in the organization is the system used?
• Who will benefit from use of the system?
• Who will supply the system with this information, use this information, and remove this information?
• Who will support and maintain the system?
• Does the system use an external resource?
• Does one person play several different roles?
• Do several people play the same role?
• Does the system interact with a legacy system?
• What other systems use this system?
• Who gets information from this system?

Use Cases

Use Case - a sequence of actions that an actor performs within a system to achieve a particular goal. The purpose of this stage is to capture user requirements of the new system using use case diagrams.

• Definition: A sequence of actions that an actor performs within a system to achieve a particular goal.
• A use case describes one or more courses through a user operation. The basic course must always be present; alternate courses are optional.
• Basic course - the main start-to-finish path the user will follow under normal circumstances.
• Alternate course - infrequently used path, an exception, or an error condition.
• Stated from the perspective of the user as a present-tense verb phrase in an active voice (AdmitPatient, Do Trade Entry, Generate Reports).
• Describes one aspect of usage of the system without presuming any specific design or implementation.
• Ask "what happens?"
• "Then what happens?"
• Be relentless.
• All required system functionality should be described in the use cases.
• Actor - represents a role a user can play with regard to a system.
• A user can serve as more than one type of actor.
• Use cases appear as ovals, generally in the middle of a use case diagram.
• Analysis level and design level use cases.
• Should be able to write a solid paragraph or two about a design-level use case.
• Use cases should have strong correlations with material in the user manual for the system (write the manual, then write the code). (Write the manual as though the system already exists.)
• Use rapid prototyping as frequently as possible.
• If you're reengineering an existing legacy system, work from the user manual backward.
• A use case captures some user-visible function.
• A use case achieves a discrete goal for the user.
• A use case may be large or small.
• Use cases model a dialogue between an actor and the system.

Questions to help identify use cases[11]

• What are the tasks of each actor?
• Will any actor create, store, change, remove, or read information in the system?
• What use case will create, store, change, remove, or read this information?
• Will any actor need to inform the system about sudden, external changes?
• Does any actor need to be informed about certain occurrences in the system?
• What use cases will support and maintain the system?
• Can all functional requirements be performed by the use cases?

Use case diagrams

• Use case diagrams identify use cases and actors of the system.
• Use case-actor relationships are shown with association lines.
• Use cases appear as ovals, generally in the middle of a diagram.
• Use cases appear at various levels of detail; two such levels are analysis-level and design-level.

Use case diagrams - include and extend

• One use case can use or extend another use case.
• The secondary (sub-level) use case is not associated directly with an actor.
• Stereotypes
• «includes» - use/include a piece of behavior that is similar across more than one use case.
• «extends» - one use case is similar to another, but does more.

Wrapping Up Use Case Modeling

Feel comfortable when you've achieved the following goals:

1. Your use cases account for all of the desired functionality of the system.
2. You have clear and concise descriptions of the basic course of action, with appropriate alternate courses of action.
3. You have factored out common scenarios.

.