In a recent post, I provided a definition of use case as well as an example.
The example I provided uses a very simple format. In most real-world projects, teams find it helpful to use a more fully-dressed format.
In this post, I share a use case template in a fully-dressed format, as well as a use case example using the template. You can even download the template as a Microsoft Word file.
Alright, here we go…
“Fully-Dressed” Use Case Template
Primarily based on the couple of books I referred to earlier (“Software Requirements,” by Karl Wiegers and “Writing Effective Use Cases,” by Alistair Cockburn) – here’s an example of a use case in a fully-dressed format:
| ID: | UC-6 |
| Title: | Register for courses |
| Description: | Student accesses the system and views the courses currently available for him to register. Then he selects the courses and registers for them. |
| Primary Actor: | Student |
| Preconditions: | Student is logged into system |
| Postconditions: | Student is registered for courses |
| Main Success Scenario: |
1. Student selects “Register New Courses” from the menu. 2. System displays list of courses available for registering. 3. Student selects one or more courses he wants to register for. 4. Student clicks “Submit” button. 5. System registers student for the selected courses and displays a confirmation message. |
| Extensions: | 2a. No courses are available for this student. — 2a1. System displays error message saying no courses are available, and provides the reason & how to rectify if possible. — 2a2. Student either backs out of this use case, or tries again after rectifying the cause.5a. Some courses could not be registered. — 5a1. System displays message showing which courses were registered, and which courses were not registered along with a reason for each failure.5b. None of the courses could be registered. — 5b1. System displays message saying none of the courses could be registered, along with a reason for each failure. |
| Frequency of Use: | A few times every quarter |
| Status: | Pending Review |
| Owner: | John Smith |
| Priority: | P3 – Medium |
Explanation of fields
Here’s what these fields are for:
- Title: Enter the goal of the use case – preferably as a short, active verb phrase.
- Description: Describe the goal and context of this use case. This is usually an expanded version of what you entered in the “Title” field.
- Primary Actor: A person or a software/hardware system that interacts with your system to achieve the goal of this use case.
- Precondition: Describe the state the system is in before the first event in this use case.
- Postcondition: Describe the state the system is in after all the events in this use case have taken place.
- Main Success Scenario: As you can see, this field contains the example from our previous post – i.e. the flow of events from preconditions to postconditions, when nothing goes wrong
- Extensions: Describe all the other scenarios for this use case – including exceptions and error cases.
- The other fields are self-explanatory.
I’ve seen use case templates that contain 2-3 times as many fields as our example above. But I think the template I’ve provided is a good balance – it has enough structured data, but not so much that it becomes overwhelming to complete and use for real-world projects.
There’s much to writing effective use cases using this template, especially the “Main Success Scenario” and “Extensions” – I’ll cover them in detail in future posts.
Download Word File: Here’s the Use Case Template in Microsoft Word format.
By the way, our Accompa Requirements Management Software can help you create, manage and collaborate on your use cases – using customizable use case templates.
