-
Notifications
You must be signed in to change notification settings - Fork 3
Use Case template and explanation
This page defines the format of the Use Case template. It was modified from this example. Use case template in github markdown:
| Use Case ID: | |
| ------------- | ------------- |
| Use Case Name: | |
| Created by: | |
| Date Created: | |
| Date Last Updated: | |
| Last Updated by: | |
| | |
| Actor: | |
| Description: | |
| Preconditions: | |
| Postconditions: | |
| Priority: | |
| Frequency of Use: | |
| Normal Course of Events: | |
| Alternative Courses: | |
| Exceptions: | |
| Includes: | |
| Special Requirements: | |
| Assumptions: | |
| Notes and Issues: | |
And a rendered example:
| Use Case ID: | |
|---|---|
| Use Case Name: | |
| Created by: | |
| Date Created: | |
| Date Last Updated: | |
| Last Updated by: | |
| Actor: | |
| Description: | |
| Preconditions: | |
| Postconditions: | |
| Priority: | |
| Frequency of Use: | |
| Normal Course of Events: | |
| Alternative Courses: | |
| Exceptions: | |
| Includes: | |
| Special Requirements: | |
| Assumptions: | |
| Notes and Issues: |
In order to create an ordered list inside of a table cell, you need to do the following:
| Question | Answer |
| -------- | ------ |
| What do I like to eat? | 1. Eggs <br>2. Beans <br>3. Spaghetti |
Which will show up as:
| Question | Answer |
|---|---|
| What do I like to eat? | 1. Eggs 2. Beans 3. Spaghetti |
If a section of the use case template seems unnecessary or redundant for a certain use case, don't feel obligated to fill in the section. Leave it blank so that if it can be filled in if it becomes relevant at a later date.
Give each use case a unique numeric identifier, in hierarchical form: X.Y. Related use cases can be grouped in the hierarchy. Functional requirements can be traced back to a labeled use case.
For the purposes of organization, the hardware team should use the number: 1.X while the software team will use: 2.X
State a concise, results-oriented name for the use case. These reflect the tasks the user needs to be able to accomplish using the system. Include an action verb and a noun. Some examples:
• View part number information.
• Manually mark hypertext source and establish link to target.
• Place an order for a CD with the updated software version.
Supply the name of the person who initially documented this use case.
Enter the date on which the use case was initially documented.
Supply the name of the person who performed the most recent update to the use case description.
Enter the date on which the use case was most recently updated.
An actor is a person or other entity external to the software system being specified who interacts with the system and performs use cases to accomplish tasks. Different actors often correspond to different user classes, or roles, identified from the customer community that will use the product. Name the actor(s) that will be performing this use case.
Provide a brief description of the reason for and outcome of this use case, or a high-level description of the sequence of actions and the outcome of executing the use case.
List any activities that must take place, or any conditions that must be true, before the use case can be started. Number each precondition. Examples:
-
User’s identity has been authenticated.
-
User’s computer has sufficient free memory available to launch task.
Describe the state of the system at the conclusion of the use case execution. Number each postcondition. Examples:
-
Document contains only valid SGML tags.
-
Price of item in database has been updated with new value.
Indicate the relative priority of implementing the functionality required to allow this use case to be executed.
Estimate the number of times this use case will be performed by the actors per some appropriate unit of time.
Provide a detailed description of the user actions and system responses that will take place during execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use case name and description. This description may be written as an answer to the hypothetical question, “How do I ?” This is best done as a numbered list of actions performed by the actor, alternating with responses provided by the system.
Use a numbered format to detail steps:
-
Acquire hotdog
-
Apply mustard
-
Apply ketchup
Document other, legitimate usage scenarios that can take place within this use case separately in this section. State the alternative course, and describe any differences in the sequence of steps that take place. Number each alternative course using the step from the normal course of events. If the step is big enough to warrant it's own use case, give the number in the step.
2.a. There is no mustard
2.a.1 Look in cupboard for more mustard
--
3.b There is no ketchup
3.b.1 Buy ketchup ( Case ID: 1.5 )
Describe any anticipated error conditions that could occur during execution of the use case, and define how the system is to respond to those conditions. Also, describe how the system is to respond if the use case execution fails for some unanticipated reason.
3.b.1.ex Cannot go to store
3.b.1.ex.1 Eat hotdog with no ketchup.
List any other use cases that are included (“called”) by this use case. Common functionality that appears in multiple use cases can be split out into a separate use case that is included by the ones that need that common functionality.
Identify any additional requirements, such as nonfunctional requirements, for the use case that may need to be addressed during design or implementation. These may include performance requirements or other quality attributes.
List any assumptions that were made in the analysis that led to accepting this use case into the product description and writing the use case description.
List any additional comments about this use case or any remaining open issues or TBDs (To Be Determined) that must be resolved. Identify who will resolve each issue, the due date, and what the resolution ultimately is.