ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo
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.
? Copyright 2011 John Wiley & Sons, Inc. 4-2
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
Example
? Copyright 2011 John Wiley & Sons, Inc. 4-4
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
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
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
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
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
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
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
12
Chain of use cases ¨C an example
? Copyright 2011 John Wiley & Sons, Inc. 4-13
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
Example
? Copyright 2011 John Wiley & Sons, Inc. 4-15
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
Example
? Copyright 2011 John Wiley & Sons, Inc. 4-17
18
Use Cases and Testing
Building Use Cases
? Step 1: Identify the major use cases
? Copyright 2011 John Wiley & Sons, Inc. 4-19
Step 2: Identify the major steps for each use case
? Copyright 2011 John Wiley & Sons, Inc. 4-20
Step 3: Identify elements within steps
? Copyright 2011 John Wiley & Sons, Inc. 4-21
Step 4. Confirm the use case
? Copyright 2011 John Wiley & Sons, Inc. 4-22
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. "
? Copyright 2011 John Wiley & Sons, Inc. 4-24
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.
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
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
5 - 28
Notations
? Copyright 2011 John Wiley & Sons, Inc.
5 - 29
Notations
? Copyright 2011 John Wiley & Sons, Inc.
5 - 30
Notations
? Copyright 2011 John Wiley & Sons, Inc.
5 - 31
Notations
? Copyright 2011 John Wiley & Sons, Inc.
5 - 32
Notations
? Copyright 2011 John Wiley & Sons, Inc.
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
¨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
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
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
Use Case Diagram
?Other Types of Relationships for Use
Cases
¨CGeneralization
¨CInclude
¨CExtend
? Copyright 2011 John Wiley & Sons, Inc. 4-37
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
39
Example of Relationships
? Copyright 2011 John Wiley & Sons, Inc.
5 - 40
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
42
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
44
Example of Relationships
? Copyright 2011 John Wiley & Sons, Inc.
5 - 45
46
Sample
Use Case
Diagram
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
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

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
  • 5. Example ? Copyright 2011 John Wiley & Sons, Inc. 4-4
  • 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
  • 13. 12
  • 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
  • 16. Example ? Copyright 2011 John Wiley & Sons, Inc. 4-15
  • 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
  • 18. Example ? Copyright 2011 John Wiley & Sons, Inc. 4-17
  • 19. 18
  • 20. Use Cases and Testing Building Use Cases ? Step 1: Identify the major use cases ? Copyright 2011 John Wiley & Sons, Inc. 4-19
  • 21. Step 2: Identify the major steps for each use case ? Copyright 2011 John Wiley & Sons, Inc. 4-20
  • 22. Step 3: Identify elements within steps ? Copyright 2011 John Wiley & Sons, Inc. 4-21
  • 23. Step 4. Confirm the use case ? Copyright 2011 John Wiley & Sons, Inc. 4-22
  • 24. 23 Building Use Cases ? Copyright 2011 John Wiley & Sons, Inc.
  • 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
  • 29. 5 - 28 Notations ? Copyright 2011 John Wiley & Sons, Inc.
  • 30. 5 - 29 Notations ? Copyright 2011 John Wiley & Sons, Inc.
  • 31. 5 - 30 Notations ? Copyright 2011 John Wiley & Sons, Inc.
  • 32. 5 - 31 Notations ? Copyright 2011 John Wiley & Sons, Inc.
  • 33. 5 - 32 Notations ? Copyright 2011 John Wiley & Sons, Inc.
  • 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
  • 40. 39
  • 41. Example of Relationships ? Copyright 2011 John Wiley & Sons, Inc. 5 - 40
  • 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
  • 43. 42
  • 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
  • 45. 44
  • 46. Example of Relationships ? Copyright 2011 John Wiley & Sons, Inc. 5 - 45
  • 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