PDF download Download Article PDF download Download Article

Write a use case to explore and highlight the value of your business, industry or computer system. Use cases can be valuable tools for understanding a specific system's ability to meet the needs of end users. When designing software or a system, enhance your development efforts by thinking through practical scenarios about product usefulness. Use cases can also be effective for product marketing purposes. Here are some steps to guide you through the writing process.

What to Include in a Use Case

Clarify who the primary users of the technology or process will be. Define what they want to do or how they will use the technology or process in narrow, specific terms. Describe everything the user must do and how the system will respond to their actions, including alternate and exception flows.

Part 1
Part 1 of 3:

Defining the Purpose and Scope

PDF download Download Article
  1. 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. [1]
    • For example, you could write use cases about logging into a system, managing an account or creating a new order.
  2. 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. [2]
    • 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.
    Advertisement
  3. 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.
  4. Advertisement
Part 2
Part 2 of 3:

Writing the Steps of a Use Case

PDF download Download Article
  1. 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. [3]
    • 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.
  2. 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. [4]
  3. 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. [5]
    • 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.
  4. 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. [6]
  5. Advertisement
Part 3
Part 3 of 3:

Writing Valuable Use Cases

PDF download Download Article
  1. 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. [7]
    • 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.
  2. 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. [8]
  3. 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. [9]
  4. Advertisement

Expert Q&A

Ask a Question
      Advertisement

      Tips

      Submit a Tip
      All tip submissions are carefully reviewed before being published
      Name
      Please provide your name and last initial
      Thanks for submitting a tip for review!

      About This Article

      Article Summary X

      If you need to write a use case, write a brief introduction describing the primary goals of implementing a new technology or business process. Define the preconditions that must be in place prior to the start of the use case, then detail the basic flow, or the procedure used to implement the process. Include any alternate flows, or less common scenarios that may arise, as well as exception flows, or what happens when the user can’t achieve their goal. Conclude with the post conditions, or the elements that must be present when the use case is completed. For tips from our financial reviewer on describing the users and stakeholders in your use case, read on!

      Did this summary help you?
      Thanks to all authors for creating a page that has been read 184,464 times.

      Reader Success Stories

      • Fung Suan Lim

        Dec 21, 2017

        "Very clear, step-by-step explanations for a novice!"
      Share your story

      Did this article help you?

      Advertisement