The document discusses use case analysis in systems analysis and design. It describes what use cases are, how to write them, and how they are used. Key elements of a use case include actors, triggers, steps, inputs, outputs, alternatives, exceptions, and preconditions and postconditions. Use cases are developed through interviews and help express user requirements to guide system development.
1 of 49
More Related Content
Chapter04 use case
1. 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.
2. 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
3. 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.
? Copyright 2011 John Wiley & Sons, Inc. 4-2
4. 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 ¨C the event that causes the use case
to begin.
? Copyright 2011 John Wiley & Sons, Inc. 4-3
6. 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.
? Copyright 2011 John Wiley & Sons, Inc. 4-5
7. 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.
? Copyright 2011 John Wiley & Sons, Inc. 4-6
8. 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.
? Copyright 2011 John Wiley & Sons, Inc. 4-7
9. 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.
? Copyright 2011 John Wiley & Sons, Inc. 4-8
10. 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.
? Copyright 2011 John Wiley & Sons, Inc. 4-9
11. 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.
? Copyright 2011 John Wiley & Sons, Inc. 4-10
12. Additional Use Case Issues
? Additional sections may be included, e.g.,
- Frequency of use
- Business rules
- Special requirements
- Assumptions
- Notes and issues
? Copyright 2011 John Wiley & Sons, Inc. 4-11
14. Chain of use cases ¨C an example
? Copyright 2011 John Wiley & Sons, Inc. 4-13
15. 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.
? Copyright 2011 John Wiley & Sons, Inc. 4-14
17. 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.
? Copyright 2011 John Wiley & Sons, Inc. 4-16
25. 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. "
? Copyright 2011 John Wiley & Sons, Inc. 4-24
26. 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.
? Copyright 2011 John Wiley & Sons, Inc.
27. 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?
? Copyright 2011 John Wiley & Sons, Inc. 4-26
28. Actors
?An Actor is outside or external the system.
?It can be a:
¨C Human
¨C Peripheral device (hardware)
¨C External system or subsystem
¨C Time or time-based event
?Represented by stick figure
? Copyright 2011 John Wiley & Sons, Inc. 4-27
34. 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
35. Use Case - Relationships
?Relationships
¨C Represent communication between actor and use
case
¨C Depicted by line or double-headed arrow line
¨C Also called association relationship
Make
Appointment
? Copyright 2011 John Wiley & Sons, Inc. 4-34
36. Use Case - Relationships
?Boundary
¨C A boundary rectangle is placed around the perimeter
of the system to show how the actors communicate
with the system.
Make
Appointment
? Copyright 2011 John Wiley & Sons, Inc. 4-35
37. Use Case Diagram
A use case diagram is a collection of actors, use cases, and their communications.? Copyright 2011 John Wiley & Sons, Inc.
5 - 36
38. Use Case Diagram
?Other Types of Relationships for Use
Cases
¨CGeneralization
¨CInclude
¨CExtend
? Copyright 2011 John Wiley & Sons, Inc. 4-37
39. Components of Use Case Diagram
?Generalization Relationship
¨C Represented by a line and a hollow arrow
? From child to parent
Child use case Parent use case
? Copyright 2011 John Wiley & Sons, Inc. 4-38
42. Use Case Diagram
?Include Relationship
¨CRepresents the inclusion of the functionality of one
use case within another
¨CArrow is drawn from the base use case to the used
use case
¨CWrite << include >> above arrowhead line
? Copyright 2011 John Wiley & Sons, Inc. 4-41
44. Use Case Diagram
?Extend relationship
¨CRepresents the extension of the use case to include
optional functionality
¨CArrow is drawn from the extension use case to the
base use case
¨CWrite << extend >> above arrowhead line
? Copyright 2011 John Wiley & Sons, Inc. 4-43
48. 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.
? Copyright 2011 John Wiley & Sons, Inc. 4-47
49. 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.
? Copyright 2011 John Wiley & Sons, Inc. 4-48