This is part 2 of 2 of the use case document series. In part 1, I explained what a use case is, and outlined the benefits and components of a use case. In this article, I'll go through the use case template and provide a step-by-step guide to creating one.
The use case could be part of the Business Requirement Document (BRD) or a separate document depending on the organization you are working for.
Not all use case documents include the entire list mentioned above; it depends on the level of detail you wish to achieve; however, providing more detail to stakeholders is beneficial We write use cases to a level that is appropriate to readers
1. Name top
Assign a unique name to your use case preferably describing the functionality you want to present (like food order, order processing or ATM machine)
2. Brief description top
The use case description can be in any of the following formats:
- Narrative: it is describing the user’s intent from the use case in a free form text; it tells the story of the user’s actions during the use case
- Scenario: it is describing the sequence of events and the list of steps to accomplish; it is a simple step by step statement in logical sequence, such as in ATM machine:
- Present transaction screen
- Capture fast cash withdrawal request
- Post transaction to bank and confirm
- Dispense money, card and transaction receipt
- Conversation: it is describing the use case behavior in a dialogue form between the user and the system, such as:
You can use any of the above formats to describe your use case as long as it’s clear and easy for the stakeholders to understand.
3. Define your use case actors top
In this step, you will basically list all your actors, their role description and their objectives.
Once you have identified your actors and their goals, you have now created your initial list of high level use cases. Remember, effective use cases must have understandable actors and goals.
4. Create the use case basic flow top
The basic flow represents the most important course of events or what happens most of the time, sometimes called a “happy day scenario” because it occurs when everything goes well (no errors). The benefits of creating the basic flow is that it once the norm is understood – which represents 70% of the system – it is easier to comprehend exceptions
5. Create the alternative flow top
The alternative flow could be a variation or exception:
- Variation: it is also referred to as an additional flow, which is another significant way to accomplish the same function that could be taken at this point (not necessarily error based). For example you can press (CTRL + S) to save a document or click on menu then click save. Another example, you can enter your username and password then hit ENTER or click on the LOGIN button
- Exception: it describes anything that could go wrong (error), like what would happen if the user enters a wrong password? The system sends an error message
6. Special requirements top
Special requirements describe any limitations to the function. For example, wire transfer limit is $500 or country limitations for international calls
7. Pre-conditions top
Pre-conditions are the conditions that must be met before this use case can start. Such as, the user has been granted authority to access the system or prices must exist for the products being sold.
"Pre-conditions are like the guards on the use case." ~ James Shields
8. Post-conditions top
This part is exactly how it sounds. What should happen when the use case ends?
9. Create the use case diagram top
Now that you have all the information required for the use case, you can go ahead and create the use case diagram. You can read about how to create the diagram from this post.
BONUS - Download free template top
Working in the industry for more than a decade, I worked with a group of BA mentors in developing a
general use case template that has gained a general concensus amongst the majority of the BA
community. You can download it from here.