Software Engineering

Lecture 5.xx
Understanding
USE CASE

Software Engineering: A Practitioner’s Approach, 7/e Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman
Software Engineering 9/e By Ian Sommerville
 Use Case Deliverables

 Use case diagrams

 Writtendescriptions of use-case
contents

Topic 4 2
© Prentice Hall, 2007
Topic 4 3
© Prentice Hall, 2007
 UML Use Case Diagram Symbols

 Use Case
 Actor
 Boundary
 Connection
<<include>>  Include relationship
 Extend relationship <<extend>>

Topic 4 4
© Prentice Hall, 2007
 What Is a Use Case?
 A depiction of a system’s behavior or functionality under
various conditions as the system responds to requests from
users

 Full functioning for a specific business purpose

Topic 4 5
© Prentice Hall, 2007
 What Is an Actor?
• An external entity that interacts with the system

• Most actors represent user roles, but actors can also be external
systems.

• An actor is a role, not a specific user; one user may play many roles,
and an actor may represent many users.

Topic 4 6
© Prentice Hall, 2007
 What Is a Boundary?
 The dividing line between the system and its environment

 - Use cases are within the boundary.

 - Actors are outside of the boundary.

Topic 4 7
© Prentice Hall, 2007
 What Is a Connection?
 An association between an actor and a use case

 Depicts a usage relationship

 Connection does not indicate data flow

Topic 4 8
© Prentice Hall, 2007
 What Is an <<include>> Relationship?
 A connection between two use cases

 Indicates a use case that is used (invoked) by another use

case

 Links to general purpose functions, used by many other use

cases

Topic 4 9
© Prentice Hall, 2007
Topic 4 10
© Prentice Hall, 2007
 What Is an <<extend>> Relationship?
 A connection between two use cases

 Extends a use case by adding new behavior or actions

 Specialized use case extends the general use case

Topic 4 11
© Prentice Hall, 2007
 What Is a Stereotype
• A construct that extends the UML vocabulary

• Adds new meanings to existing entities

• Depicted with << >> delimiters

• <<extend>> and <<include>> are stereotypes

Topic 4 12
© Prentice Hall, 2007
 Use Case Diagram in MS Visio

Topic 4 13
© Prentice Hall, 2007
Topic 4 14
© Prentice Hall, 2007
 Include vs. Extend
 Use <<extend>> if you want to model an extension to, or a
variation of, a complete use case that exists in its own right

 Use <<include>> if you want to factor the common

behavior among two or more use cases into a single
generalized use case

Topic 4 15
© Prentice Hall, 2007
 Actors can be
grouped in
generalization
categories.

Topic 4 16
© Prentice Hall, 2007
 Written Use Cases
 Document containing detailed specifications for a use case

 Contents can be written as simple text or in a specified

format

Topic 4 17
© Prentice Hall, 2007
Topic 4 18
© Prentice Hall, 2007
 Level of Use Case
 Refers to degree of detail in the use case
description

 Five suggested levels (Cockburn)

1. White – as seen from clouds summary
2. Kite – “birds-eye view”
3. Blue – sea-level view
4. Fish – below sea-level
5. Black – bottom of the sea detail
Topic 4 19
© Prentice Hall, 2007
 summary

detail

Topic 4 20
© Prentice Hall, 2007
 Sample Format for Written Use Case
 Title – descriptive name, matches name in use case diagram

 Primary actor – usually a user role

 Stakeholders – any group or individual with an interest in

the function of the use case

Topic 4 21
© Prentice Hall, 2007
 Sample Format for Written Use
Case (Continued)
 Precondition – conditions that must be satisfied
in order to execute the use case

 Minimal guarantee – outputs that can be

expected if the service attempt failed

 Success guarantee – outputs that can be

expected if the service succeeds
Topic 4 22
© Prentice Hall, 2007
 Sample Format for Written Use
Case (Continued)
 Trigger – an event or action that initiates the
use case

 Main success scenario – description of

sequence of interactions between actor and use
case during the use case execution

 Extensions – detailed description of how errors

are dealt with
Topic 4 23
© Prentice Hall, 2007
 A sample
written use
case at kite
level

Topic 4 24
© Prentice Hall, 2007
 Use case at
sea level

Corresponds
with Step 1
of kite-level
use case

Topic 4 25
© Prentice Hall, 2007
 Use case at
sea level

Corresponds
with Step 2
of kite-level
use case

Topic 4 26
© Prentice Hall, 2007
 Guidelines for Good Use Cases
 Choose a good name
 Illustrate a complete behavior
 Identify a completable behavior
 Provide “inverse” use cases
 Limit each use case to one behavior
 Represent the actor’s point of view

Topic 4 27
© Prentice Hall, 2007
 Recap
 After studying this chapter we learned
to:
– Understand how to structure
requirements with use case diagrams.
– Explain the basics of use case
construction using UML standards.
– Construct use case diagrams.
– Write text-based use cases.

