Business Analysis Level II

USE CASE MODELING

CONFIDENTIALITY: 2010 BA ValueBASE LLP, The concepts and methodologies contained herein are proprietary to BA ValueBASE LLP. Duplication,
reproduction or disclosure of information in this document without the express written permission of BA ValueBASE LLP is prohibited.

Learning Objectives

Defining Use Case?

Understanding:
Use Case Diagram
Use Case Model
2011 BA ValueBASE LLP

USE CASE

Use Case is exactly what it says:

A CASE for a user to USE the solution

Q: Hey, why would you use an ATM?
A: I would use an ATM, say, in case I need to withdraw money

Withdraw Money is therefore a Use Case for a solution called ATM.

A Use Case represents a Goal of a User
UML Notation for a Use Case
2011 BA ValueBASE LLP

Actor

A role that a user plays with respect to the system

Represents anything that interacts with the system

Gives / takes information from the system
Is identified as external to the system
Time, if the actor triggers the event at specified time

2011 BA ValueBASE LLP

Actor's Relationship with Use Cases?

An Actor in a Use Case:

Is a role user plays with respect to the system

Is anything that interacts with the system

Exchanges information with the system

Is external to the system

Fig: Actor Representation

The Actor can be divided into two sub-categories according to there relation with the Use case:

Primary Actor: A primary actor is one having a goal requiring the assistance of the system.
Eg. For Create Order' Use Case, the Order Entry Clerk will be the primary actor as it uses this
functionality to complete its action.

Secondary Actor: A secondary actor is one from which the system needs assistance.
Eg. For the same Create Order' Use Case, a database administrator can be a secondary actor who
will define the roles of different order entry clerks.
2011 BA ValueBASE LLP

How to Identify Actors?

Actors are people or other systems to whom the system provides value.

To identify actors it is important to identify the purpose and boundary of the system and to
know whom it provides value.

To find to whom system provides value for, try finding answers to these questions:

Who will use this system?

Who, or what, will supply, use, or remove information?

Who is interested in a certain requirement or area of functionality?

Who is involved in the undertaking of the system's use cases?

What other systems are required to interact with this one?

What external resources does the system require?

Who or what starts the system?

Who will support and maintain the system?

2011 BA ValueBASE LLP

How to Identify Actors? (Cont..)

Example: ATM

In ATM application, the people or system interacting with the ATM system are

Customers to withdraw cash, deposit cash, check balance, print statements and
request for Cheque book

Bank Personnel to load the cash

Banking System to send/ receive customer account information and receive

Cheque book request

Customers, Bank Personnel and Banking System are the actors of the system.

2011 BA ValueBASE LLP

What is Use Case?

Describes how an actor uses a system to achieve a goal and what the system does for the
actor to achieve that goal. It tells the story of how the system and its actors collaborate to
deliver something of value for at least one of the actors.
- Kurt Bitner

Use Case is

A dialogue between the actors and the system

Initiated by an actor to invoke specific functionality

Results in a specific output of identifiable value for the actor

Use Case name should be in Verb-Noun format

Use Case Name

Fig: Use Case Representation
2011 BA ValueBASE LLP

How to Identify Use Cases?

Use Cases tells the story of how the system and its actors collaborate to deliver something of
value for at least one of the actors.

To identify use cases, identify the actors need or value from the system.

Focusing on actor value is key in identifying use cases. Trying to answer these questions will
enable identifying use cases:

For each actor you have identified, what are the goals that the system will fulfill?

Will the actor need to inform the system about sudden, external changes?

Can all features be performed by the use cases you have identified?

What use cases will start, stop, configure, support, and maintain the system?

What information must be modified or created in the system?

What events will the system need to be informed about?

What occurrences must the system track and inform the actors about?

Does the use-case model represent the interests of all the stakeholders?
2011 BA ValueBASE LLP

How to Identify Use Cases? (Cont..)

