<<Name of the System>>

Use Case Specification

<<Use Case Name>>

Version xx
May 4, 2010
Use Case ID:

Revision History and Approval

Ver
#

Effective
Date

Brief Description of Change

Affected Sections

Author

Reviewer

Approver

Page ii

<<Use Case Name>>

TABLE OF CONTENTS
1

<<Use Case Name>>........................................................................................4

1.1

Brief Description.....................................................................................................4

1.2

Pre-Conditions........................................................................................................4

1.3

Actors....................................................................................................................4
1.3.1
1.3.2

Primary........................................................................................................................4
Secondary....................................................................................................................4

1.4

Use Case Diagram...................................................................................................4

1.5

Trigger Points.........................................................................................................4

1.6

Flow of Events........................................................................................................5
1.6.1
1.6.2

Main Flow <<Description of the Flow>>.........................................................................5

Alternative Flows...........................................................................................................5

1.6.2.1
1.6.3

AF1: <<Description of the Alternate Flow>>.................................................................................5

Exception Flows.............................................................................................................6

1.6.3.1

EF1: <<Description of the Flow>>................................................................................................ 6

1.7

Post Conditions.......................................................................................................6

1.8

Business and Processing Rules..................................................................................6

1.8.1
1.8.2

1.9

Business Rules..............................................................................................................6
Processing Rules............................................................................................................7

Messages...............................................................................................................7

1.10 Special Requirements...............................................................................................8

1.10.1 <<Special Requirement 1>>...........................................................................................8

1.11 Notes....................................................................................................................8
1.11.1 <<Note 1>>.................................................................................................................8

1.12 Page Properties.......................................................................................................9

1.12.1 <<Page 1>>.................................................................................................................9
1.12.2 <<Page 2>>.................................................................................................................9

1.13 Assumptions / Questions........................................................................................10

1.13.1 Questions....................................................................................................................10
1.13.2 Assumptions................................................................................................................10

Page iii

<<Use Case Name>>

1 <<Use Case Name>>

1.1 Brief Description
[The description briefly conveys the role and purpose of the use case. A single paragraph will suffice for this
description. The brief description should reflect the purpose of use case. As you write it, refer to actors involved in
the use case. It summarizes the actors, actions and benefits to actor. It should contain information relevant only to
this Use-Case. Ancillary functions performed by system in background such as auditing, logging, etc should NOT be
mentioned here]

1.2 Pre-Conditions
[A precondition of a use case is the state of the system that must be present prior to a use case being performed.
Precondition is a constraint on when a Use-Case can start. It is not the event that starts the Use-Case .Precondition
is not for only one sub flow. Do not mention other Use-Cases as Precondition. The emphasis here is state of System
required to proceed with the Use-Case. Examples of pre-conditions: The Actor has been authenticated. The Actor
has been authorized to perform the Use Case that initiated this use case]

1.3 Actors
1.3.1 Primary
[There is only one and only one Primary Actor for each use case. If at first it appears that there are multiple
Primary actors for the Use-Case then it indicates some analysis is needed so that multiple actors can be generalized
(abstracted) into a single base (parent) actor. This base actor embodies a common role played by multiple actors. A
Primary Actor could be a person or an external system.]

1.3.2 Secondary
[Secondary actors are supporting actors that are needed for successful completion of Use-Case. They could be
persons or external systems.]

1.4 Use Case Diagram

[The Use Case Diagram is that portion of the Use Case Model which is relevant for this Use Case. It obviously must
show the Use Case that is being written along with the Primary and Secondary Actors. If the Use Case is an
included Use Case, then the Parent Use Case should also be included it the Use Case Diagram]

View Contacts
Agent

CMS

1.5 Trigger Points

[Triggers are the reasons due to which this Use Case is invoked.
Triggers should NOT be articulated in terms of User Interface. For e.g. The Actor clicks on the Create User link
is incorrect. The correct way to articulate the same Trigger is The Actor chooses to Create User The reason is

Page 4

<<Use Case Name>>

that the functionality of creating a User is more important to the Use Case than how it is implemented on the User
Interface.
A Use Case can have more than one Trigger.]

