Are use cases right for my project?

You may have heard the news that use cases help ensure your software requirements are clear and complete. That they work magic in helping you discover new questions to ask your stakeholders and find requirements gaps before it’s too late. And, what’s more, when they are combined with wireframes, they pack a powerful one-two punch of clear text requirements and powerful visuals.

But are they right for your project?

Excellent question. I’m glad you asked.

I’ve been writing use cases for years. (In fact, I have a bit of a well-documented love affair with use cases.) However, that doesn’t mean they are always an appropriate choice.Three

A use case is a type of textual requirements specification that captures how a user will interact with a solution, specifically a software solution, to achieve a specific goal. They are a very common way to create “developer ready” specifications in a format with enough context that enables business stakeholders to provide meaningful feedback.

There are three primary types of software projects in which use cases would be an appropriate technique to use.

#1 – Use Cases Can Document Existing Software Functionality

Have you ever worked with a complex system that no one seemed to completely understand? Or perhaps different people throughout the organization had bits and pieces of relevant knowledge, but no one understood the entire workflow from beginning to end?

In these situations, I’ve found a use case to be an excellent technique for capturing exactly what the system does today. Often, any documentation that does exist is technical in nature – meaning it might cover the technical design and how the system is built, but not what it actually does. Use cases are a good choice to elevate the understanding of how and what a human being does to use that system to accomplish something that’s relevant to your organization. They can make a great addition to your organization’s knowledge repository.

For example, when redesigning this website, I wrote a use case for the functionality covering “Join the Email List”. This was critical functionality that needed to be brought over into the new website. Analyzing the requirements in the use case enabled me to understand exactly how the functionality worked in the original site, helping ensure we didn’t overlook critical functionality during the migration. (This use case is now included as a work sample in our Business Analyst Template Toolkit.)

If you’ll indulge me in a little side bar here, this particular use case just happens to illustrate one of the side benefits of well-written use cases.  Since the functionality of joining the email list is the same whether you decide to join from the side bar, the home page, the bottom of this article, or the page with information on what you receive when you join, by capturing the functionality in a use case, my requirements were not dependent on the website design. I could make adjustments to the layout of the pages without needing to update the use case. And when you are dealing with big, complex systems, that’s a very nice feature to have. And it’s one reason to write use cases first, rather than annotated wireframes or dialog maps.

Because, like I did with this website, you eventually might replace one or more of your legacy systems, and the use cases you create could actually help kick start the scoping process of the new system. Let’s talk about that scenario next.

#2 – Use Cases Can Document Functionality for New Systems

Many business analyst roles involve working on new systems or IT projects. For these projects, you’ll often start with a list of business requirements, some of which are allocated to the system or software that’s in scope for the IT aspect of the project. The IT aspect of the project – or the functional requirements – can then be specified in a collection of use cases. Each feature or user goal of the system would have a use case written for it.

(You could also capture these requirements in a collection of user stories or in a software requirements specification. Your choice here is going to largely depend on your business analysis process and stakeholder needs. I tend to prefer use cases because they capture the functional requirements in context and the format itself helps ensure good analysis.)

The possible examples here are incredibly diverse. Here are a selection of use case names and descriptions from previous participants in our virtual Use Case and Wireframes course:

  • Purchase Tools from Vending Machine – Described the flow of buyers requisitioning tools from a physical vending machine, the machine dispensing the tool, and the data feed to the accounting system to account for the cost of the tool.
  • Calculate Course Fee – Described the flow and business rules for collecting training information using an employee management system, calculating the fee due to an internal trainer, and adding the appropriate compensation to the trainer’s paycheck.
  • Make a Reservation – Described the functionality for a hotel guest to make a reservation using a website. In this example, the organization was moving from using a third-party booking system to their own internal system.

As you can see with these examples, use cases can be used for websites, software applications, or even systems with a physical component like a vending machine.

But with the prevalence of off-the-shelf software today, very often your team is not building a new feature from scratch, but enhancing an existing system to meet your business needs. Use cases can still be relevant in these contexts, so let’s talk about that next.

#3 – Use Cases Can Document Enhancements to Existing Functionality

Whether you have an existing system that is built and maintained in-house or you are licensing a third-party system and customizing it to fit your needs, you can write use cases to show enhancements to functionality that already exists.

In many cases, you’ll capture the current functionality in a first draft of the use case (see #1) and then identify the changes to that functionality. I like to use color coding to call out the changes. Perhaps gray for what’s being removed, green for what’s being added, and yellow for what’s being changed.

In the case of customizing licensed or off-the-shelf software, you might document the current functionality of the software in a use case format and then color code in any configuration options, workflow variations, or enhancements you need made to the standard system. This would be particularly useful if your stakeholders don’t have a good understanding of the current system, as your use cases would serve the purpose of both training material and configuration requirements.

For example, one of our Use Case and Wireframes participants documented a “Initiate Versioning” use case which described the flow of using a workflow system to manage the flow of events related to preparing new creatives.  The information in the use case was used to identify configurations and customize the workflow management software to serve the needs of this particular business process.

Still other projects link multiple pieces of pre-existing software together. The “Join the Email List” functionality discussed in #1 is a good example of this. The functionality is enabled through a combination of the WordPress content management system, the MailChimp email software, and a bit of custom code. The use case describes how this collection of systems respond to specific user actions, such as you putting your email address in the box.

So there you have it – three project scenarios when it’s appropriate to apply use cases – to document current functionality, functionality for new systems, or enhancements to existing systems. And those three scenarios cover most IT projects.

Imagine that! Maybe my love affair is justified after all. 🙂

Learn How to Create Use Cases
(and Wireframes Too)

UseCasesWireframesInterested in learning how to write a use case? Join us for Use Cases and Wireframes – a virtual, 4-week course. You’ll learn a time-tested approach for creating a use case and associated wireframes. With the professional credit option, you can earn 8 PDs/CDUs too.

Click here to learn more about Use Cases and Wireframes

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.