SEEM3430 Information

Systems Analysis and Design

Qianyu Chen
Department of Systems Engineering and Engineering
Management
The Chinese University of Hong Kong
[email protected]
October 23, 2024
What is use case?

How to do use case analysis?

OVERVIEW
• Use case diagram
• Identify use case
• Write a use case
Conclusion

Questions
BIG PICTURE
USE CASE
 What is a Use Case?  Why Use Cases?
 A use case represents how a system  Captures user requirements
interacts with its environment. effectively.
 It shows the activities performed by users
 Focuses on user interactions with the
and the system's responses.
 They are an essential tool for
system.
understanding user needs and system  Helps in identifying the functional
behavior. behavior of the system.
 When are Use Cases Used?  Key Benefits of Use Cases
 Primarily used in the Analysis Phase.  Enhances communication between
 Helps to clarify what the system stakeholders and developers.
should do before moving to design  Simplifies understanding of system
and implementation. requirements.
 Acts as a foundation for further
development stages.
USE CASE TECHNIQUES
 Key Use Case Techniques:  Visual Modeling
 Visual Modeling  Use Case Diagram:
 Textual Documentation  A visual representation of the system’s use
 Combining Visual and Textual: cases.
 Use case diagrams give a clear overview.  Typically used alongside textual descriptions to
give context.
 Textual use cases add depth and detail
 Provides a higher-level view of the system.
for precise understanding.
 Often referred to as "blueprints for your system"
 Textual Documentation  Use Case Diagrams vs Textual Use
 Written in detailed templates to describe Cases
the system’s behavior in various scenarios  Use Case Diagram: Offers a simplified,
 Textual use cases provide in-depth detail graphical view of what the system must
about every possibility. do.
 Complements use case diagrams by  Textual Use Case: Provides the complete
offering specific interactions and and detailed documentation of system
exceptions. interactions.
USE CASE DIAGRAM
 Visual Representation: A use case diagram is used to graphically
depict a subset of the use-case model, simplifying communication.
 Main Purpose: It helps illustrate user interactions with the system,
providing a clear and concise view of system functionality.
 Textual Specifications: While use case diagrams are visual, much
of the use case model is actually textual. Each use case has detailed
event flow specifications that describe how the system responds to
user actions.
 Summary: The use case diagram gives an overview, while the
textual specifications provide details. Together, they facilitate better
communication and ensure accuracy in system design.
 TEXTUAL AND SYMBOL

• Actors are external entities that interact with the system. These can include users,
other systems, or hardware devices.
• Use cases are like scenes in the play. They represent specific things your system
can do.
• The system boundary is a visual representation of the scope or limits of the
system you are modeling. It defines what is inside the system and what is outside.
RELATION REPRESENTATION
 Relationship
 The Association Relationship represents a communication or interaction between an actor and
a use case. It is depicted by a line connecting the actor to the use case. This relationship
signifies that the actor is involved in the functionality described by the use case.
 The Include Relationship indicates that a use case includes the functionality of another use
case. It is denoted by a dashed arrow pointing from the including use case to the included use
case. This relationship promotes modular and reusable design.
 The Extend Relationship illustrates that a use case can be extended by another use case under
specific conditions. It is represented by a dashed arrow with the keyword “extend.” This
relationship is useful for handling optional or exceptional behavior.
 The Generalization Relationship establishes an “is-a” connection between two use cases,
indicating that one use case is a specialized version of another. It is represented by an arrow
pointing from the specialized use case to the general use case.
 EXAMPLE

 Example: Online Banking  Example: Social Media Posting  Example: Flight Booking System  Example: Vehicle Rental
System  Use Cases: Book Flight, Select System
 Use Cases: Compose Post, Add
 Actor: Customer Image Seat  Use Cases: Rent Car, Rent
  Extend Relationship: The Bike
Use Case: Transfer Funds  Include Relationship: The
 “Compose Post” use case “Select Seat” use case may  Generalization