User Interaction Use Cases:

Identify the functionality of the system that provides a value to the actor.
E.g.: Withdraw Money in ATM Application will be a use case.

Group the set of related functionality of the system that provides a value to the actor.

E.g.: Create, Update and View Bank Account in Banking Application will be grouped together to create a
Maintain Bank Account use case.

Do NOT identify use cases for menu that will just act as a dispatcher to Include other use cases and has no
functionality on its own.
E.g.: In a Banking Application if Search is a menu option and it has search for bank accounts, customers and
transactions. Perform Search CANNOT be a use case on its own that includes Perform Customer Search,
Perform Transactions Search etc. The search functionality will be handled by individual Search use cases.

Do NOT identify features that does not provide any business value to the actor.
E.g.: Verifying ATM Password cannot be a use case. It does not provide any business value of Withdraw
Money or Deposit Money.
2011 BA ValueBASE LLP

CONCEPT:

USE CASE RELATIONSHIPS

2011 BA ValueBASE LLP

What are Use Case Relationships?

During the process of Use Case modeling or further down during Detailed
Requirements phase, when the Use Case are being detailed, it is likely that the
Business Analyst (or the team) will discover a commonality in behavior between

two or more use cases or a variation in behavior of an use case under specific
circumstances. These two forces drive relationship between use cases.

When commonality in behavior occurs, <<Include>> relationship is used and

When variation in behavior under specific circumstances occur <<Extend>>

relation is used.
2011 BA ValueBASE LLP

Include Use Case

<<Include>> is used when a functionality is repeated in two or more
separate use cases and we want to avoid repetition

A use case uses another use case (functional decomposition)

Included use case can also exist independently

They are executed unconditionally

2011 BA ValueBASE LLP

Extend Use Case

An <<Extend>> relationship is used to specify when one Use Case
extends the behavior of another Use Case. In other words,
additional functionality that becomes conditionally relevant are
captured in a separate Use Case called the extending Use Case and
is extended from a base Use Case.
The extend relationship specifies that the incorporation of the
extending Use Case is dependent on what happens when the base
Use Case executes. In other words, only upon reaching a certain
specific condition in the base Use Case, the extending Use Case is
invoked, not otherwise. A corollary of this is that the base Use Case
is defined independently and is meaningful by itself. However, the
extending Use Case is not meaningful on its own. The reason is
because the extending use case consists of behavior segments that
describe additional behavior that can incrementally augment the
behavior of the base Use Case.
2011 BA ValueBASE LLP

CONCEPT:

USE CASE DIAGRAM

2011 BA ValueBASE LLP

What is Use Case Diagram ?

A use case diagram is a diagram that provides a high-level graphical view of

the functionality (use cases) supported by the system and shows which roles
(actors) can invoke each use case.

A diagram to show the various user roles and how those roles use the
system.
Withdraw Money

Balance Enquiry
Customer
Change Pin Code

Fig: Sample Use Case Diagram

2011 BA ValueBASE LLP

CONCEPT:

USE CASE MODEL

2011 BA ValueBASE LLP

What is Use Case Model ?

Sample Use Case Model

The use-case model is the set of all the use

cases, actors, and use-caseactor associations
used to describe a particular system.

Make Payment

OPAL

The set of all actors and use cases describing

a system are known as the system's use-case
model.

- Kurt Bitner
A 'use case model' describes the complete
functionality of a system by identifying how
everything that is outside the system interacts
with it

Customer

Nominate Card

SOLVE

Create Hot Card

Request

Financial Analyst

Chargeback for Card

Acquirer

Generate Reports

Payment Manager
Scheduler

Pass Transaction
Data to PPS

2011 BA ValueBASE LLP

CONCEPT:

USE CASE MODEL - WHEN, WHY, WHAT

2011 BA ValueBASE LLP

Life Cycle of A Use Case

Requirements

Development

Testing

Identified

Analyzed

