A use case is a description that entails all the steps involved in the business process or system to help customers obtain a measurable result of value, such as a service or a product.
It, therefore, outlines the actions through which customers interact with business processes and systems, as well as business process or system requirements such as interfaces, actors, activities the actors undertake within the system, outcomes after each activity, system boundaries, raw materials, etc.
It is an effective tool for understanding how a business meets the needs of its end-users (customers). A use case can be developed for each customer need, as different customer interactions with a business process or system usually serve different objectives. Its development will often involve input from the technical staff and business customers as well. The system requirements have to be defined, as well as the actors (staff and customers), the interactions, and the end result.
A bank queue management system can be used to illustrate its use in business. Bank customers can use the queuing system for different objectives like withdrawal/deposit, account registration, mortgages, loan applications, and others. All these actions or “uses” can be developed into different use cases.
EXAMPLE
When a customer wants to deposit money, they book a ticket; then they are issued a ticket with a unique ticket number; when their number is reached, they are assigned to a bank teller, make a deposit, and the money is deposited in their account, and they are issued a receipt to mark the end of the interaction.
Use cases use non-technical language to translate what a system does and how it accomplishes set objectives. Therefore, they are used to translating the functionality of such a system to end-users and stakeholders. Additionally, they help business clients state their needs to businesses and also help with communication between businesses and IT experts such as developers and designers on what a system should do and how it should be done. This way, all stakeholders are on the same page, and the end-user of a system is able to verify if the system under development meets their needs by “testing” the system during the design stages.
As a result, a more usable system is created since end users are involved in the early stages of development, meaning they can make changes or share their input on what they expect from the system. This ensures a system’s capability to meet pre-determined objectives is determined before it is built, and resources and time are not wasted on creating an inefficient system.
These are also essential in defining system requirements and testing processes and systems in terms of requirements and user acceptance. This is because they can be used to collect customer requirements, which is an essential step in developing user-friendly and objective user interfaces such as screens, messages, and screen edits that are easy for the user to translate and verify if the translation is correct. User-oriented systems have higher user acceptance.
Use Case Templates
Writing use cases can be a time-consuming process, especially for beginners. Therefore, it is common for people to opt for templates to undertake the process. Templates contain the key sections that should appear in a standard use case and simplify the entire process by guiding users on what details to input.
A single template can be used for different projects without writing from scratch. With this in mind, we have made different professionally designed templates that can be downloaded and personalized to meet the diverse project needs available to our readers.
Key Components
A use case should incorporate all the moving parts of the business process or system described. As a result, some may have a more extensive scope than others. The described process or system must be fully functional, such that it fulfills the designers’ goal of creating a functional system and meeting the end user’s needs.
The following components must be defined for a use case to be effective:
The system
The system encompasses every element involved in producing the end result, directly or indirectly, that has to be created. The system encompasses everything within the system boundary. Therefore, a system will often include software, hardware, users, and supporting elements that ensure the success of a customer’s journey.
A well-defined system results in a well-defined project scope, which means a better understanding of the process or the system requirements, identifying project risks and appropriate actors. The project scope forms the pillar of project management, so it is always best to focus on the system and not the actors.
EXAMPLE
The bank queuing system involves the booking machine, the ticket number, and the PA system, which are the system requirements in this case.
Actors
Actors are external entities that have direct interaction with the system. Actors can be people, computers, applications, time, or other systems. Actors are the entities that prompt use case actions or steps. People actors should play a specific role in the system.
EXAMPLE
A customer who makes a purchase, a maintenance worker, a bank teller, a troubleshooting technician, etc.
Each actor should be defined by describing their roles in the system, not their job title. This implies that the actors should be defined by their interaction with the system—the activities they perform within the system. This is because actors are not specific people but rather active “players” that perform specific tasks within the system, meaning anyone can be any type of actor as long as they perform the specific role in the system that defines that actor category.
System actors include computers, other external devices that play a role in facilitating the process, or any other role players that are not people or time actors. Time actors are any entity whose function or role in the system is initiated or executed periodically after a specified timeframe. The different types of time actors are daily, weekly, or monthly initiators.
In the bank queuing system, the actors will be the customer when indicating what services to use in the ticket machine; the ticket number becomes an actor by influencing which bank teller the customer will be assigned to and prompting the PA system to announce the number once it is clear for the customer to be served and the bank teller who clears the ticket number as “served.”
Use cases
The use cases are any sequence of steps or processes that provide value to an actor. It represents how input is converted to output. As a result, it should be defined with an active verb and a noun.
EXAMPLE
Deposit money, withdraw money, apply for a loan, or open an account in the bank queuing system example used above. Therefore, one system can have multiple use cases.
Interfaces
Interfaces facilitate conservation between actors and the system. These include screens, screen edits, messages, receipts, etc. End-users use screens to communicate with automated systems such as computers. Screen edits convey support details on the screen, such as “Enter PIN” or arrange different categories of information on the screen to guide the end-user.
Messages are used to relay specific information after a function has been completed, such as “Invalid PIN. Try again” or “Processing completed.” Receipts are often used as proof of successful end-user interaction with the system. Interfaces are essential in translating what the user achieved with the system and verifying if the translation was correct before the system was executed. The interface is the ticket, PA system, ticket machine screen, and receipt in the bank queuing system.
How to Write an Effective Use Case
A comprehensive use case should define all the different users of the business process or system, describe the roles of each significant user category, and define all the different ways users can use the system to achieve predetermined goals.
The steps given below can be used to write it:
Define the purpose and scope
Firstly, the purpose and scope of the use case should be defined.
This step can be achieved by undertaking the following steps:
Describe your primary goal
Each use case is meant to fulfill an end result. This result will often define the goal of implementing the system, which in turn represents its objective. The primary goal can be written in one or two sentences.
EXAMPLE
To open a bank account or to monitor, manage, and plan customers’ entire visits to the bank, from arrival to post service.
List all the stakeholders
Next, a list of all the stakeholders in the organization that are interested in the outcome of the system (customer satisfaction) should be created. The stakeholders do not have to be directly involved in the execution of the business process or system, even though the processor system meets certain expectations of theirs. Each stakeholder should be described by indicating their name and interest. For a bank queue management system, bank directors, managers, and tellers are the stakeholders.
What is in and out of scope
Afterward, the scope of the business process or system should be defined to encapsulate all internal and external elements. The scope can be prepared using a 3-column spreadsheet that indicates any topic related to the system, In (internal) and Out (external).
The Out elements of a system are not part of the business process or system. In a bank queue management system, the internal topics would be inputting requests, allocating queue numbers, automating the PA system, and assigning numbers to tellers. External topics would be the receipt machine, printing receipts, and the PA system.
Write the steps of a use case
Once it is clear what a business process or system is expected to do and how it can achieve this, it can be written to show process or system requirements.
This can be realized by following the guide below:
Define all elements
First, each component should be defined. This can be accomplished by looking into each scenario in the system that would result in an outcome, successfully or unsuccessfully.
The following elements should be defined:
- Users: Users are the people who influence the activities associated with the flow of actions. They will often be the people who trigger the execution of a system unless it is a time actor.
- Preconditions: Preconditions are conditions or requirements that must be satisfied before the use case begins.
- The basic flow: The basic flow is the sequence of actions for each user and the system for each objective to be fulfilled.
- Alternate flows: An alternate flow is any sequence of actions beyond the normal workflow (basic flow). It will usually be a less common interaction between the user and the system.
- Exception flows: An exception flow outlines any steps preventing users from achieving their desired goal within the system.
- Post-conditions: Post-conditions are any conditions that must be met for the use case to be deemed successful, which will often have to be checked once the use case is completed.
Define the use of this process
The next step is to define the use of the system or process. This begins with listing all the business processes or system functions that define the scope of the primary use case, which is typically narrower than that of a system.
EXAMPLE
To deposit money at the seller’s counter.
Outline the normal course of events
The next step is to describe the normal process and the primary objective of the process. This step should clearly define the basic flow of the system (primary use case). Ensure to highlight the steps each user should take, the stage at which they should carry out the action, and how the business process is expected to respond to the users’ actions.
Alternate and exception flows to the primary use case should also be described, detailing actions that would hinder the normal course of events.
EXAMPLE
A customer who wants to open a bank account is served on a FIFO (First in, First out) basis, and their account is activated.
Write use cases for all other functions
Since most business processes and systems are designed to accomplish more than one objective (function), having more than one use case for a single system, business process, or device is not unusual. These should be developed for all the other functions by stating each function’s normal course of events and the associated users.
Each function should also be described by stating the contingencies for cases when the user does not achieve what they wanted and it must clearly show the specific action of the user and the corresponding response from the system. Alternate and exception flows for each function must also be described.
EXAMPLE
- Withdraw money
- Deposit funds
- Convert currency
Tips for Writing an Effective Use Case
A well-written use case can benefit a business in many ways, such as improving customer satisfaction, efficiency, and project budgeting.
To create an effective use case, below are some tips that should be considered during the writing process:
Focus on user needs
A compelling use case should be objective. It should focus on user needs and how the system responds, not the technical functions of the system.
EXAMPLE
A use case for a bank ATM process should highlight the actions taken by users and how the machine helps the users attain their goals, not how many capacitors, motherboards, or sensors are used to manufacture the machine.
Keep the use case word-based
A well-written use case should primarily be textual. Other editorial tools like charts, photos, or visual aids do not have to be included to explain how the business process or system works. However, simple flow charts are acceptable for emphasis. Additionally, it should use simple, clear language so that people without technical knowledge about the process can understand the document’s contents without further training.
Include the most relevant details
As earlier mentioned, the use case should be as objective as possible—to educate on how a business process or system works and how to use it correctly. Therefore, only relevant details should be included.
How Do Use Cases Help in Project Management
Project managers are commonly known to implement use cases in their projects. This is because it helps them in more than one way to fulfill their roles and responsibilities in a project and meet customer expectations.
Below are several key advantages of implementing a use case when managing a project:
Identify scope
It will help a project manager identify the project scope and define it objectively. It helps identify the project by setting the boundaries of the project, indicating the processes under consideration and the flow of events, identifying project actors, and linking all these to the project vision and objectives. This way, project requirements can be identified and clearly defined.
Control scope
It helps in controlling the scope of project functions. Once the primary functions and workflow have been identified and defined, any changes to the system can be assessed to determine their contribution to the end goal, which helps maintain the scope within justifiable constraints. Changes can be in terms of new users, varied needs, or new functions. New functions or users may sometimes require new use cases or additional work to be done on existing ones, depending on their influence on how the system or process works.
Risk management
Since a use case is developed at the beginning of the project, it can be an essential tool in assessing risk management. It represents all project components across the board; this enables project managers to see which component depends on the functionality of the other component and the risk posed by this dependency. Probable risks in project management are new technology, associated vendor risks, multiple actors, etc.
note
The more actors in a project, the greater the risk. They also help in identifying emergent risks as the project is underway.
HR management
A use case helps identify human actors who are stakeholders in a project, even though they are not directly involved in its execution. Their expectations and obligations can be identified and taken into consideration when developing the system or process. It also enhances communication among the stakeholders, ensuring that misunderstandings are quickly resolved, thus promoting teamwork and faster project completion. Also, through a use case, management is able to connect hidden actors and justify their involvement in the project.
Frequently Asked Questions
A use case is a document or textual description of how a system or business process works and how users interact with the system to achieve a specific objective. Conversely, a use case model uses a diagram and narrative text to describe the components of a system and illustrate how it works. A use case diagram is designed using Unified Modeling Language (UML) to show the feasible interactions between a system and the end-users and an overview of the entire system. The narrative text describes the flow of events, including pre- and post-conditions, primary process steps, alternate flows, and exception flows.
The practicality of defining a business process as a system compromises the effectiveness of use cases as modeling tools—other modeling tools like process maps, activity diagrams, and swim lanes. Use cases are word-based, whereas graphical representations may better illustrate processes and identify anomalies and ways to improve them.
Use cases in a business process can be identified using the more effective modeling tools stated above and looking for ways results in the process are achieved using current and future automated systems. Each function that produces a value is a potential use case.
UML uses notation guidelines to develop use case diagrams that are compliant with object technology. By following object technology conventions in creating a use case diagram, people from different professions, such as designers, developers, business analysts, and testers, can consistently interpret the use case diagram with minimal risk of misinterpretation. The unified process is a framework that provides standardized project phases involved in a development life cycle. These processes are inception, elaboration, construction, and transition. The Unified Process is used for developing general systems and specific objects. They can be used to define the development life cycles of a unified process.
It is recommended that a separate requirements list be developed for traceability, which forms the basis of the traceability matrix, which is a tool used to ascertain that every system requirement is contributing toward a business or process need and that each approved requirement is delivered in between and after the project.
Use cases can be altered to illustrate all the process requirements. However, it is not unusual to find out that some requirements may not be initially identified when they are used in a project, as opposed to when other models are used. Therefore, other models are worth considering, as they may be more effective in capturing these requirements than use cases. It is advisable to try out other models such as business process maps, data models, and prototyping, to ensure all requirements are identified in a project.
About This Article
