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

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 Identify actors and use cases Construct a use case model Sequence specific uses identified Identify use case dependencies … 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 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?

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?

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

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

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’

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

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”

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

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?

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

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