is3320 developing and using management information systems lecture 9: use cases and scenarios rob...
TRANSCRIPT
IS3320 Developing and Using Management Information SystemsLecture 9: Use Cases and Scenarios
Rob Gleasure
IS3320
Today’s lecture What is a Use Case? Use Case Diagrams Exercise
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.
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
The Use Case Design process
The process of constructing a use case model is basically as follows
1. Identify actors and use cases
2. Construct a use case model
3. Sequence specific uses identified
4. Identify use case dependencies
5. … more stuff
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’)
Identifying use cases
For each actor What tasks does that actor want the system to perform? What information must that actor provide to the system? What information must that actor receive from the system? Are there events that actor must tell system about? Are there events the system must tell that actor about? Does that actor help initialize or shut down the system?
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?
We may then consider drawing a use case diagram
Use Case Diagrams
Driver
Enters carpark
Actor represented by a stickperson
Interaction represented by an oval shape
Associates actor with interaction
Use Case Diagrams
Driver
Exit carpark
Box around use cases to signify system boundary
Enter carpark
Opening hours query
Security staff
CARPARK
Includes and Extends
IncludesIf 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’
ExtendsStore the basic behaviour in one use-case and let specific exceptional cases add additional behaviour as necessary
e.g. ‘user account overdue’
Use Case Diagrams
Driver
Enters carpark
Opening hours query
Checks account
Security staff
«includes»
Accountrejected
«extends»
Account system
Exitscarpark «includes»
Textual Use Case Specification
From A. Cockburn, “Basic Use Case Template”
Number
Name
Summary
Priority
Preconditions
Postconditions
Primary Actor(s)
Secondary Actor(s)
Trigger
Main Scenario Step Action
Extensions Step Branching Action
Open issues
Textual Use Case SpecificationNumber 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
Textual Use Case SpecificationNumber 1
Trigger Driver has chosen to enter carpark
Main Scenario Step Action
1 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 Step Branching Action
3a System determines account rejected
3b System asks driver to inquire with security
Open issues 1 What if another driver is blocking the driver in when their card is rejected?
Exercise
In groups of 3 Create a use case diagram for Blackboard Create a textual use case specification for a student searching
for class notes
Want to read more?
Cockburn, A., Writing Effective Use Cases. New York: 2001, Addison-Wesley.