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 service or a product.
A use case, therefore, outlines the actions through which customers interact with business processes and systems as well as a 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. The development of a use case 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 the use it in business. Bank customers can use the queuing system for different objectives like withdrawal/deposit, account registration, mortgage, loan application, and other uses. All these actions or “uses” can be developed into different use cases.
For example, when a customer wants to deposit money, they book for 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 in translating the functionality of such a system to end-users and stakeholders. Additionally, they help business clients to state their needs to businesses and also helps 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 the end users are involved from 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 a higher user acceptance.
Key Components
A use case should incorporate all the moving parts of the business process or system described. As a result, some use cases may have a more extensive scope than others. The described process or system must be fully functional such that it fulfills the designers’ goal to create a functional system and meet the end users’ 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.
For 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, for example, a customer who makes a purchase, a maintenance worker, bank teller, a troubleshooting technician, etc.
Each actor should be defined by describing their roles in the system, not job title. This implies that the actors should be defined by their interaction with the system – the activity 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. A system use case represents how input is converted to an output. As a result, it should be defined with an active verb and a noun – for 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 the conservation between actors and the system. These include screen, 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 of it. The primary goal can be written in one or two sentences. For example, to open a bank account or to monitor, manage and plan customers’ entire visitations 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
Firstly, each component of the use case 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 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 following 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. For example, to deposit money at the seller’s counter.
Outline the normal course of events
The next step is describing the normal process of 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 flow to the primary use case should also be described detailing actions that would hinder the normal course of events. For 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 must clearly show the specific action of the user and the corresponding response from the system. Alternate and exception flow for each function must also be described.
For example;
- Withdraw money
- Deposit funds
- Convert currency
Use Case Templates
Writing use cases can be a time-consuming process, especially for beginners. Therefore, it is common for people to opt for use case templates to undertake the process. Use case 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 the use case from scratch. With this in mind, we have made different professionally designed use case templates that can be downloaded and personalized to meet diverse project needs available to our readers.
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 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 and not the technical functions of the system. For 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, the use case should use simple, clear language such 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 use cases help 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
A use case will help a project manager identify the project scope and define it objectively. It helps identify the scope of 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
Use cases help 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 (use cases). New functions or users may sometimes require new use cases or additional work to be done on existing use cases, 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. A use case 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 that the more the actors in a project, the greater the risk. Use cases 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 put into consideration when developing the system or process. A use case 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 to use cases 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 users interact with the system to achieve a specific objective. Conversely, a use case model uses a use case diagram and narrative text to describe the components of a system and illustrate how it works. A use case diagram is designed using Unified Modelling 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 result of 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. Use cases can be used to define the development life cycles in 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 a use case is 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.