Verified

Authored

Designed

Accepted

Agreed

Implemented

2011 BA ValueBASE LLP

When do we use Use Cases?

Use Cases are developed to realize functional flows of solution

requirements in projects.

A key input to developing a Use Case Model is to have a prioritized

list of Business/ Functional Requirements, which will be available
at the end of the Big Picture phase or at the beginning of High Level
Requirements phase. Thus, a Use Case Model is developed in the High
Level Requirements phase.

Detailed Use Case Specification documents are produced based on the

iteration plan.

2011 BA ValueBASE LLP

Benefits of Use Case (as against other methods)

Due to its user-centric technique, it is made sure the right system is built

Powerful technique for the elicitation and documentation of blackbox functional requirements

Because they are written in natural language, use cases are easy to understand and provide an
excellent way for communicating with customers and users

Use cases can help manage the complexity of large projects by decomposing the problem into
major functions

They use lower-level scenarios to capture requirements completely

They provide a good basis for verification of functional requirements

Give an objective means of project tracking in terms of use cases implemented / tested and
delivered

Use cases can form the foundation on which to specify end-to-end timing requirements for realtime applications.
2011 BA ValueBASE LLP

Use Case pitfalls / What can go Wrong

If the System Scope is Undefined or Inconsistent, it may lead to conflicting use cases

If the Use Cases are written from only Systems perspective, it may lead to hard to use systems from the users point
of view

Inconsistent naming of Actors may mislead developers

Actors having wrong functional roles may lead to imperfect processing

If the Actors goals are at too low level, it may obscure the big picture

Too many technical and UX details is a strictly a no-no. This could limit the developers creativity and thought process

If Use Cases are too confusing or too long, the developer may meander into insignificant areas

Disorganized Use Cases may confuse the developer

Too many Use Cases, if ungrouped, may make it difficult for development

If Customers not able to understand the Use Cases, it may lead to incorrect requirements capturing

2011 BA ValueBASE LLP

When NOT to apply Use Cases in Projects?

In Requirements Engineering projects of Data Warehousing type where the system to be
designed is a reporting tool, the functional requirements are realized using Reporting
Specification and not use case methodology.
In Maintenance Projects when the enhancement is minor change to an existing
requirement and use case methodology is not followed in the project, the requirements
are captured in form of Functional Requirements.
When the proposed System is not a Business Application. For e.g. Use Cases will not work
for building compilers or operating systems.
Use Cases can only capture System behavior. They cannot capture Non Functional
Requirements. Use the good old system of statements for capturing Non Functional
Requirements

2011 BA ValueBASE LLP

Tips and Takeaways

Name the use cases with a <<Verb>> followed by <<Noun>> indicating the goal of the
use case.

Use active verb in present tense for use case steps. Dont use passive voice.

Avoid Functional Decomposition and Dataflow Modeling during use case identification.

Have a single Maintain use case for Create, Read, Update and Delete functions.
Breaking it into separate use case is functional decomposition.

Avoid multiple primary actor roles for single use case.

Prevent using extend functionality till needed.

Do NOT use implementation details like technology and User interface.

In Batch Use Cases, the scheduler/ time triggers the use case. So Scheduler can be used
as a primary actor.
2011 BA ValueBASE LLP

Tips and Takeaways

Contd

In few scenarios, the Interface Use Cases can be triggered by the system. In these
scenarios the "System Under Development" is referred as Primary Actor. These
interface use cases will always be as a include use case.

Maintain focus on the goal of use case when detailing.

Don't describe what happens outside the system in use case flows.

Synthesize, Don't Analyze when identifying use cases.

Dont just draw pictures when implementing Use Case Modeling.

Dont mix business and system use cases.

The rule of thumb is that an approved Use Case document must be available before a
designer initiates design of the functionality described in the Use Case.
2011 BA ValueBASE LLP

Thank You

2011 BA ValueBASE LLP