Project Name
Document Version 1.0
Prepared by Jane Doe, ITS
Last Edited February 9, 2016
PLAN
REQUIREMENTS
SOLUTION
ANALYSIS
DESIGN
BUILD
TEST
TRAIN/DEPLOY MAINTENANCE
TO THE DOCUMENT OWNER: This template is provided as a guideline and resource. The structure and instructions
give detail about what might go into a completed document. Only you and your team, however, know what will
best fit the needs of your specific effort, and you are encouraged to adapt the template as appropriate to meet
those needs.
Use Case
Use Cases identify all actor-action scenarios for the product, a critical step in defining the functions which
the system should deliver. A formal Use Case defines the details of a single scenario, including specific
requirements which must be in place for the action to occur, the consequences of the action, and errors
or variations which may occur. Use Cases will be reviewed by the project team for accuracy and
completeness. Functional requirements are linked to Use Cases through the Requirements Traceability
Matrix, and the Use Cases will be used by the project testing team as a foundation for creating functional
test scripts.
1.0
Use Case Name
Enter a short name for the Use Case that describes the action of the use case, e.g. Register User,
Calculate Undergraduate Tuition, etc.
2.0
Use Case ID
Enter a unique numeric identifier for the Use Case. e.g. UC_CASI-123.
3.0
Objective
Briefly describe the objective of this Use Case.
4.0
Scope
4.1
In scope
Describe the objective and/or components of this Use Case, e.g. the process, service or piece of
functionality that is addressed.
4.2
Out of Scope
Describe the objective and/or components that will not be addressed in this Use Case, e.g. the
process, service or piece of functionality that is not covered.
Page 1 of 3
Project Name
Document Version 1.0
5.0
Actors
5.1
Primary
Define the Primary Actor of the use case. This is the actor who will be satisfied by this Use Case
and has the primary interest in the outcome of this Use Case.
5.2
Secondary
Define the other Actors who assist the Primary Actor to achieve his or her goal, e.g., System
Administrator, Developer, EID Holder, Student.
6.0
Pre-conditions
List the conditions that must be true before this Use Case can be executed.
7.0
Post conditions
Enter the successful end condition of the Use Case where the Primary Actor’s goal is accomplished, e.g.,
user is authenticated to access an application.
8.0
Triggers
List the event(s) that start this Use Case, e.g., User accesses application.
9.0
Assumptions and Dependencies
Describe assumptions made with the creation and fulfillment of this Use Case. List any impacts to other
systems, services, applications, etc. For example, this use case cannot happen unless a system is online.
10.0 Terms and Abbreviations
List common terms that will be used in this Use Case. If common terms are defined project-wide, provide
a link to the appropriate documentation.
Term
11.0
Definition
Process Diagrams and Steps
11.1
Normal
List the main flow of events, step-by-step, i.e., describe the straight and simple path where
everything goes as expected and enables the primary actor to accomplish his or her goal. Main
flow/path should always end with a success end condition.
Use Case
Page 2 of 3
Project Name
Document Version 1.0
1. Enter step here.
2. Enter step here.
3. Enter step here.
11.2
Exceptions
List the exceptions of the main flow, step-by-step. These exceptions address deviations from the
main path, such as errors.
1. Enter step here.
2. Enter step here.
3. Enter step here.
11.3
Variations
Enter any data entry or technology variations e.g, different methods of data input,
screen/module invocation, browser versions, etc.
12.0
Requirements
The table below should include the requirements that are addressed in this use case.
ID
13.0
Description
Operational Impact
List any side effects or impacts to other systems, services, applications, etc.
14.0
Stakeholders
List people, departments, organizations and/or roles that should be consulted on or informed of changes
to this use case.
15.0
Issues
List any issues associated with this use case. For example, a known defect in the selected software that is
expected to be fixed by the vendor but not does not have a scheduled release.
Revision History
Version
V1
Use Case
Date
Updater Name
Description
Initial draft completed.
Page 3 of 3