ZEIT2301Design of Information Systems

Functional Design: Use Cases

School of Engineering and Information TechnologyUNSW@ADFA

Dr Kathryn Merrick

Topic 04: Functional Design

Objectives Appreciate the role of Use Cases in Systems Development Be aware of the rules & style guidelines for Use Case diagrams. Be able to create functional models using Use Case diagrams. Design Use Case Descriptions

Reference: Dennis Ch 5

Use Cases

Model the systems interaction with the environment

Provide a high level view of the system from the user’s perspective.

Use cases are a non-technical record of what the customer (or user) expects the system to do.

Based on functional requirements.

Use Cases and Requirements

Use Cases assist the analyst to organize and model the functional requirements identified for the system.

Requirements obtained via interviews, questionnaires, observation, document analysis, JAD sessions or prototyping.

Use cases are not effective in capturing non-functional requirements They describe what a system accomplishes, not how Non-functional requirements (e.g. reliability, etc) are often documented

outside the use case.

A Use Case

Informally, a use case is a story of using a system to fulfill a (business) goal.

A Use Case represents a behaviour, so name should start with a verb

eg RentDVDs, Make Appointment, CheckPrice, ApproveLoan

Types of Use Cases

Early analysis stage concentrates on Use Cases: Overview and Essential

Guidelines for Good Use Cases

Identify major system functions Choose a good name (start with a verb) Illustrate a complete behaviour Limit each use case to one behaviour Represent the actor’s point of view

An Actor

An actor is an external entity that interacts with one or more Use Cases of the system

An actor is outside the system boundary

An actor is a role, not a specific user One actor may represent many users; a particular user may

perform more than one role.

An Actor

Most actors represent user roles e.g. StoreClerk, Customer, BankTeller

but occasionally actors can also be external systems. eg CreditAuthorizationSystem

An actor is connected to a Use Case Depicts a usage relationship Connection does not indicate data flow NB. There are no arrow heads on the connection line

Use Case Diagrams

A Use Case Diagram provides a high-level graphical view of all the Use Cases for the part of the system being modelled.

Illustrates, in a very simple way, the main functions of the system (or sub-system) and the users that will interact with it.

Can be used as a tool to communicate with users in the early phases of system development.

Use Case Diagram Syntax

Actor person or system that derives benefit from and is external to the

subject

Use Case Represents a major piece of system functionality

Association Relationship(between an actor and a use case)

Include Relationship

Extend Relationship

Generalization Relationship

<<extend>>

<<include>>

store clerk

system manager financial system

A simple Use Case DiagramNote the high level view of the system from the user’s perspective.

Diagram does not show the backend processes and databases that would connect these views.

rent DVDs

add new DVDs

increase price

store clerk

system manager financial system

A simple Use Case Diagram

Actors: store clerk (perhaps there are several clerks), system manager, financial system.

rent DVDs

add new DVDs

increase price

An <<include>> Relationship

Two Use Cases may be connected by an <<include>> relationship

Indicates a Use Case that is used (invoked) by another Use Case

Useful if the Use Case includes common functions also used by other Use cases.

The included Use Case is always performed as part of the original Use Case

But can also stand on its own

A Sales System with <<include>>relationships

<<include>> arrow points from the base use case to the included use case.

An <<extend>> Relationship

Two Use Cases may be connected by an <<extend>> relationship

Extends a Use Case by adding new behaviour or actions that are not always part of the Use Case

An extend use case cannot stand on its own

A Retail Sales System with <<extend>> and <<include>> relationships

<<extend>> arrow points from the extending use case to the extended use case.

Include vs. Extend

Use <<extend>> if you want to model an extension to, or a variation of, a use case.

Use <<include>> if you want to factor the common behaviour among two or more use cases into a single generalized use case

Generalization Relationships

Optionally, it may be useful to portray a generalization (of an actor or of a Use case).

New patient is a type of patient.

Use Case Diagram with Extend, Include and Generalization

Make appointment is a generalization of Make old patient appt and Make new patient appt.

store clerk

system manager financial system

Use Case Diagrams

In a Use case Diagram, the only connection between two Use Cases is via <<extend>>, <<include>> or generalization

rent DVDs

add new DVDs

increase price

print updated catalogue

X

Levels of Use Cases

A common challenge is identifying use cases at a useful goal level.

For example, how do we know which of these is at a useful level? Negotiate a Supplier Contract Rent DVDs Log In Start Up System

Material sourced from Craig Larman and Alistair Cockburn

Levels of Use Cases

One answer is that they are all use cases. Not helpful… We can end up with too many fine-grained use cases

management and complexity problems.

Or “fat” use cases which span an entire organization.

Guidelines for Use Case Levels

Cockburn supports the Elementary Business Process (EBP) guideline.

Focus on use cases at the level of EBPs. “A task performed by one person in one place at one time, in

response to a business event, which adds measurable business value and leaves the data in a consistent state.”

EBP for Use Case Levels

Naively, you can apply the “boss test” for an Elementary Business Process Boss: “What do you do all day?”

