A Use Case is usually used in software designing, but as a tool, it is effective for any type of management. A USE Case defines what needs to happen upon a particular action in order for that action to be completed successfully. It is important to use a USE Case because it easily outlines all that is needed for a particular process to succeed and also outlines all the people involved in it.
Table of Contents
- 1 Use Case Templates
- 2 Use Case Formats
- 3 Use Case Examples
- 4 Actors
- 5 Trigger
- 6 Preconditions
- 7 Flow
- 8 Level
- 9 Stakeholders
- 10 Use Case Diagrams
- 11 Advantages of a Use Case
- 12 Create Unique and Explanatory Names
- 13 Use Case Samples
- 14 Best Practices when writing a use case
It also helps ensure business continuity; if the original people who designed the system are no longer present, the Use Case can be easily read to understand all the thought that was involved in making a system. When designing software or any other type of project, a Use Case is used as a planning tool which ensures that the users and customers have the best experience possible.
Use Case Templates
Use Case Formats
There is no single format for use cases – there are many different types and formats which you can use depending upon the nature of your requirements. The important thing is to ensure that the use case is easily understandable. As long as your use case contains all the necessary information, it can use any of the different formats or you can even create a format of your own. You’ll find different use case templates with different designs. Some will be in the form of a table while others will be descriptive and filled with text.
None of these is wrong and none of these is right. The one that is right is the one which serves your purpose best. If you’re defining actions in technical terms, then a table is all you need. If you are writing about complex processes, then you will need a more descriptive format that explains all the nuances of the use case.
It is important to ensure that you write all the use cases in your company using a similar format. Once you have established a format, people will become used to writing in that manner. If you change formats between use cases, it will look disorganized and will be harder to understand for readers as well. Consistent formats also allow the reader to easily connect different use cases from complex processes where hundreds of use cases might be involved.
Common Sections of a Use Case
You can create a unique type of Use Case for your specific organization but there are some common terms which are used in almost all Use Case templates. Anyone who knows what is Use Case is will be easily able to grasp the whole context of an action easily as long as you ensure that all these sections are present in the Use Case.
- Use Case Name
Use Case Examples
The actors in the use case are the people or elements who are involved in the process. Let’s take a use case example to help us understand all the parts. Suppose a person generates a support request on a website for electronic products. In such a situation, the following actors are present:
A primary actor is the person who is responsible for the event for which the Use Case exists. In our example, the primary actor will be the person who generates the support request by clicking a button on the company’s website. It is important to write about the primary actor to inform the reader about who the use case caters to.
A secondary actor is a person or group of people that is needed to complete the process successfully. If someone generates a request for support on the website, they will need to be provided support by a customer support representative. This means that another person will have to get involved and that the process needs to notify them. Usually, in most companies when a customer generates a support ticket, it is directly delivered to the people who are assigned the task of helping customers. The delivery to the secondary actor, in our example, is a necessary part of the case; otherwise the customer will never receive the support that they need.
A trigger simply defines the exact action which results in the Use Case. You’ll find this section in most use case templates. In our example, the trigger is when the customer clicks the button on the website to generate a support ticket. That click is what starts the use case within the support system.
The preconditions are the conditions that need to be met to ensure that the use case can be fulfilled. If these conditions are not met then the case cannot run its course. In our example, the preconditions are that:
- The person who generates the request needs to have an active internet connection
- The website needs to be accessible by the customer
- The support agent needs to have an active internet connection
Preconditions are necessary to define. When preconditions are poorly defined, the action that is designed might not work at all or may present grave errors.
You need to define the flow of the process that starts when a use case is started. The flow needs to detail how the communication will flow, who the information will be displayed to, what they need to do, and where the primary actor will end up.
There are 3 things which you need to mention when writing the flow.
The basic flow is the best case scenario of what should happen in the use case if all the conditions are met. So in our example, the basic flow is as follows:
- The customer visits the support website
- The customer clicks the “generate support ticket button”
- The customer is taken to a page where they are told that support will be present shortly.
- The ticket is sent to the support department
- A customer support representative takes hold of the ticket
- The customer support representative is sent to the same page as the user where there is a chat box.
- The customer support representative provides the help and support to the customer
- The customer closes the chat window
- The customer support representative closes the support ticket and enters information about the session.
- The use case ends
You need to define the flow of the use case if you are designing the software or the process. The flow tells the people what needs to be done to make the use case possible.
Are there any alternate routes that the action can be done? In our use case example, the alternate flow can be that the customer asks to be contacted over the phone. Or they might request someone come to their home to help them with the product. All the possible alternate routes which can be taken to the use case need to be mentioned here.
This dictates what happens when a failure occurs in the flow. In our example, there are several ways that exceptions can occur:
- The customer loses their internet connection between the chat. They are then shown an error message.
- The customer service representative accidentally closes the chat window, ending the support session. The customer is informed that another representative will be with them shortly.
Exceptions are just as important to define as basic flow. Any good system needs to have precautions in place in the case of failure. By knowing all the exceptions, you will be easily able to define what needs to be done in such a case.
It is important to classify the use case with a level in order to explain the urgency which it needs to be dealt with. The level depends on the type of a company; a normal electronics company will classify most consumer complaints as high level while general feedback will be classified as being on a lower level. You need to ensure that whoever reads the use case realizes its importance to ensure that they give it the right amount of time.
Who are the people that are going to be affected by the use case? Any project manager will be able to tell you how important this section is in a use case template. There’s no way to write a good process if you do now know who will be affected because only when you know all the people involved will you be able to ensure that your design does everything that it needs to do. In our example, there are several stakeholders:
- The Customer Support Department – The whole department’s purpose is to ensure customer satisfaction.
- The Sales Department – If the customer is unable to get their problem fixed they might want to return the product, which will be a loss for the sales department.
Use Case Diagrams
A great way to ensure that the Use Case you write is easily decipherable is to create a diagram that defines everything involved in the use case. People are much better at visual cues than they are at reading. Just look at our use case diagram example which is based on the example we have been using:
This is a very simple diagram but one glance at it will let you know what needs to be done and who does it. You can easily add more detail based on the complexity of your own use case as well as the people involved in it. Use case diagrams, like use cases themselves, do not have a set form you can follow. There are common ways to do it, but as long as your use case diagram is easy to understand, it doesn’t matter if you deviate from the norms.
Advantages of a Use Case
If you are designing a software or a process then it is necessary to develop a good use case for everything that can happen. Use cases aren’t restricted to processes or software; they are an effective tool for any type of management. The biggest advantage of a Use Case is that it acts as a blueprint for the whole process. Once you write down a use case, anyone who comes in after you will be able to easily fix any issues that are occurring. Instead of spending time first understanding the system, they’ll be able to read the use case and directly begin checking what went wrong.
The more detailed a use case is, the easier it is to understand. Ensure that the summary of the use case defines the context of the use case properly.
Create Unique and Explanatory Names
Use Case naming is usually done based on an organization’s data standards. If your organization has already been using Use Cases, ensure that you name your Use Case using the same terminology as the other use cases. Use cases need to be searchable and they need to be easily available when needed. Some companies simply assign numerical IDs to ensure that use cases are easily indexed and maintained.
Use Case Samples
Best Practices when writing a use case
A use case is not the place to show your creativity – it needs to be meticulously researched and detailed. It also needs to be simple. When writing a use case, ensure that you include everything that is involved in the action and nothing else. A good use case will also contain a diagram, which helps the reader understand what is going on.
Make sure that all the sections of the use case have been outlined properly. If your action needs special sections to explain it properly, then feel free to add as many sections as you want. Some technical use cases have a lot of sections detailing the different technology and the different software which is involved in the use case while others are simple like the example we gave above. At the end of the day, all that is important is that the reader understands everything about that action.