Example 1: Cellular Phone Customer Use Cases
Diagram 2: Student who wishes to enroll in a course
Use Cases are created for a variety of reasons. At the start of a program's life cyle it is critical to ensure that the program being built will meet the objectives. But, what are those objectives? The customer will certainly know some of them. But, often additional objectives are discovered while developing a solution. Additionally, customers and programmers are not always good at understanding each other. They may say the same thing and actually envision very different solutions.
This document introduces the concept of a use case and provide some guidance for creating use cases that will meet the needs of both the customer and the programmer. Creating use cases provides an initial task to complete as part of your program's design. Creating use cases is intended to help you ask and answer the right questions of the customer. Some parts are intentionally less detailed at the start and can be filled in later. While other parts are critical to understand and make the good decisions from the start.
Writing use cases will help you ask the right questions and focus on the right level of detail from the start. As decisions get made, the use cases themselves help document what was decided. Such documentation helps keep all parties working toward the same solution.
Well designed and written use cases become part of a program's requirements and help communicate what those requirements are long after the discussions that let to those requirement have been forgotton.
Creating use cases with the customer helps make sure that both programmer and customer understand the program or system that will be created. By identifying who will use the program and how the program will be used to achieve their objectives, it is more likely that the correct program will be designed and built.
These are elements that are found in most use cases. They have a fairly standard defintion and use.
The person or entity that will be performing the actions described in this use case. They are the one who goals are being addressed by this use. The primary actor can be a person or a system. Their goal is to complete some task using the system.
The primary objective of the actor that this use will accomplish.
What part of the system does this use case represent.
A person or entity that will be affected by the actor succeeding in this use case. Stakeholders are usually considered as being positively affected. They are listed to ensure that their interests are not forgotten as the primary actor's goals are planned for.
A description of the actor succeeding in achieving their goal using the system.
Describe exactly who the primary actor is, what they are trying to do, and how they perform this action if the system is working properly.
This is not the use case, but when you get lost in the other details of the project, it will serve to remind you why you are writing the program and the use case in the first place.
Create a list of the known actors that will use the system. Include their primary objective or goal. Once you have such a list, you can prioritize which actors with goals will be designed for in the first, second, third, or later phases of the system development cycle.
Who are the other people and entities that are affected by the success and or changes that the system will introduce. List as many different type os stakeholders as you can and include their interest in the system. Do you need their approval, or will informing them of changes be sufficient.
List each issue that can occur that would limit or prohibit success. Do not try to solve just yet. Get the list of failures recorded first. Later, go back and assign importance and decide correct course of action should the system fail.
For each failure that may occur, decide or list possible resolutions. You may need to abort the program in the worst case, reprompt for a new filename, or display error mode message and continue with next system request.
The elements included in a use case can vary a great deal and depend upon the purpose of the use case. Here are some common additional elements that may or may not be useful and included in your use cases.
Does this use case represent a high or low level goal.
If there are conditions that must be met prior to this use case occurring, document them here. This section may also be use to indicate things that can be asserted to be true and therefore do not need to be considered further in this use case.
Decribe an event or state that causes this use case to occur. While not required, this can be useful when putting a final solution together to show how one use case leads to or triggers another use case to occur.
Extensions include operations or features that may not be needed to reach the primary goal for this actor and use case, but will benefit the system or actor in some way. For example, you may wish to outline options that will provide for more convenient use.
Secondary actors are people or things that may or may not be stakeholders, but they are involved in the use case in some way. Possibly an external vendor, or another entity that provides some resource that is needed by the primary actor in this use case. They may or may not be a primary actor in a different use case.
"Writing Effective Use Cases", by Alistair Cockburn. ©2001 Addison-Wesley
For more information and example of how Use Cases are used in industry.
Written by Deb Deppeler © 2017, based on information found online and in Alistair Cockburn's book referenced above.