1. Rob Gleasure R.Gleasure@ucc.ie www.robgleasure.com
IS3320 Developing and Using Management Information Systems Lecture 8: Use Cases and Scenarios
Rob Gleasure

2. IS3320
Today’s lecture
What is a Use Case?
Use Case Diagrams
Exercise

3. What is a Use Case?
A use-case describes the contact between some stakeholders (actors) and the system
This actor can be a person, or another system, and are sometimes conceptualised in two categories
Primary actors – those actors who initiate the interaction to achieve some goal
Secondary actors – other actors involved in the interaction sequence making up the system’s response
When the system responds, different sequences of behaviors, or scenarios, can unfold. The use case gathers these scenarios together in one view.

4. Why would we do this? Ability to stay user-centred in our design
Means we can capture functional requirements from the users' perspective
Ability to communicate
Means we can involve users in the requirements-gathering process and share one view of a system’s functionalities
Ability to abstract
Means we can identify major classes (sets) of usage scenarios and their relationships
Ability to tie testing back to key requirements
Means that later we can test the system according to the scenarios we already identified as of most importance

5. The Use Case Design process
The process of constructing a use case model is basically as follows
Identify actors and use cases
Construct a use case model
Sequence specific uses identified
Identify use case dependencies
… more stuff

6. Identifying actors
Who will be interacting with the system generally? What about secondary tasks of maintenance and administration? Will the system interact with other systems?
Clear and differentiated role names, typically NOT person names (e.g. ‘stock manager’, not ‘Mary’)

7. Identifying use cases Some prompting questions for each actor include:
What tasks does that actor want the system to help them perform?
What information must that actor provide to the system?
What information must that actor receive from the system?
Are there events about which that actor must tell system?
Are there events about which the system must tell that actor?
Does that actor help initialize or shut down the system?

8. An example
Imagine the UCC main car park entered at the back of the university
A Driver has to be registered on the system with a swipe card, which they then use to swipe in and out. There is also a security hut where issues with swipe cards can be resolved and unusual circumstances handled
What actors do we have?
What use cases are associated with each actor?

9. Use Case Diagrams We may then consider drawing a use case diagram
Interaction represented by an oval shape
Actor represented by a stickperson
Enter carpark
Associates actor with interaction
Driver

10. Use Case Diagrams CARPARK Enter carpark Exit carpark Driver
Box around use cases to signify system boundary
Enter carpark
Exit
carpark
Driver
Security staff
Query opening hours

11. Includes and Extends Includes
If you have a piece of behaviour that is similar across many use cases, you should create this as a separate use-case and let the other ones “include” it
e.g. ‘check if user logged in’
Extends
Store the basic behaviour in one use-case and let specific exceptional cases add additional behaviour as necessary
e.g. ‘user account overdue’

12. Use Case Diagrams Query opening Security staff hours Enter carpark
Account system
«includes»
Driver
Check
account
Exit
carpark
«extends»
«includes»
Reject
account

13. Textual Use Case Specification
Number
Name
Summary
Priority
Preconditions
Postconditions
Primary Actor(s)
Secondary Actor(s)
Trigger
Main Scenario
Step
Action
Extensions
Branching Action
Open issues
From A. Cockburn, “Basic Use Case Template”

14. Textual Use Case Specification
Number
1: Enters Carpark
Name
Swipes In
Summary
Driver swipes card to enter carpark
Priority 5
Preconditions
Driver has registered for use of car park
Postconditions
Driver has entered carpark
Primary Actor(s)
Driver
Secondary Actor(s)
Accounts system

15. Textual Use Case Specification
Number 1
Trigger
Driver has chosen to enter carpark
Main Scenario
Step
Action
Driver swipes card 2
System checks account 3
System raises barrier 4
System asks driver to enter 5
Driver enters carpark 6
System updates records 7
System lowers barrier
Extensions
Branching Action 3a
System determines account rejected 3b
System asks driver to inquire with security
Open issues
What if another driver is blocking the driver in when their card is rejected?

16. Exercise In groups of 2-3 Create a use case diagram for Blackboard
Create a textual use case specification for a student searching for class notes

17. Want to read more?
Cockburn, A., Writing Effective Use Cases. New York: 2001, Addison-Wesley.