1. Requirements Inc BA Training
Module 2.1
Use Case Modeling
v9.01 ©2009

2. In this session..
We will
Understand about modeling functional requirements using use cases
Study the elements of a use case diagram – Semantics of entities and relationships
<<Include>> and <<extend>> constructs
Introduce use case text format, types of use cases

3. What is a use case?
A use case is a particular example (a case) of how a system is used, literally a “case of system use”.
A use case describes a sequence of interactions between an user and a system to achieve a significant goal, prompted by some triggering event.
is a unit of business functionality
represented as horizontal ellipse
Online Banking System - Example use cases [Verb + Object]
View Statement, Check Balance, etc.
Formal Definition [Alistair Cockburn]
Use Cases record a contract between system stakeholders about the behaviors of the system under discussion under various circumstances, organized by goals of selected actors”.
Formal Definition [OMG]
“The Use Case construct is used to define the behavior of a system or other semantic entity without revealing the entity’s internal structure. Each U`se Case specifies a sequence of actions, including variants, that the entity can perform, interacting with actors of the entity”.

4. Use Case Models and Use Cases
pictorially depicts the functionalities of the system, the people and external systems (actors) interacting with the system
drawn at the system level representing multiple use cases, use case – use case relationship, actor – use case relationship
visualizes functional requirements
Use case (textual)
textually describes the interaction between the system and an actor
is a sequence of related transactions performed by an actor and the system in a dialogue
documents functional requirements

5. Use Case Model Use case model
Is the starting point when designing a new system using the UML
Provides a high level overview of a system
Tells us what the system will do when interacting with actors
Depicts the functionalities of the system as users perceive it
‘Sets context’ easily for conversations about requirements and system development
Works well with Objects

6. Use Case Model Is focal to / binds all activities within a project
A set of Use Cases can be developed to tell “stories” of how a system will be used, from the differing points of view of each of the actors.
Use cases must be traceable
to design and testing
Use cases model will
evolve!
A Use Case describes a sequence of actions a system performs that yield an observable result of value to a particular actor
An actor is someone or something outside of the system that interacts with the system

7. What is an actor?
An actor is a person, organization, service or another system that plays a role in one or more interactions with your system.
is external to the system, but is not a part of the system
represented as a stick figure
Time is an actor!
Primary Actors
Secondary Actors
Initiate use cases
Provide inputs
Act as an on-demand service
Receive messages
E.g., Customer making payment
E.g., Equifax used in a credit card company’s system to gather credit score - Customer receiving a funds deficit alert
End User Actors
Organizational Actors
Customer / client users
Users within the organization
E.g., Credit card customers in a credit card system
E.g., Customer support reps within a credit card company, managers viewing monthly reports

8. What is an actor? Examine actors’ needs to determine use cases
Actors should reflect the entire system lifecycle including: set up users, support users, client users, etc.
“What’s my goal?”

9. Use Case Model Notation
Actor
An Actor is a user of the system / someone or something that interacts with the system.
The role of the user is written beneath the icon.
Use Case
A Use Case is functionality provided by the system (e.g., Register Car, Delete User).
System boundary
Marks the bounds of the system. Distinguish functionalities “in scope” and “out of scope”.
Package
Logical folders to group related use cases together. Typically used then the use case diagram is too large.
May used to represent different releases.
Directed Association
Associations are used to interactions.
Directed associations are depicted by an arrow with the direction originating from the trigger.
Often misread as information flow, hence avoided.

10. Use Case Model Notation
Association
Associations are used to indicate interactions.
(Undirected) associations are depicted by a plain line, does not indicate trigger.
Primary actors on the left and secondary actors on the right if using plain association
Generaliza-tion
Inheritance relationship (generalization in UML) is indicated by a block arrow pointing to the parent.
<<Include>> stereotype
A base use case executes an <<include>> use case as part of its flow to complete its business functionality.
E.g., Transfer Balance
<<includes>> Check Balance
<<Extend>> stereotype
A base use case may be extended by an <<extend>> use case based on a certain condition.
E.g., Buy extended warranty
<<Extends>> Buy laptop

11. Examples

12. Examples System Student Maintain schedule Billing System
Professor
Registrar
Billing System
Student
Maintain schedule
Maintain curriculum
Request course roster

13. Examples

14. Examples

15. Use Case Diagram

16. Use Case Scenarios Use cases are scenario or flow based – ‘what if’
Success or Main or Primary scenarios – all goes well, happy path
Alternative success scenarios – not typical but leading to success
Failure or Exception scenarios
What are the possible scenarios for a login use case?

17. Use Case Representation
Basic Use Case representation
Extending Use Case representations
Purchase
Book
Purchase
Book
Add one day
shipping
<<extend>>

18. Use Case – Actor interaction
Ecommerce System
Reception is
usually
on the right
Initiation is
usually
on the left
View
catalog
Actor with
custom icon
Add to
Cart
Purchase
Book
<<extend>>
Order
Management
System
Customer
Add 1 day
shipping

19. Actor Generalization DB Admin Backup Admin Deployment Admin
Op. Data System
Replicate DB
DB Admin
Backup
User Data
Startup
Backup Admin
Shutdown
Deploy
Web App
Deployment
Admin

20. Actor Generalization Sys Admin DB Admin Backup Admin Deployment Admin
Op. Data System
Startup
Sys Admin
Shutdown
DB Admin
Replicate DB
Backup
User Data
Backup Admin
Deploy
Web App
Deployment
Admin

21. Use Case Generalization
Perform search
Search by author
Search by ISBN
Search by title

22. Preconditions
Preconditions are statements / use cases that must be true before another use case is executed
E.g.,
“Register for an account” is a precondition to “Login”
“Login” is a precondition to “Pay fees”

23. <<Include>> ConstructA
Base use case B
Included use case
<<include>>
Signifies that the base use case calls the included use case (also <<uses>> or <<includes>>)
Eg., A includes B
A is the base (calling) use case, B is the included (called) use case
During A’s execution, B will be called one or more times and then control comes back to A
A cannot produce success outcome without running B
Nothing precludes B from being executed directly by the user/another use case without <<include>> relationship
Mimics subroutines to reuse a frequently accessed functionality (called by different use cases)

24. <<Include>> Construct
When to <<include>>
Reusability:
To pull out use cases that may be called (included) by many use cases (behavior that is common to one or more use cases)
Modularity:
To keep different business goals separate 19

25. Is this correct?

26. <<Extend>> ConstructA
Base use case B
Extending use case
<<extend>>
Signifies that the extending use case extends the functionality of the base use case
Eg., B extends A
A is the base use case, B extends the functionality of A
B may or may not be executed (when a certain condition is satisfied during A’s execution)
A can run (produce success outcome) without running B
Nothing precludes B from being executed directly by the user/another use case without <<extend>> relationship
Usually used to keep special / specific business cases separate from a basic flow

27. <<Extend>> Construct
When to <<extend>>
Pull out optional steps out of a use case so the use case outcomes can be distinct and unconditional
Apply discount code
Purchase item
Add maintenance
<<extend>>

28. Is this correct? Pay by check <<extend>> Pay for dinner
Pay by credit card
<<extend>>
Pay by cash

29. Include and Extend - Usage

30. <<Include>> and <<Extend>>
What’s missing in this diagram?
Buy lunch
<<include>>
Make payment
<<include>>
Buy theme park ticket
Theme park
tourist
<<extend>>
Buy speedpass ticket

31. Use Case Guidelines
All use cases must provide significant value to one or more actors (exception – included and extension use cases)
Use cases must be meaningful independently. E.g., Enter PIN may not be executed by itself. Doesn’t satisfy a goal either (exception – included and extension use cases)
Use cases must be completed in one sitting
Separating use cases
Flow occurs in more than one use case? Consider include
Flow occurs optionally? Consider extend
Across RUP
Same use case may be iteratively built
New use cases may be part of a new iteration

32. Use Case Format Title – must start with a verb – Make payment
Description and purpose
Diagrams and documents
Pre-conditions
Post-conditions
Included / extending use cases
Glossary
Primary Actors
Secondary Actors
Main flow
Alternate flow(s)
Exception flow(s)

33. Use Case Types Business Use Case (BUC) Application Use Case (AUC)
Supports business policy and operations, independent of implementation
Generic, rule book
Transfer funds – process is independent of mode of operation
Application Use Case (AUC)
Supports BUC but dependent on the implementation of an application, eg., online system
Specific, triggered by a user and documents interaction
Transfer funds – process is specific to the mode (online)
System Use Case (SUC)
Similar to AUC but no user interaction
Triggered by AUC / system
Run Payroll

34. Review Course Website
For additional reference materials, instructions for the next session, assignments, tests, review the course website at

35. `
Srinivas,
RequirementsInc.com