IS3320 Developing and Using Management Information Systems Lecture 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 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 Driver Enters carpark Opening hours query Checks account Security staff «includes» Account rejected «extends» Account system Exits carpark «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 ScenarioStepAction ExtensionsStepBranching Action Open issues

Textual Use Case Specification Number1: Enters Carpark NameSwipes In SummaryDriver swipes card to enter carpark Priority5 PreconditionsDriver has registered for use of car park PostconditionsDriver has entered carpark Primary Actor(s)Driver Secondary Actor(s)Accounts system

Textual Use Case Specification Number1 TriggerDriver has chosen to enter carpark Main ScenarioStepAction 1Driver swipes card 2System checks account 3System raises barrier 4System asks driver to enter 5Driver enters carpark 6System updates records 7System lowers barrier ExtensionsStepBranching Action 3aSystem determines account rejected 3bSystem asks driver to inquire with security Open issues1What 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.