Topic 4 28
© Prentice Hall, 2007
Objective:
To learn and draw use case diagrams for any software .
The purpose of a use case diagram in UML is to demonstrate the different ways that
a user might interact with a system.
◦ Scenarios in which your system or application interacts with people, organisations, or external systems
◦ Goals that your system or application helps those entities (known as actors) achieve
◦ The scope of your system
● Don't expect it to model the order in which steps are performed.
● Representing the goals of system-user interactions
● Defining and organising functional requirements in a system
● Specifying the context and requirements of a system
● Modelling the basic flow of events in a use case
An actor in a use case diagram is any entity that performs a role
in one given system. This could be a person, organization,` or
an external system and is usually drawn like a skeleton shown
here.
Component:
Actors:
o The users that interact with a system. An actor can be a person, an organisation, or an outside system that
interacts with your application or system. They must be external objects that produce or consume data.

System:
o A specific sequence of actions and interactions between actors and the system.
A system may also be referred to as a scenario.

Goals:
o The end result of most use cases. A successful diagram should describe the activities and variants used to
reach the goal.
Actor
•Someone interacts with use case (system function).
•Named by noun.
•Actor plays a role in the business
•Similar to the concept of user, but a user can play different roles
•For example:
• A prof. can be instructor and also researcher
• plays 2 roles with two systems
•Actor triggers use case(s).
•Actor has a responsibility toward the system (inputs), and Actor has
expectations from the system (outputs)

•Actor in a use case diagram is any entity that performs a role in one given
system. This could be a person, organization or an external system and
usually drawn like skeleton shown below.
 What are the Use cases:
Introduction:
•Use cases are a fundamental concept in software engineering.
•They provide a way to capture functional requirements and depict how users interact with a system.
•Understanding use cases is essential for effective software development and requirement analysis.
1. What are Use Cases?
•Use cases describe interactions between users and a system to achieve specific goals.
•They focus on the functional requirements of a system from the user's perspective.
•Use cases typically consist of a series of steps or actions performed by users or system components.

Introduction:
A Use Case Diagram is a vital tool in system design, providing a visual representation of how users interact with a system. It
serves as a blueprint for understanding the functional requirements of a system from a user’s perspective. Use Case Diagrams aid
in communication between stakeholders and guide the development process.
1. What is a Use Case Diagram?
A Use Case Diagram is a type of Unified Modeling Language (UML) diagram. It serves as a graphical representation of the
interaction between actors (users or external systems) and a system to accomplish specific goals.
 Types of Components of a Use Case:
•Actor: Represents a user or any external system interacting with the software.
• Example: In an online shopping system, the "Customer" is an actor who interacts with the system.
•Use Case Name: Describes the goal or functionality being performed.
• Example: A use case name could be "Place Order" or "Add Item to Cart."
•Description: Provides a brief overview of the use case.
• Example: Description of the "Place Order" use case includes details about selecting items, providing shipping
information, etc.
•Preconditions: Conditions that must be true before the use case can start.
• Example: Preconditions for the "Place Order" use case could be that the customer must be logged in.
•Main Flow: Sequence of steps for the successful completion of the use case.
• Example: Main flow of the "Place Order" use case includes selecting items, providing shipping details, etc.
•Alternate Flows: Optional sequences of steps for different scenarios or exceptions.
• Example: An alternate flow for "Place Order" could be if an item is out of stock.
•Postconditions: Conditions that must be true after the use case completes successfully.
• Example: Postcondition for "Place Order" could be that the customer receives an order confirmation email.
Benefits of Use Cases:
•Clear Communication:
• Use cases provide a clear and concise way to communicate requirements between stakeholders.
• Example: Presenting use cases in a project meeting helps stakeholders understand expected system
behavior effectively.
•Visualization:
• They help stakeholders visualize system interactions and understand user needs.
• Example: Diagrams representing use case flows aid in comprehending the sequence of steps
involved.
•Requirement Analysis:
• Use cases aid in identifying and prioritizing functional requirements.
• Example: Examining steps within a use case helps pinpoint specific functionalities needed to
support user interactions.
•Validation:
• Use cases serve as a basis for validating system functionality against user expectations.
• Example: During user acceptance testing, stakeholders reference use cases to ensure the system
behaves as intended.
 Examples:
Example Use Case: User Registration
•Actor: New User
•Description: This use case describes the process of a new user registering on a website.
•Preconditions: The user must have access to the registration page.
•Main Flow:
• User navigates to the registration page.
• User enters personal information (e.g., name, email, password).
• User submits the registration form.
• System validates the entered information.
• System creates a new user account.
•Alternate Flows:
• If the email is already registered, display an error message and return to step 2.
• If the password is too weak, prompt the user to choose a stronger password and return to step 2.
•Postconditions: User receives a confirmation email and gains access to the website.
Example Use Case: Online Shopping
•Actor: Customer
•Description: This use case describes the process of a customer purchasing an item online.
•Preconditions: The customer must have access to the online shopping website.
•Main Flow:
• Customer browses products and selects items to purchase.
• Customer adds selected items to the shopping cart.
• Customer proceeds to checkout.
• Customer enters shipping and billing information.
• Customer selects a payment method and completes the transaction.
•Alternate Flows:
• If an item is out of stock, notify the customer and allow them to remove it from the cart.
• If the payment fails, prompt the customer to try a different payment method.
•Postconditions: Customer receives an order confirmation and the purchased items are reserved for shipping .
Examples:
Best Practices for Creating Use Cases:
•Keep it Simple: Use concise language and avoid unnecessary
details.
•Focus on Goals: Describe what users want to accomplish
rather than technical implementation details.
•Be Iterative: Refine and update use cases throughout the
development process as requirements evolve.
•Involve Stakeholders: Collaborate with stakeholders to ensure
use cases accurately reflect user needs.
Conclusion:
•Use cases are invaluable tools in software engineering for
capturing and communicating functional requirements.
•By understanding and creating use cases effectively, software
teams can build systems that meet user expectations and deliver
value.
Types of Requirements:
Types of Requirements:
Types of Requirements:
Types of Requirements:
Types of Requirements:
Types of Requirements:
Types of Requirements:
 Thanks for watching!
If you enjoyed the
content, consider
subscribing, hitting
the like button,
leaving a comment,
and sharing it with
others.

Like | Share | Subscribe