1.6 Flow of Events

1.6.1 Main Flow <<Description of the Flow>>
[The Main Flow should always describe the happy or the main success scenario. For e.g. In Manage User Use
Case, the Main Flow must describe the flow for creating a User. It would be incorrect if the Main Flow describes a
flow for deleting a User or searching a User, which are really alternate flows.
The format for describing a flow is in the form of a table as below. Although a straight bulleted list of points also
accepted in the industry, a tabular format as below enhances readability. Some best practices to follow are:
1.

Always use extension points, which are like a heading to describe the next set of steps. The extension points will
be very useful when returning to a point in the Main Flow from an Alternate Flow

2.

Always use hyperlinks to link other parts of the Use Case, like Processing Rules, Alternate Flows or Page
Properties, etc. It enhances readability

3.

Use simple English. Avoid complex sentences. If you have to state multiple points in the same sentence, break
them up into bulleted list. Please bear in mind that the consumers of a Use Case is a human being, not a
machine.

4.

The Main Flow should not be more than 10 to 12 steps long; the shorter the better. If there are more than 10 to
12 steps, evaluate whether it can be broken down

5.

Do NOT elaborate Error / Warning messages in the flow. Refer to a separate Messages document where all
Messages are articulated.

6.

Always specify a reference to a Page / Screen from any given step in the flow. This enhances clarity with people
looking at the relevant screen while reading the Use Case

7.

Describe only the events that belong to the use case, and not what happens in other use cases or outside of the
system

8.

Avoid vague terminology such as "for example", "etc. " and "information"

9.

Make sure you use business terms consistently across all Use Cases]

Actor

System

1.6.2 Alternative Flows

1.6.2.1

AF1: <<Description of the Alternate Flow>>

[An Alternate Flow is where the Actor can choose to be, unlike an Exception Flow, where the Actor is automatically
landed by the System.
An Alternate Flow must always have an origin in the Main Flow or in another Alternate Flow it cannot just
appear out of nowhere
An Alternate Flow must always have an origin in the Main Flow or in another Alternate Flow it cannot just
appear out of nowhere]

Page 5

<<Use Case Name>>

#

Actor

System

1.6.3 Exception Flows

1.6.3.1

EF1: <<Description of the Flow>>

[An Exception Flow is where the Actor is forced into by the System. For e.g. Validation Failure, External System
Communication Exception]
#

Actor

System

1.7 Post Conditions

