Use Cases

Introduction
9 Means of capturing system functionality as seen by users Æ user-focused
technique
9 By recording all the ways the system can be used, we accumulate all the
requirements for the system (e.g. software system or a business process)
9 Specify WHAT and not HOW
9 Identified in early stages of development by Analysts & domain experts
9 NOT an Object-Oriented technique BUT process driven
9 An informal and imprecise modeling technique

Actors
9 An external entity (person or other system) that interacts with the target system.
9 Actors can be:
o Primary Actors: Actor using the system to achieve a goal but in a
particular role
o Secondary Actors: Assist system to achieve the goal of primary actor.
Often other system communicating with the target system
o Abstract concepts, Date, Time

Identifying Actors
9 Who starts up and shutdown the system?
9 Who will benefit from the use of the system?
9 Does system use any external resources?
9 Who will maintain the system?
9 Does anything happen automatically at the set time?

Use Cases
9 Represent goal (meaningful and measurable objective for primary actor;
something of value) of an interaction between an actor and the target system
9 Pattern of behavior the system exhibits = Sequence of transactions between
actor and system
9 Describe processes Æ Should be named in VERB-NOUN form
9 Should document the system behavior from user point of view
9 Is a complete sequence of steps that provides an actor with a result of value

More notes available at: http://www.computer‐science‐notes.blogspot.com  Page 1 

 
 9 User-stories about functional requirements of a software system or business
process to be written from software or processes’ point of view; more precisely
from view of system user’s

Identifying Use Cases

9 Talk to the user how/who will use the system
9 What are the tasks of each actor like how they behave with information in the
system?
9 Will any actor need to inform the system about sudden external changes?
9 Does actor need to be informed about certain occurrence in the system?
9 What use-cases will maintain the system?

Use Case Diagrams

9 Created to visualize the (communicates) relationship between the actors and
use-cases
9 Navigation arrow shows who initiate the communication
9 Often, navigation direction is not shown
9 Show boundary of the target system

Communication 
Association

Advanced Use Case Relationships

Include (Uses Relationship):

9 Shows behavior that is common to one or more use casesÆAllows modeling of

re-use
9 Extract commonality to avoid duplicating effort
9 ‘Included Use Case’ must be included by more than one use case as otherwise
there is no use

More notes available at: http://www.computer‐science‐notes.blogspot.com  Page 2 

 
 Use-case3

(Sign Insurance Policy)

<<include>>

<<include>>

Use-case 1 use-case 2

(Buy Car Insurance) (Buy Life Insurance)

Extend:

9 Shows how a variant of behavior is possible on a mainstream use-case by

extending it
9 May model optional behavior (seldom occurring alternate courses) like exception
handling

Use-case 1 (Sign car insurance contract)

<<extend>>

Use-case 2 (Sign insurance policy)

When use-case 1 occurs, sometimes (but rarely) use-case 2 also occurs

Checking Use-Cases
9 Is use-case complete? Are there any details that need to be added?
9 Are there any procedural or requirement changes that would simplify the process
depicted in the use-case?
9 Are there any additional goals of actors that are not addressed?

More notes available at: http://www.computer‐science‐notes.blogspot.com  Page 3 

 
Documenting Use-Cases
9 ‘Use Case Description’ or ‘Flow of Events’ document is created for each use-
case
9 Written from actors point of view
9 This details what the system must provide to the actor when the use-case is
executed
9 Typical contents are
o How the use-case starts/ends?
o What interactions use-case has with actors?
o What data is needed by use-case?
o What data is generated by the use-case?
o Normal flow of events
o Alternate/exception flow of events
o Non-functional requirements

Explicitly specify who will initiate the use-case and what the use-case will do.

Structure of Use-Case

Flow of Events

Basic Path:

9 Happy day scenario: Series of simple declarative statements listing steps of use-
case from actor point of view
o Explicitly state if some statements can occur concurrently
o Where from the data comes, where and how it is stored
o All accounts to be accounted for
o Evolutionary Æ Iterative refinement
9 Use-case begins “when …..” and the use-case ends
9 Steps repetition to be explicitly written using FOR or WHILE

