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.