How to Write a Use Case

Defining the Purpose and Scope

Write a goal statement. Write a sentence or two that briefly describes the primary goal of implementing the technology or business process. Define specifically the goals of the primary user of the system. A use case can be written to describe the functionality of any business process or piece of software or technology a business uses. For example, you could write use cases about logging into a system, managing an account or creating a new order.

Identify the stakeholders. These are the people in the organization who care about the outcome of the process. They may not be users in the process described by the use case. But the system acts to satisfy their interests. List all of the stakeholders, including their names and their interest with respect to the operation of the system. Also, note any guarantees they expect from the system. For example, if you were writing a use case about how an ATM functions, the stakeholders would include the bankers and the ATM owners. They are not present when the user uses the ATM to withdraw cash. However, they must be satisfied that systems are in place to verify the amount of money in the user’s account before dispensing cash and to create a log of transactions in the event of a dispute.

Define what is in and out of scope. Specifically identify the system that is being evaluated, and leave out elements that are not part of this system. It can be useful in defining the scope of a project to create a spreadsheet containing an in/out list. Create three columns. The left column lists any topic at all that might relate to the system. The next two columns are titled In and Out. Go through the list and determine which topics are in and which are out. For example, if you were writing a use case implementing software to create purchase orders, topics that would be In would include producing reports about requests, merging requests to a purchase order, monitoring deliveries, and new and existing system software. Topics that would be Out would include creating invoices and non-software parts of the system.

Writing the Steps of a Use Case

Define the elements of the use case. All of these elements are required in every use case. Use cases accumulate scenarios. They define how a user uses a system, what happens when the system succeeds, and what happens when it fails. Each scenario describes a procedure and what happens as each step progresses. Users are all of the people who will engage in the activities described in the use case. For example, if you are writing a use case for logging into a software system, the users would be anyone who must log in. Preconditions are those elements that must be in place prior to the start of the use case. For example, users with permission to use the system have been identified and entered into the system ahead of time, so the system will recognize their usernames and passwords when entered. The basic flow is the procedure the users use to achieve the primary goal of the system and how the system responds to their actions. For example, the user inputs a username and a password, and the system allows the user in. Alternate flows explain less common actions. For example, the user is on a different computer and must answer a security question. Exception flows detail what happens when the user cannot achieve the goal. For example, the user inputs an invalid user name or password. Post conditions are those elements that must be present when the use case is completed. For example, the user can proceed to use the software.

Define how the user will use the technology or process. Each thing the user does becomes a separate use case. The scope of a use case is narrow. For example, if a company is implementing new software to create purchase orders, you could write several use cases about this. One use case might be about how users log in to the system. Another might be about how to run requisition reports. List all of the functions of the new technology or business process you are analyzing, and write a use case for each one.

Describe the normal course of events for each use case. Outline everything the user does and how the technology or process responds to those actions. In a use case about how users log into a software system, the normal course of events would state that the user enters a username and password. The software responds by verifying the user and either granting or denying access to the system. Alternate flows and exception flows are written to describe the actions when there are obstacles to the goal. If the user is denied access because the system didn’t recognize her computer, she may be prompted to verify her identity by answering a security question. If the user inputs an invalid username or password, she may be prompted to answer a security question and enter an e-mail address to receive new log in information.

Repeat the steps for all other functions and users. Write use cases for all of the other functions of the software or business process. Identify the users for each function, and write the steps for the normal course of events. Explain contingencies for when the goal cannot be achieved. For each step, explain how the system responds to the actions of the user.

Writing Valuable Use Cases

Capture what the technology or business process does. The use case explains the goal of the technology or process, not how the technology functions. In other words, a use case about logging in to software does not include how the code must be written or how the technological components are connected. It simply focuses on what the user needs to do and how the software responds. Get the level of detail right. For example, if writing a use case about implementing technology, don't exclude details about how the software responds to users. Alternatively, adding too much detail about how the software functions reads more like system design implementation than a use case.

Keep the use case primarily textual. Use cases do not need to include complex flow charts or visual diagrams that explain the process. Simple flow charts can often be used to clarify information. However, the use case should be largely word-based. The style of writing should be very simple so that others can read and comprehend it without specific training.

Learn the most relevant details. Writing a good use case helps you learn exactly how a piece of software or business process works. It educates you and the reader about the correct use of applicable vocabulary. This way, you know you are not using technological terms incorrectly or gratuitously. You can learn to discuss technology and business processes in a way that is useful and valuable to others in the business community.