Me: “I logged in!”

Is Boss happy?

Guidelines: Size for Use Case Levels

An EBP-level use case usually is composed of several steps, not just one or two.

Think in terms of user-level goals. Stakeholders usually relate to requirements presented in the

form of goals.

Use Case Levels: Applying the Guidelines

Applying the EBP and size guidelines, which would you choose as a use case?

Negotiate a Supplier Contract Rent DVDs Log In Start Up System

Use Case Levels: Applying the Guidelines

Applying the EBP and size guidelines: Negotiate a Supplier Contract Rent DVDs Log In Start Up System

The others can also be modelled as Use Cases. But, prefer a focus on the user-goal level.

Definition: Essential & Concrete (Real) Use Cases

“Keep the User Interface out” Essential use cases defer the details of the UI, and

focus on the intentions of the actors. Essential: Clerk enters Customer ID

Good Concrete: Clerk takes Customer ID card and reads the

bar code with laser scanner. Not recommended at this stage. Anticipates physical design

decisions about how the process will be done

Use Case Descriptions

Individual Use Cases are described in words: Use Case Description.

Use Cases are text, not diagrams Despite the emphasis often given to the diagrams. A Use Case Diagram just helps in identifying Use Cases by name

and creating a context for the Use Case

Use-Case Descriptions

Describe basic functions of the Use Case What the user can do How the system responds

Describes one and only one function, but may have multiple paths.

Content is developed in collaboration with users.

There is no formal specification for a Use Case Description.

Use-Case Descriptions

Each Use Case has at least one sequence (or flow) that a user follows when interacting with the system eg the “normal” process for withdrawing money from an

ATM

The Use Case may have alternative paths that illustrate alternative actions Typically to cater for exceptions eg the user enters an

incorrect PIN; the user has insufficient funds.

Each path through the Use Case is known as a scenario

Sample Elements of a Use-Case Description

Use Case Name: ID: Importance Level:

Primary Actor: Use Case Type:

Stakeholders and Interests:

Brief Description:

Trigger:

Relationships: (Association, Include, Extend, Generalization)

Preconditions:

Normal Flow of Events:

Subflows:

Alternate/Exceptional Flows:

Elements of a Use Case Description

Title descriptive name, matches name in use case diagram

ID indentifying number

Importance level Low, High

Primary actor usually a user role, the trigger for the use case

Stakeholders any group or individual with an interest in the function of the use case

Brief description

Elements of a Use Case Description

Type Overview vs Detail

Overview: a high level view of requirements as agreed between the analyst and users

Detail: documents as much relevant information as possible Essential vs Real

Essential: only the minimum needed to understand the required functionality

Real: describes specific steps in detail In early analysis, the type is typically overview and essential

Elements of a Use Case Description

Precondition – conditions that must be satisfied in order to execute the use case;

Where we are up to when the Use Case commences? eg For a Use Case “Purchase Items” the precondition might be:

Customer has searched the web site and selected at least one item to purchase

Note: preconditions not shown in textbook’s template (Fig 5-5) for Use case descriptions

Elements of a Use Case Description

Trigger Each Use case usually has a trigger – an event or action

that initiates the use case External trigger

eg a customer placing an order Temporal trigger

eg library book overdue

Use Case Elements: Relationships

Association Actors that are associated with this use case

Extend Any uses cases which are extensions of this use case

Include Any use cases included with this one

Generalization Whether this is in a hierarchy of use cases

Use Case Elements: Flows

Normal Flows Sequence of steps that are normally executed in this particular

use case Simple, clear steps Identify who initiates the step

If flow “includes” other use cases, then specify that use case name eg

Step 2: ….. Step 3: perform “Check Outstanding Fines”

Use Case Elements: Flows

Sub-Flows The normal flow of events decomposed, if necessary, to keep the

normal flow of events as simple as possible Alternate or Exceptional Flows

Flows that do happen but are not considered to be the norm Some of these exceptional flow may cause the use case to end;

others may be recoverable

Larman example: Place an Order

UC 4: “Place an order”1. Clerk identifies the customer, each item and quantity

2. System checks credit

3. System accepts and queues the order

Extensions:2a. Low credit: Customer is ‘Preferred’...

2b. Low credit & not Preferred customer: ...

3a. Low on stock: Customer accepts reduced...

Use Case Writing Guidelines

1. Write in the form of subject-verb-direct object

2. Make sure it is clear who the initiator of the step is

3. Write from independent observer’s perspective

4. Write at about the same level of abstraction

5. Ensure the use case has a sensible set of steps

6. Apply the KISS principle liberally.

7. Write repeating instructions after the set of steps to be repeated

Summary

Examining the goals a system supports makes for good functional requirements a user can understand

Use Case Diagrams present a graphical overview of the main functionality of a system.

Use Case Diagrams present a graphical overview of the main functionality of a system represented by the use cases shown.

A description is developed for each use case shown on the use case diagram.

Use Case Descriptions detail the interactions of a user with the system when undertaking a particular function.