Alternate Paths:

9 Include user choices, error conditions etc.

9 Things that can happen anytime
9 Identifying questions:
o Can another action be taken at this point?
o Could something go wrong at this point?
o How to handle that situation?
o Could specific behavior present itself at any time?

More notes available at: http://www.computer‐science‐notes.blogspot.com  Page 4 

 
 9 Categories can also help in identifying alternatives
9 Alternatives and exceptions may be specified in paragraph form or as numbered
list. If multiple alternatives then stick to incremental style

Pre-Condition: What state system must be in at start of use-case?

Post-Condition: What state system must be at the end of use-case regardless of which
branch or alternative is followed (may need to use compound conditions)

Level of Details

Depends on:
9 who needs use-case – Manager, User, Developer
o Use-Case Business View: Describes complete process to customer
o Use-Case User View: How user will interact with specific software
o Use-Case Developer View: More information regards to development
9 How it will be used
o As a contract
o For test plan
o For user manual
o Software development
o Document new corporate process
9 What will be done with the use-case
9 What information user will need

Everything included/excluded must be documented with diagrams

Ranking Use-Cases
9 If incremental development then higher ranked use-cases can be done in earlier
increments
9 When ranking, we may consider:
o Impact on architectural design
o Ease of implementation (big bangs for bucks)
o Risk, time criticality, complexity
o Requirement for significant research
o Importance for business processes

Identifying Requirement Packages

9 UML packages partition model into smaller more manageable pieces

More notes available at: http://www.computer‐science‐notes.blogspot.com  Page 5 

 
 9 UML entities like use-cases, classes, subsystems, and even other packages can
be packaged
9 If packaging use-cases the ‘package’
o Use-cases that support a particular business process
o Use-cases that support a particular actor
o Use-cases related via ‘includes’ & ‘extends’ relationships
o Use-cases related by high cohesion and low coupling
9 Requirement packages should ideally be able to be sold/delivered respectively

Use-Cases and Stages of Development

9 Use-cases capture the functional requirements of the system
9 Use-cases act as the basis for software analysis and design
9 Use-cases help in software acceptance testing
9 Used to help validate correct and complete implementation of use-cases

When to use Use-Case Diagrams?

9 While determining user-requirements: New requirements Î new use-case
9 Communicating with the clients
9 Use-case scenario Æ Suite of test cases

Use-Case Template
9 Use-Case Name
9 Brief description: A paragraph, priority, status
9 Context Diagram: Use-case and all of its relationships
9 Pre-condition: Condition to be true before use-case starts
9 Flow of Events: Basic and Alternative
9 Post-condition: Condition to be true when use-case ends regardless of scenario
executed
9 Subordinate use-case diagram
9 Subordinate use-cases: Each with its flow of events
9 Activity Diagram: Flow of events; may be only complex or significant
9 View of Participating Classes: Collaborating classes for use-case
9 Sequence Diagram: Basic path and alternatives
9 User Interface: Sketches, Screen Shots, Storyboards
9 Business Rules: Implemented by use-case
9 Special Requirements: e.g. timing, sizing, or usability
9 Other Artifacts: Reference to sub-system use-case belongs to, analysis & design
model, code, test plan

More notes available at: http://www.computer‐science‐notes.blogspot.com  Page 6 

 
 9 Outstanding Issues: to be answered

Other Documents Required

9 Non-Functional Requirements Template
o Usability – how system will be used, level of user
o System – on which software will operate, multi-platform, multi-user
o Security – secure login, secure data transmission
o Persistence – persistent data, use of database
o Integration with other systems – hardware or software
o Error Detection/Handling/Reporting – allowed, error rate, procedure
o Redundancy – of data, subsystems, processes, or hardware
o Performance – slow/fast restriction on system or any part
o Size – of system or any part
o Internationalization – Unicode, translation
9 Glossary of Terms
9 Data Definition Document
9 User Interface Document

More notes available at: http://www.computer‐science‐notes.blogspot.com  Page 7