Use Case Template
Use Case ID: {This should be coded to identify the owning team and the level of the use case}
Use Case Level: {High-level, system-level end-to-end, functional sub-use case}
Scenario (User Story): {As a <Role>, I want <feature> so that <execution of feature or post
condition>
Details: {This is a complete description of the use. Each subsection is explained below.}
 Actor: {Which actor from the actor model initiates this use case? This should be a reference
into the actor description model.}
 Pre-conditions: {This describes requirements on the state of the system prior to this use
being valid.}
 Description: {A detailed description of the use. It is structured as shown below.}
Trigger: The user initiates an action by...
The system responds by...
{In this section reference is made to sub-use cases that this “use case” uses, or
series of steps perfromed by the user}
 Relevant requirements: {In this section reference is made to any other requirements documents such as industry standards or government regulations.}
 Post-conditions: {This describes the state of the system following the successful completion
of this use. Affects on other systems and actors may also be described.}
Alternative Courses of Action {This section presents other scenarios that are related to the main
scenario but that differ in small ways.}
Extensions: {This section presents variations on this use case that “specializes” it. It presents
those use cases that have an extends relation with the current use case.}
Exceptions: {This section describes all error conditions that can arise in the use case.}
Concurrent Uses: {This use can occur concurrently with the uses listed in this section.}
Related Use Cases: {Reference is made here to use cases that describe uses that are either usually
performed just before or after the current use.}
--------------------------------------------------------------------------------------------------------------------Decision Support
Frequency: {How often will this use of the system occur? Usually stated in terms of number of
times per application execution, but can be stated in terms of number of times per hour of execution
for always available systems. This field is combined with the criticality field to determine the
number of tests that will be used to test the functionality. It may also be used in certain design
decisions.}
Criticality: {How necessary is this use to the successful functioning of the program from a user’s
perspective. Its absence may not cause the system to crash, but it may prevent the user from accomplishing their goal. This field is used to assist in determining the extent to which the use will
be tested.}
Risk: {The project risk associated with providing this use. This is used in project planning. Often
riskier uses will be implemented early to provide sufficient recovery time.}
Constraints:
{ Use structured natural language to describe the constraints(non-functional requirements)
related to this use cases. These non-functional requirements neeed to be quna}

Usability {Maybe be described in the training time needed and/or the help provided to
the user}

Reliability {Usually described in the terms of the mean time to failure (MTTF) or
downtime of the system}

Performance {Usually described in the response time of the system, which may include
processing time, time to save data, etc.}

Supportability {Explicitly states the platforms the system should run on either web-based
ot mobile-based}

Implementation {Desribes the implmentation language and technologies that are
required by the client}
--------------------------------------------------------------------------------------------------------------------Modification History -- {Follow the standard corporate document versioning template}
Owner:
Initiation date:
Date last modified:
Thanks to Dr. John McGregor, Computer Science Department Clemson University.