[A Post Condition is the state in which the System would be after the Use Case is successfully executed.
Every Main and Alternate Flow will have a Post Condition. Because Exception Flows deal with exception
situations, they do not have any Post condition
A Post Condition is a succinct statement. It is not a long paragraph. E.g. The Actor successfully receives
money and prints a receipt
Main Flow:
Alternate Flow 1:
Alternate Flow 2:

1.8 Business and Processing Rules

[From the Systems perspective, both Business and Processing Rules are exactly that, rules that need to be
evaluated. However, intrinsically, Business Rules are different from Processing Rules as explained in the
following two sections. Keeping this difference in mind, there are two separate sections provided to capture
Business and Processing Rules separately.
It is of utmost importance that every Rule, whether Business or Processing, are referenced from at least one
point in the Main or Alternate Flows. If it is found that a Rule is not referenced within the flow at all, then
that Rule is either not a Rule or has become irrelevant after analysis ]

1.8.1 Business Rules

[Business Rules are Rules that are executed regardless of the existence of a System. In order for the
business to run, these Business Rules must be executed. E.g. that an Agent in one Country cannot receive
a Transaction meant to be received in some other country is a Business Rule. This Rule will be executed
even if the Business Process were to be executed manually, without any System in place.
It is a best practice to capture all Business Rules executed by a given System in a separate document. The
following are a couple of key reasons:

Page 6

<<Use Case Name>>

1.

Should there be an initiative in the future to consolidate all Business Rules in a Rules Engine, it will be
easy if there is a separate document capturing all Business Rules.

2.

Since a given Business Rule can be relevant for more than one Use Case, capturing Business Rules in
a separate document will avoid duplication

Having said that, it is not incorrect to capture Business Rules relevant for a given Use Case right here in
the Use Case document.
It is another best practice to categorize Business Rules under Transaction, Security, and Administration.
Depending upon the System being built, more categories can be thought of. ]

1.8.2 Processing Rules

[Processing Rules are Rules that come into existence ONLY because the System is being built. These Rules
are irrelevant outside the context of the System. Processing Rules mostly deal with communicating with
External Systems, detailing an algorithm that processes certain input parameters. For e.g. the rules around
reconciling User Permissions with Device permissions in order to authorize a User is a Processing Rule.
Ideally, any given Processing Rule is relevant to one and only Use Case. If it is observed that a Processing
Rule is relevant to multiple Use Cases, it is possible that either the Rule is a Business Rule instead of a a
Processing Rule or the Use Case modeling is incorrect. Since Processing Rules are relevant to a given Use
Case, all Processing Rules for a Use Case is captured in that Use Case itself.
PR #

PR Name

PR Description

Message(s)

1.

1.9 Messages
[Messages are displayed to the Actor during the execution of the Use Case. Messages could be Error
Messages, Warning Messages, Confirmation Messages or Information Messages.
Every Message will have a Message ID, Message Title and the Message Description. It is important that
the Use Case state the exact Message ID and Message Title that will be displayed to the Actor at
appropriate points in the Main, Alternate or Exception Flows
It is a best practice to capture all messages in a separate document for the following reasons:
1.

Corporate Communication team would want to standardize all Messages across all Systems. If
messages are spread in individual Use Cases, it will be difficult to go about the process of
standardization.

2.

Most Systems of today are built for internationalization. Every time there is a decision to
introduce a new language that the System would support, there will be a need to translate, among
others, all Messages too. It will easy to go about the translation process if Messages are captured
in a separate document.

Page 7

<<Use Case Name>>

3.

Messages can be reused across more than once in a given Use Case as well as across multiple
Use Cases. Describing the Message in one place will avoid duplication and will help during
maintenance.]

1.10 Special Requirements

[Special Requirements are non functional requirements. E.g. Pagination, Audit trails, etc. Such
Requirements can be effectively captured in this section. It is important, however, to refer to these Special
Requirements from within the Main, Alternate or Exception Flows.
Every Special requirement must be detailed in a separate sub-section under Special Requirements.
However, make sure that Special Requirements that are relevant to the Use Case being written only are
captured here. It is advised that Special Requirements that are relevant to all use Cases in general are
captured in a separate document called Supplementary Specification.]

1.10.1

<<Special Requirement 1>>

1.11 Notes
[If it is found that a specific point / requirement needs more elaboration for people to understand, such
details can be provided in this section. A flow chart or an activity diagram, background to why certain
requirements are needed, etc. can be explained here.]

1.11.1

<<Note 1>>

Page 8

<<Use Case Name>>

1.12 Page Properties
[Page Properties are used to stick the wireframes. Every page / screen that is relevant to the Use Case must be included in this section. Every field
in the screen must be elaborated in the table below. Field level validations must be provided here and not in the flow.]

1.12.1

<<Page 1>>
<<Wire Frame goes here>>

Field Name

Type

Size

Mandatory
/ Optional

Display /
Input

Default
Value

Validation

Description / Remarks

Header
Location Name

Mandatory

Text

Location Address
Line1

1.12.2

<<Page 2>>
<<Wire Frame goes here>>

Field Name

Type

Size

Mandatory
/ Optional

Display /
Input

Default
Value

Validation

Description / Remarks

Page 9

<<Use Case Name>>

1.13 Assumptions / Questions
[Assumptions made and Questions that arise while detailing the Use Case can be captured in this section. All
assumptions must be validated and every question must be answered by the time the Use Case is signed off.]

1.13.1

Questions
Q#

Title

Question

1.13.2

Assumptions
AS#

Title

Assumption

Validated
(Y/N)

Page 10