Chapter04 use case

ITE 321
Systems Analysis and Design
Chapter 4: Use Case Analysis
ROBERTA ROTH, ALAN DENNIS, AND BARBARA HALEY
WIXOM
4-0© COPYRIGHT 2011 JOHN WILEY & SONS, INC.

INTRODUCTION
Use cases are a means of expressing user requirements.
Use cases are used extensively in the analysis phase.
A use case represents how a system interacts with its
environment by illustrating the activities that are
performed by the users and the system’s responses.
The text-based use case is easy for the users to understand,
and also flows easily into the creation of process models
and the data model.
© Copyright 2011 John Wiley & Sons, Inc. 4-1

USE CASES
A use case depicts a set of activities that produce some output
result.
Each use case describes how an external user triggers an event
to which the system must respond.
With this type of event-driven modeling, everything in the
system can be thought of as a response to some triggering
event.
Creation of use cases is often done as a part of interview
session with users or a part of JAD sessions.

Elements of a Use Case
Basic Information
Each use case has a name and number, and brief description.
The priority may be assigned to indicate the relative significance.
The actor refers to a person, another system, or a hardware
device that interacts with the system to achieve a useful goal.
The trigger for the use case – the event that causes the use case
to begin.

Example

Preconditions
 It is common practice to create smaller, more
focused use cases breaking the whole process
down into parts.
It is important to define clearly what needs to be
accomplished before each use case begins.
 The preconditions define the state the system
must be in before the use case commences.

Normal Course
The next part of a use case is the description of
the major steps that are performed to execute the
response to the event, the inputs used for the
steps, and the outputs produced by the steps.
The normal course lists the steps.

Alternative Courses
Alternative courses depict branches (alternative
paths of the steps) in logic that also will lead to a
successful conclusion of the use case.

Postconditions
 The postconditions section of defines the final
product of the use case.
 These postconditions also serve to define the
preconditions for the next use case in the series.

Exceptions
 A use case should describe any error conditions or
exceptions that may occur as the use case steps are
performed.
These are not normal branches in decision logic, but
are unusual occurrences or errors that could
potentially be encountered and will lead to an
unsuccessful result.

Summary of Inputs and Outputs
 The final section of the use case summarizes the
set of major inputs and outputs of the use case,
along with their source or destination.

Additional Use Case Issues
 Additional sections may be included, e.g.,
- Frequency of use
- Business rules
- Special requirements
- Assumptions
- Notes and issues

Chain of use cases – an example

Alternative Use Case Formats
 A full-dressed use case is very thorough, detailed,
and highly structured.
 The project team may decide that a more casual
use case format is acceptable.

Example

Use Cases and the Functional Requirements
 Use cases are very useful tools to us to understand user requirements.
However, use cases only convey the user’s point of view.
 Transforming the user’s view into the developer’s view by creating
functional requirements is one of the important contributions of system
analyst.
 The derived functional requirements give more information to the
developer about what the system must do.

Example

Use Cases and Testing
Building Use Cases
 Step 1: Identify the major use cases

Step 2: Identify the major steps for each use case

Step 3: Identify elements within steps

Step 4. Confirm the use case

23
Building Use Cases
© Copyright 2011 John Wiley & Sons, Inc.

Use Cases
Step 1 Identify the actors
As we read the scenario, define those people or systems
that are going to interact with the scenario.
 A patient calls the clinic to make an appointment for a
yearly checkup. The receptionist finds the nearest empty
time slot in the appointment book and schedules the
appointment for that time slot. "

5 - 25
Actors
 The labeled stick figures on the diagram represent actors
 An actor is not a specific user, but a role that a user can play while
interacting with the system.
 An actor can also represent another system with which the current
system interacts.
 In this case, the actor optionally can be represented by a rectangle with
<<actor>> and the name of the system.
 Actors can provide input to the system, receive output from the system,
or both.

Questions for Identifying People Actors
Who is interested in the scenario/system?
Where in the organization is the scenario/system be
used?
Who will benefit from the use of the scenario/system?
Who will supply the scenario/system with this
information, use this information, and remove this
information?
Does one person play several different roles?
Do several people play the same role?

Actors
An Actor is outside or external the system.
It can be a:
– Human
– Peripheral device (hardware)
– External system or subsystem
– Time or time-based event
Represented by stick figure

5 - 28
Notations

5 - 29
Notations

5 - 30
Notations

5 - 31
Notations

5 - 32
Notations

Use Cases
 The picture below is a Make Appointment use case for the medical
clinic.
 The actor is a Patient. The connection between actor and use case is a
communication association (or communication for short).
Actors are stick figures. Use cases are ovals. Communications are lines that link actors to use cases.
Actors are stick figures. Use cases are ovals. Communications are lines that link
actors to use cases.
4-33

Use Case - Relationships
Relationships
– Represent communication between actor and use
case
– Depicted by line or double-headed arrow line
– Also called association relationship
Make
Appointment

Use Case - Relationships
Boundary
– A boundary rectangle is placed around the perimeter
of the system to show how the actors communicate
with the system.
Make
Appointment

Use Case Diagram
Other Types of Relationships for Use
Cases
–Generalization
–Include
–Extend

Components of Use Case Diagram
Generalization Relationship
– Represented by a line and a hollow arrow
• From child to parent
Child use case Parent use case

Example of Relationships
5 - 40

Use Case Diagram
Include Relationship
–Represents the inclusion of the functionality of one
use case within another
–Arrow is drawn from the base use case to the used
use case
–Write << include >> above arrowhead line

Use Case Diagram
Extend relationship
–Represents the extension of the use case to include
optional functionality
–Arrow is drawn from the extension use case to the
base use case
–Write << extend >> above arrowhead line

Example of Relationships
5 - 45

Benefits of Use Cases
 Use cases are the primary vehicle for requirements capture in RUP
 Use cases are described using the language of the customer (language
of the domain which is defined in the glossary)
 Use cases provide a contractual delivery process (RUP is Use Case
Driven)
 Use cases provide an easily-understood communication mechanism
 When requirements are traced, they make it difficult for requirements
to fall through the cracks
 Use cases provide a concise summary of what the system should do at
an abstract (low modification cost) level.

SUMMARY
A use case contains all the information needed to build one
part of a process model, expressed in an informal, simple
way.
When writing a use case,
- identify the triggering event,
- develop a list of the major steps,
- identify the input(s) and output(s) for every step,
- have the users role-play the use case to verify.

Chapter04 use case

More Related Content

Similar to Chapter04 use case (20)

Recently uploaded (20)

Chapter04 use case