Association: A line connecting extend the “Book Flight” use
includes the functionality of Relationship: Both “Rent
the “Customer” actor to the case when the user wants to
“Add Image.” Therefore, Car” and “Rent Bike” are
“Transfer Funds” use case, choose a specific seat, but it is
composing a post includes the specialized versions of the
indicating the customer’s an optional step.
action of adding an image. general use case “Rent
involvement in the funds
Vehicle.”
transfer process.

9
 WRITTEN FORM USE CASE
Identify use case Main parts in template

Main steps writing a use Tips

case
HOW TO IDENTIFY USE
CASES?
There are two ways to identify Use Cases :
 Using the user goal technique
 ask users to describe their goals for using the new or updated
system. The analyst first identifies all the users and then conducts
a structured interview with each user. A user goal can be thought
of as a piece of work, or a task, that the user must complete.
 Using event-decomposition technique
 begins by identifying all the business events that will cause the
information system to respond, and each event leads to a use
case. Starting with business events helps the analyst define each
use case at the right level of detail.
MAIN PARTS OF A
TEMPLATE
 Preconditions
 Normal Course
 Alternative Courses
 Postconditions
 Exceptions
 Summary
MAIN PARTS OF A TEMPLATE
 1.Preconditions
 List any activities that must take place, or any conditions
that must be true, before the use case can be started.
Number each precondition. Examples:
 User’s identity has been authenticated.
 User’s computer has sufficient free memory available to
launch task.
MAIN PARTS OF A TEMPLATE
 2. Normal Course
MAIN PARTS OF A TEMPLATE
 3. Alternative Courses
MAIN PARTS OF A TEMPLATE
 4. Postconditions
 Describe the state of the system at the conclusion of the use case execution.
Number each postcondition. Examples:
 Document contains only valid SGML tags.
 Price of item in database has been updated with new value.
MAIN PARTS OF A TEMPLATE
 5. Exceptions
 Describe any anticipated error conditions that could occur during execution of the
use case, and define how the system is to respond to those conditions. Also,
describe how the system is to respond if the use case execution fails for some
unanticipated reason. Number each exception using the Use Case ID as a prefix,
followed by “EX” to indicate “Exception”. Example: X.Y.EX.1.
MAIN PARTS OF A TEMPLATE
 6. Summary
ALTERNATIVE FORM USE
CASE
 Major parts:
 1. Preconditions
 2. Normal course
 3. Postconditions
 4. Exceptions
STEPS FOR WRITING A USE
CASE
 Describe your system
 Start by describing your system, or the product or service you and
your team will build. Focus your description on what your system
does for users
 Identify the actors
 Actors generally refer to users and customers but can apply to any
outside force that engages with your system. Your actor needs well-
defined behaviors explaining how and why actors use your system.
 Define your actors’ goals
 Use cases highlight the outcome actors want from a system.
Remember to focus on your actors’ wants over the system’s
capabilities to understand why users come to your system.
 Create a scenario
 In a use case, scenarios are the sequence of actions customers take
when using a system and the flow of effects from that interaction.
Your basic flows cover scenarios where a system works as intended.
A user approaches the system, enters the right inputs, and your
system helps them reach their goals.
 Consider alternate flows
 After writing a successful scenario, write alternate flows that lead to
different outcomes. Typically, alternate flows involve the misuse of a
system that keeps actors from reaching their goals. However, you
can also note internal errors that cause a system to break down or
unintended ways systems can reach goals.
 3. One person,
1. Based on a 2. Complete or one place, one 4. Six to ten
goal. not complete. time, one steps.
event.

FINAL TIPS
• A use case
describes
• When an
actor has
• Try to write
use cases
• Try to keep the
main success
scenario of a use
how an actor performed that describe case between six
uses the the steps in a how one and ten steps.
system to use case, the actor Use cases should
achieve a goal should responds to make
goal. be either one event in requirements
easier to
100% one place at
comprehend.
complete or one time.
0% complete.
TAKE AWAY MESSAGE
 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.
QUESTION
S?
THANK YOU!