A Use Case Primer

1
A Use Case Primer
2
The Benefits of Use Cases

• Compared to traditional methods, use cases are
  easy to write and to read.
• Use cases force the developers to think through
  the design of a system from the perspective of a
  user.
• Use cases engage the users in the requirements
  process, helping them to understand the proposed
  system and giving them a way to communicate their
  needs.
• Use cases give context for the requirements of
  the system.
• Use cases provide an ordering mechanism for
  requirements they show the ordering of things.

3
The Benefits of Use Cases (Contd)

• In most cases, developers write use cases. That
  shows they understand the requirements and accept
  responsibility for them.
• Use cases are a critical tool in the analysis
  process, helping to understand what the system
  needs to do.
• Use cases are a critical tool in the design and
  implementation process, reducing the risk of
  inconsistencies when moving from requirement to
  design to implementation.
• Use cases carry over directly into the testing
  process.
• Use cases serve as inputs to the user
  documentation.

4
What is a Use Case?

• A use case describes sequences of actions a
  system performs that yield an observable result
  of value to a particular actor. (In UML, a use
  case is represented by an oval.)

5
Use Case Basics

• Sequences of actions
• The sequences of actions describe a set of
  functions performed, an algorithmic procedure, or
  any other internal process that produces a
  result.
• The set is invoked when the actor initiates the
  use case by providing some input to the system.
• An action is atomic that is, it is performed
  entirely or not at all.

6
Use Case Basics (Contd)

• System performs
• The system works for the actor.
• It exhibits the functionality described in the
  use case and takes its orders from the actor as
  to when to do what.
• An observable result of value
• The use case must be of value to a user.
• The system must do something for the user.

7
Use Case Basics (Contd)

• A particular actor
• The particular actor is the individual or device
  that initiates the action.

8
What is an Actor?

• An actor is someone or something that interacts
  with the system. (In UML an actor is represented
  as a simple stick figure.)

9
Types of Actors

• Users
• Users act on the system and this is the most
  common type of actors.
• Other Systems or Applications
• Most software systems interact with other systems
  or applications. These are also actors.
• A Device
• Input and output devices can also be actors.

10
Mandatory Elements of a Use Case

• Name Each use case has a name which describes
  what is accomplished by interaction with the
  actor. It must be unique for each use case.
• Brief Description The purpose of the use case
  should be described in one or two sentences.
• Actors Since a use case has no meaning outside
  its use by an actor, each actor that participates
  in the use case must be listed.

11
Mandatory Elements of a Use Case (Contd)

• Flow of Events The heart of the use case is the
  event flow, usually expressed as a textual
  description of the interactions between the
  system and the actor. The flow of events can
  consist of both the basic flow, or main path
  through the use case and alternate flows which
  are executed only under certain circumstances.

12
Optional Use Case Elements

• Pre-conditions Those conditions that must be
  true before a use case can start.
• Post-conditions Conditions that describe the
  state of the system after a use case has
  completed.
• System or Subsystem In a system comprised of
  many subsystems, it must be specified whether a
  use case is a system-level use case or which
  subsystem it is identified with.

13
Optional Use Case Elements (Contd)

• Other Stakeholders It may be useful to identify
  other stakeholders who are affected by the use
  case.
• Special Requirements There may be special
  requirements (e.g., performance or throughput)
  that may be related to a use case that should be
  specified.

14
Optional Use Case Elements (Contd)

• Other Stakeholders It may be useful to identify
  other stakeholders who are affected by the use
  case.
• Special Requirements There may be special
  requirements (e.g., performance or throughput)
  that may be related to a use case that should be
  specified.

15
Building the Use Case Model

• It is a top down process that depends on first
  building a context model of the system.
• That model is successively refined until the
  detailed behaviors are understood.
• It is an iterative process in which the various
  steps are revisited over time.

16
Steps in Building the Use-Case Model

• Identify and Describe the Actors Identify all
  actors that interact with the system.
• Who uses the system?
• Who gets information from the system?
• Who provides information to the system?
• Where in the organization is the system used?
• Who supports and maintains the system?
• What other systems use the system?

17
Steps in Building the Use-Case Model (Contd)

• Identify the Use Cases and Write a Brief
  Description Identify what actors need to do to
  accomplish their tasks.
• What will the actor use the system for?
• Will the actor create, store, change, remove, or
  read data in the system?
• Will the actor need to inform the system about
  external events or changes?
• Will the actor need to be informed about certain
  occurrences in the system?

18
Steps in Building the Use-Case Model (Contd)

• Choose Use-Case names carefully a few words
  beginning with a verb is usually a good idea,
  e.g., Change Password.
• Consider the following template

Use-Case Name Actor(s) Description
19
Steps in Building the Use-Case Model (Contd)

• Identify the Actor and Use-Case Relationship
  Although only one actor can initiate a use-case,
  many use-cases involve the participation of
  multiple actors. Each use-case must be analyzed
  to see what actors interact with it.

20
Steps in Building the Use-Case Model (Contd)

• Outline the Individual Use Cases Before
  developing detailed use-cases for the system,
  outlines of each should be developed. Of
  particular interest at this point is the flow of
  events, including the basic and alternate flows.

21
Steps in Building the Use-Case Model (Contd)

• Basic flow
• What event starts the use case?
• How does the use case end?
• How does the use case repeat some behavior?
• Alternate flow
• Are there optional situations in the use case?
• What odd cases might happen?
• What variants might happen?
• What may go wrong?
• What may not happen?
• What kind of resources can be blocked?

22
Steps in Building the Use-Case Model (Contd)

• Refine the Use Cases At some point later in the
  project lifecycle, the time will be right to
  refine the use cases developed. At that time
  there are a number of additional factors to be
  considered.

23
Steps in Building the Use-Case Model (Contd)

• All alternate flows, including exception
  conditions Identifying primary alternate flows
  is straightforward, but flows due to exception
  conditions may not be clear initially.
• Pre- and Post-conditions The refinement process
  will start to identify state information that
  controls the behavior of the system

24
Use Cases and User Interfaces

• The world of use-case specification and user
  interface design tend to lead parallel lives.
• The development team must decide what choices the
  user makes given the screens, dialog boxes, and
  so on that we have presented to the user, what
  the system does based on those selections, and
  what screens, choices, and so on the system
  presents to the user.

25
The Use Cases and User Interfaces Conundrum

• How can a use case be specified if the user
  interface hasnt been designed yet?
• How can the user interface be designed to
  implement use case that have yet to be specified?

26
Use Cases and Storyboarding

• A Storyboard Defines
• Who the players are
• What happens to them
• How it happens
• If the player is a specific user and the
  interaction is between that user and the user
  interface, then storyboarding can help us
  describe how we are approaching the interaction.
• We can use iterative and incremental techniques
  to converge on the user interface and the use
  case at the same time.

27
Use Case Storyboard Example

• Use Case Sequence Inserting Online Clip Art
• (This series of steps within a larger use case
  allows the user to access an online clip art
  repository and select and insert a new clip art
  item.)
• The user puts the cursor at the desired clip art
  location and selects the function for inserting
  clip art.
• The system displays the clip art source
  locations.
• The user selects the Clip Online choice.
• The system launches the browser and automatically
  navigates to the online library.
• The user navigates to the selected art item.
• . . .