Business or System Use Case(s)
System Name: __________________________ Date: ___________________________
Contents
1. Use Case Name ........................................................................................................................... 2
2. Pre-Conditions............................................................................................................................. 2
3. Goals............................................................................................................................................ 3
4. Performance Goals...................................................................................................................... 3
5. Basic Flow .................................................................................................................................... 3
6. Alternative Flows ........................................................................................................................ 3
7. Post-Conditions ........................................................................................................................... 4
8. Business Rules ............................................................................................................................. 4
9. Process Improvement Possibilities ............................................................................................. 4
10. Process Owner .......................................................................................................................... 4
11. Special Requirements ............................................................................................................... 4
12. Use Case Relationships ............................................................................................................. 5
13. Issues and Resolutions .............................................................................................................. 6
Business or System use Case(s)
Page 1 of 6
1. Use Case Name
Brief Description
Briefly convey the purpose of the business or system use case. A single paragraph should suffice.
Actors
A list of all actors pertaining to this use case
Scope and Boundaries
This is a description of the scope of this Use-Case Specification. It may be worded to explain what is not affected or influenced by this
document. For example: “This use case does not address HIPAA.”] If it is non-applicable, put N/A
References and Supplemental Documentation
Provide a complete list of all documents referenced elsewhere in the Use-Case Specification. This information may be provided by
reference to an appendix or to another document. Supplemental documentation should be used to capture any interface specific
information, design, and/or legal documents that need to be adhered to.
Document Title
Report Number (if
applicable)
Date
Publishing
Organization
Source
A picture is sometimes worth a thousand words, though there is no substitute for clean, clear prose. If it improves clarity, feel free to
include graphical depictions of user interfaces, process flows or other figures into a supplemental document. If a flow chart is useful to
present a complex decision process, by all means use it! Similarly for state-dependent behavior, a state-transition diagram often clarifies
the behavior of a system better than pages upon pages of text. Use the right presentation medium for your problem, but be wary of
using terminology, notations or figures that your audience may not understand. Remember that your purpose is to clarify, not obscure.]
(Optional-if not used put N/A)
2. Pre-Conditions
A pre-condition of a use case is the state of the system or business process that must be present prior to a use case being performed.
Pre-conditions should be chosen to explain the prerequisite state before the basic flow can be started, encompassing all possible
alternate flows. It should not reference another use case name, but rather the state of the system or business process. I.E. the client is
identified. (Optional-if not used put N/A)
<Pre-Condition One>
A brief description of the pre-condition
Business or System use Case(s)
Page 2 of 6
3. Goals
A specification of the measurable goals or objectives of the business or system use case. It should describe the purpose of the use case.
<Goal One>
A brief description of the goal
4. Performance Goals
A specification of the metrics relevant to the business or system use case, and a definition of the goals of using those metrics. The most
common metrics used are time (an approximation of the time it should take to execute the workflow, or part of the workflow) and cost
(an approximation of the cost of executing the workflow, or part of the workflow.) (Optional-if not used put N/A)
<Performance Goal One>
A brief description of the performance goal
5. Basic Flow
A brief description of the basic flow scenario
<Basic Flow Step One>
The step name must begin with verb.
This use case starts when the actor does something. An actor always initiates use cases. The use case describes what the actor does and
what the system does in response. It needs to be phrased in the form of a dialog between the actor and the system.
The use case describes what happens inside the system, but not how or why. If information is exchanged, be specific about what is
passed back and forth. For example, it is not very illuminating to say that the actor enters customer information. It is better to say the
actor enters the customer’s name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageable—
you may want to define things like customer information there to keep the use case from drowning in details.
Simple alternatives may be presented within the text of the use case. If it only takes a few sentences to describe what happens when
there is an alternative, do it directly within the Basic Flow section. If the alternative flow is more complex, use a separate section to
describe it. For example, an Alternative Flow subsection explains how to describe more complex alternatives.
End Use Case
The use case ends. Optional: when <condition for ending use case>
6. Alternative Flows
(Optional-if not used put N/A)
Business or System use Case(s)
Page 3 of 6
<Alternative Flow One>
More complex alternatives are described in a separate section, referred to in the Basic Flow section. Think of the Alternative Flow
subsections like alternative behavior—each alternative flow represents alternative behavior usually due to exceptions that occur in the
main flow. They may be as long as necessary to describe the events associated with the alternative behavior. When an alternative flow
ends, the events of the main flow of events are resumed unless otherwise stated.
7. Post-Conditions
A post-condition of a use case is a list of possible states the business process or system can be in immediately after a use case has
finished. Post-conditions can be a powerful tool for describing use cases. First define what the use case is supposed to achieve — the
post-condition, and then describe how to reach this condition — the flow of events needed. When using post-conditions together with
extend-relationships, take care that the extending use case does not introduce a subflow that violates the post-condition in the base use
case
<Post Condition One>
(Reference the appropriate flow)
8. Business Rules
A business rule defines a specific constraint or invariant that must be satisfied by the business or system. (Optional-if not used put N/A)
<Business Rule One>
A brief description of the business rule
9. Process Improvement Possibilities
A specification of any improvements to the process described by this use case: This section should reflect improvement potential within
the workflow. Refer to performance goals specified as a guideline. (Optional-if not used put N/A)
10. Process Owner
A definition of who the owner of the business or system process is, the entity who manages the changes and plans for changes.
(Optional-if not used put N/A)
11. Special Requirements
A special requirement is typically a nonfunctional requirement that is specific to a use case, but is not easily or naturally specified in the
text of the use case’s event flow. Include if limited to this use case. If the requirement is global to many use case, it is recommended the
requirements be placed in a global special requirement document. Examples of special requirements include legal and regulatory
requirements, application standards, and quality attributes of the system to be built including usability, reliability, performance or
supportability requirements. Additionally, other requirements—such as operating systems and environments, compatibility
requirements, and design constraints—should be captured in this section. (Optional-if not used put N/A)
Business or System use Case(s)
Page 4 of 6
<Special Requirement One>
A brief description of the special requirement
12. Use Case Relationships
A brief description of any relationships between use cases: Insert use case diagram pertaining to this use case only, including actors and
any related use cases. If a relationship between use cases is conditional then the condition must be annotated on the diagram.
Include-Relationship
Extend-Relationship
The include-relationship connects a base use case to an
inclusion use case. The inclusion use case is always abstract
The extend-relationship connects an extension use case to a
base use case. You define where in the base to insert the
extension by referring to extension points in the base use case
points. The extension use case is often abstract, but does not
have to be.
Example
Example
Identify Customer
Caller
<<include>>
<<include>>
<<include>>
<<extend>>
Place Call
<<extend>>
Deposit Cash Withdraw Cash Transfer Funds
Place Conference Call
Show Caller Identity
Use Case Generalization
A parent use case may be specialized into one or more child use cases that represent more specific forms of the parent.
Neither parent nor child is necessarily abstract, although the parent in most cases is abstract. A child inherits all structure,
behavior, and relationships of the parent. Children of the same parent are all specializations of the parent.
Business or System use Case(s)
Page 5 of 6
Example
Place Order
Customer
Phone Order
Online Order
Online
Customer
13. Issues and Resolutions
A brief description of any issues and resolutions pertaining to the completion of the use case: The date of the
resolution should be included. (Optional-if not used put N/A)
<Issues and Resolutions One>
A brief description of the issues and resolutions
Business or System use Case(s)
Page 6 of 6