Use Case #

#1

Author:

Author’s name

Iteration:

Filled (outlining the high level business requirements and identifying the alternate and exception scenarios)

Finished- completed in the Functional Specification to identify the detailed system requirements for the use case and how the  user interaction with the system should work

Name:

Use case name Verb noun

Category:

Category name – optional; use this field only if you’ve divided your use cases into functional groups (or categories).

Actor(s):

 End users performing this activity and/or systems that interface with this activity.

Description:

This use case describes…provide a brief summary of the use case.

Pre-Conditions

List any pre-conditions here in a bullet list.  What are the state of things prior to executing this use case?  What conditions must be true before this use case begins?  A pre-condition is a constraint that must be true before this use case can operate.  Often, other use cases are stated as pre-conditions.

E.g. database initialized, record already found, security established

Assumptions

Items that are outside the control of development (including the out of scope) AND must be in place before the use case can run.

Business Trigger

What is the business event that causes this use case to occur?

Flow of Events (Basic Path)

Step

Action 

This is the primary flow.  Supply the detailed flow descriptions here in a numbered style text.  You should have 3 -9 steps.  Document how the use case starts and ends.  Indicate what the customer wants the system to do.  Use the active voice.  The actor and the system perform the actions.  Use present tense.  Name the actor based upon the role that the actor represents in the problem domain.  The flow should contain the step #, Actor Action, System Action, Screen (if available) and Event.  The events are documented to better understand the major functions/processes the Actors are performing on the system. This information will later be used to create the event list template.

1

The use case begins when…

2

3

4

The use case ends when…

Post Conditions

List any post conditions here in a bullet list.  What are the state of things after you execute this use case?  What is the next step?  Indicate the successful post-conditions and the failed post-conditions.  E.g. Client added to the database, Resource ‘X’ assigned to project ‘Y’.

Alternate Scenarios

Step

Branching Action

1

Alternate flows are generally considered to be choices that are intentionally made by an actor.  Each alternate flow is labeled with an identifier in the form  A#1.  Each alternative flow is also named with a one-sentence description.  Each alternative flow has a set of steps numbered in sequential order.  It then statements are alternate scenarios.

Note:  the step number here refers to step in the basic path where the alternate scenario branches off of the basic path.

2

3

Exception

Scenarios

Exception flows are generally considered to be choices that are not intentionally made by the actor and normally result from significant error conditions.  What are the what ifs?  The errors that can happen.  Each exceptional flow is labeled with an identifier in the form E#1.  Each exceptional flow is also named with a one-sentence description.

Business Rules Validated

List any business rules associated with this use case, e.g. guests cannot order a quantity greater than 3 of any one item; to calculate tax in the state of Massachusetts, multiply the total by .05.

Special Requirements

In many situations you will uncover requirements that do not fall within the scope of the use case description, list those here, e.g. volumes, usability issues, time constraints, security issues.

Issues

List any questions and issues to be addressed by the end of the discovery stage.

Design Comments

This section is optional.  State any design comments and/or suggestions and clearly identify them as either comments/suggestions or as customer-stated, design constraints.  This can include suggestions or constraints on the GUI as well as other parts of the system.  These will be used as considerations by the design team when designing the classes that will implement the use case.  Also can use this section to document system rules.