Use case modeling involves describing how users will interact with a system to achieve goals. A use case represents a dialog between a user and the system, specifying what information must pass between them without detailing the system's internal workings. Each use case should have a name that includes a verb describing the user's goal. Actors represent people or systems that interact with the system-to-be to accomplish responsibilities. Sequence diagrams visually depict the information exchanged between actors and the system in specific use case scenarios.

1. Use Case Modeling
MD. SHAFIUZZAMAN

2. What is an use case?
description of how a user will use the planned system to accomplish business goals
represents a dialog between the user and the system with the aim of helping the user achieve a
business goal
in each dialog, the user initiates actions and the system responds with reactions
specifies what information must pass the boundary (without considering what happens inside
the system)

3. Naming Convention
use cases represent recipes for user achieving goals, each use-case name must include a verb
capturing the goal achievement, for example, Withdraw cash

4. Actors and Their Goals
Actor: any entity (human, physical object, or another system) external to the system-to-be that
interacts with the system-to-be
Actors have their responsibilities and seek the system’s assistance in managing those
responsibilities
To carry out its responsibilities, an actor sets goals, which are time and context-dependent
For example, a resident leaving the apartment for work has a goal of locking the door; when
coming back, the resident’s goal is to open the door and enter the apartment

5. Actions
To achieve its goals, an actor performs some actions
An action is the triggering of an interaction with the system-to-be

7. Case Study
FROM HOME ACCESS CONTROL TO ADAPTIVE HOMES

8. The Customer’s Statement
The system offers house access control.
The system could be required to authenticate (“Are you who you claim to be?”) and validate
(“Are you supposed to be entering this building?”) people attempting to enter a building
Along with controlling the locks, the system may also control other household devices, such as
the lighting, air conditioning, heating, alarms, etc.

10. Actors
Tenant is the home occupant
Landlord is the property owner or manager
Device is a physical device to be controlled by the system-to-be, such as lock-mechanism and
light-switch
Other potential actors: Maintenance, Police, etc.

11. How to decide an actor?
Does the system provide different service(s) to the new actor?
an actor is associated with a role rather than with a person

12. Classification of actors
Initiating actor (also called primary actor or simply user)
Participating actor (also called secondary actor)
◦ Supporting actor
◦ Offstage actor

13. Actor generalization

15. REQ7

16. Types of Requirements
 Functionality
 functional requirements
 security: data integrity and authorized access to information
 Usability: ease of use, esthetics, consistency, and documentation
 Reliability: expected frequency of system failure under certain operating conditions,
recoverability, predictability, accuracy, and mean time to failure
 Performance: computing speed, efficiency, resource consumption, throughput, and
response time
 Supportability: testability, adaptability, maintainability, compatibility, configurability,
installability, scalability, and localizability

17. More on Requirements
All requirements must be written so that they are testable
o Bad Example: system should be “easy to use”
 Prioritizing requirements: cost-value approach
1. Essential: have to be realized to make the system acceptable to the customer.
2. Desirable: highly desirable, but not mandatory requirements
3. Optional: might be realized if time and resources permit
4. Future: will not be realized in the current version of the system-to-be, but should be
recorded for consideration in future versions

18. Assignment
Consider the following nonfunctional requirements and determine which of them can be verified
and which cannot. Write acceptance tests for each requirement or explain why it is not testable.
(a) “The user interface must be user-friendly and easy to use.”
(b) “The number of mouse clicks the user needs to perform when navigating to any window
of the system’s user interface must be less than 10.”
(c) “The user interface of the new system must be simple enough so that any user can use it
with a minimum training.”
(d) “The maximum latency from the moment the user clicks a hyperlink in a web page until
the rendering of the new web page starts is 1 second over a broadband connection.”
(e) “In case of failure, the system must be easy to recover and must suffer minimum loss of
important data.”

20. «extend» – optional extensions of the main case
«include» – required subtasks of the main case
«include» – required subtasks of the main case

22. Is Login a Use Case?

23. System Boundary and Subsystems

24. Use Case Specification
REPRESENTS A USE CASE OF THE SYSTEM AS A SEQUENCE OF
INTERACTIONS BETWEEN EXTERNAL ENTITIES (ACTORS) AND THE
SYSTEM-TO-BE

25. Traceability Matrix
Priority weight (PW)
Use cases specify what information must pass the boundary of a system when a user or another system
interacts with it

29. User acceptance test case

33. Lab Assignment
Consider an online auction site, such as eBay.com, with selling, bidding, and buying services.
Assume that you are a buyer, you have placed a bid for an item, and you just received a
notification that the bidding process is closed and you won it. Write a single use case that
represents the subsequent process of purchasing the item with a credit card. Assume the
business model where the funds are immediately transferred to the seller’s account, without
waiting for the buyer to confirm the receipt of the goods. Also, only the seller is charged selling
fees. Start from the point where you are already logged in the system and consider only what
happens during a single sitting at the computer terminal. (Unless otherwise specified, use cases
are normally considered only for the activities that span a single sitting.) List also some
alternate scenarios.

34. Lab Assignment
Suppose that by observation you determine that the generic Buyer
and Seller roles can be further differentiated into more specialized
roles:
Occasional Buyer, Frequent Buyer, and Collector
 Small Seller, Frequent Seller, and Corporate Seller
Identify the use cases for both situations: generic Buyers and
Sellers vs. differentiated Buyers and Sellers. Discuss the similarities
and differences. Draw the use case diagrams for both situations.

35. Sequence Diagrams
 visual form of a usage scenario that an actor experiences while trying to obtain
a service from the system
 summarize textual description of the use case scenarios
 a use case may have different scenarios, the main success scenario and the
alternate ones. A sequence diagram may represent one of those scenarios in
entirety, or a subpart of a scenario.

36. Sequence Diagrams
 key purpose of sequence diagrams is to represent what information must pass
the system boundary and in what sequence
 a system sequence diagram can contain only a single box, named System
 all other entities must be actors
 at this stage of the development cycle, the system is still considered atomic
and must not be decomposed into its constituent parts.

37. Unlock use case: main success
scenario

38. Unlock use case: burglary attempt
scenario