Chapter 4 Use Case Analysis
Introduction








What is the role of Use Cases?
o Use cases are used to explain and document the interaction that is required between the user and
the system.
o Use cases help us understand and clarify the user’s required interaction with the system and can
help us fully understand the functional requirements of the system
o A use case represents how the system interacts with its environment by illustrating the activities
that are performed by the user and how the system reacts to them.
o Goal: to create a set of use cases that describe all the tasks tat users need to perform using the
system
How do use cases contribute to the functional requirements?
o Use cases are often thought as the functional or external view of a business process, showing
how the users view the process rather than the internal mechanisms.
o User involvement ensures that users’ in sights are explicitly incorporated into the new system
Why is the System Proposal critical in the analysis phase?
o The System Proposal contains the user requirements.
o User requirements: the things the user needs to accomplish with the new system; or, what the
new system needs to do to help the user
o Use cases help express user requirements
How do we determine the requirements?
o One way to determine the requirements is to understand the things the users need to accomplish
with the new system.
What are some problems with traditional requirements elicitation techniques, such as asking the users
what they wanted the system to do?
o The user may not know what is and is not possible to do
o Users may have difficulty envisioning new wats to redesign business processes
o Users may not be able to identify business needs
 Get confused with wants
o Users may not understand process and data models
What are business scenarios?
o Traditional system development technique used to describe user interactions with the system
Use cases are helpful in:
1. Determine the functional requirements
2. Understanding, exceptions, and error handling requirements.
3. Flows easily into data and process models.
4. i.e. websites and applications
Use cases are not as useful in:
1. Batch processes
2. Computational intensive applications
3. Data warehousing
4. Programs with limited user interaction
What is a Use Case?


A use case depicts a set of activities performed to produce some output result.
Each use case describes how an event triggers action

An event-driven modelling
The Use Case Concept in a Nutshell


A use case shows what the functional requirements of the system is, but does not go extensively into the
programming features
i.e. The kiosk system will:
o enable the user to begin a transaction
o display a list of purchase transaction options that are available on the kiosk
o enable the user to specify the type of purchase transaction desired
Use Case Formats and Elements


Elements of a Use Case
o Each use case has a name and number, and brief description
o The priority may be assigned to indicate the relative significance
o The actor refers to a person, another system, or a hardware device that interacts with the system
to achieve a useful goal
o The trigger for the use case – the event that causes the use case to begin
o Events triggers can be
 External: outside environment driven (customer action, user action)
 Temporal: time driven
Casual Use Case Format
Basic Information
Normal Course
- The major steps
that are performed
to execute the
response to the
event

o
Use case in sequences
o

Fully-Dressed Use Case Format
o
o Adds new sections:
 Alternative courses
 Inputs and outputs for steps
 Summary inputs and outputs
o Use this format when:
 Users are not closely engaged with development team
 Project has high complexity and high risk
 Test cases need to be fully described
 Remote collaborating teams need detailed, shared understanding of user needs
Creating Use Cases
 Identify events the system must respond to – develop Event-Response List
 Create use case form for the complex events
 For each use case:
o Identify the major steps
o Identify elements with each major step (inputs and outputs)
o Confirm use case with users through role-playing
 Revise functional requirements as needed