If you’re writing software or functional requirements and you are not leveraging use case thinking skills then you are missing requirements.
And missed requirements cause unnecessary rework on software development projects.
While use cases aren’t always the best business analysis technique, they are a perfect choice more often than not. And in this video I share the 3 situations in which they are absolutely the perfect tool for your work as a business analyst.
Download the Use Case Template
You can download our Use Case Template for FREE. 
The best part is that when you learn to analyze requirements in use cases, you can look like the smartest person in the room by avoiding these common challenges:
- Validating that the use case reflects true end user needs.
- Describing system and user steps at the right level of detail.
- Ensuring your software requirements are clear and complete.
>> DOWNLOAD FREE USE CASE TEMPLATE <<
For those who like to read instead of watch, here’s the full text of the video:
This is Laura Brandenburg from Bridging the Gap. Today, I want to talk about when to write a use case. Because I love use cases. Not everyone does, but they are a useful analysis tool and I can guarantee you, if you’re writing software of functional requirements today, and you’re not at least thinking in use cases, you are missing requirements.
What are the scenarios that we need to be either writing a use case, or making sure we’re thinking strongly in use cases?
Use Cases Defined
First, let’s talk about what a use case is.
A use case is a textual document that outlines the system functionality in the context of user actions.
Think of it like ping pong. A user does this, the software system does this. A user does this, the software system does this. Back and forth, back and forth until a goal is accomplished for that user.
That goal is pretty discreet. It’s something that a software system can do. Not like “better life” or “improve your process”.
Goals like:
- Find customer
- Generate report
- Deliver document.
Something very specific, very concrete that the software can do.
That’s what you’re documenting in a use case. You’re getting specific about the software functionality and the sense of what software functionality is visible to a user, not what’s happening underneath the hood, not how the technology is designed, but what does the user experience with that software.
If you aren’t familiar with use cases, here’s my deep dive tutorial on how to write a use case, step by step:
What are the situations when we’re documenting functional or software requirements like that where we would use a use case?
#1 – Utilizing Use Cases to Document Existing System Functionality
The first one that comes to mind is when we’re documenting functionality of an existing system. Systems tend to grow up and they get messy and complicated.
One of the jobs I was in, they had a document delivery system that had been in place for 10 or 15 years before I started there as the business analyst, and they never did full testing or requirements or analysis of what they were building, and they just kind of kept adding on pieces. Software systems have this, especially legacy ones like that, get to the point where you’re duck taping pieces together to make things work.
It seemed like every time we went to enhance that system, or add on to that system, or introduce a new capability, something over here would break, and we wouldn’t know why because it was challenging to do the analysis about how that system worked because we didn’t have a full set of documentation about how that system worked.
One of the things I took it upon myself to do is to go and start to work with a developer and the business sponsor to understand the capabilities of the system and the logic that was happening behind the scenes, not in terms of the technical, how is it built, but things were getting routed in very specific ways and flowing through the system. I did this so that we could start to see the big picture of how that system actually worked so when we were analyzing requirements to add on and enhance that system. We could better gauge the impact that we were going to make and look at the impacts of new requirements on that full system instead of just the piece we were focused on improving.
It ended up adding a lot of value and made that system, even though it was still difficult to maintain, easier to update and improve upon, and definitely easier for new business stakeholders who were getting involved in the business to understand the scope of what it did and think through the implications of the requests and the requirements.
Use cases are great tools to analyze existing functionality.
#2 – Document Functionality for New Systems in Use Cases
The next thing to think about is functionality for new systems. Say we were going to replace that system. We would need a new set of use cases that define the requirements and capabilities and the user actions that could be supported in that new system.
Sometimes, today, we are using COTS systems and SaaS systems – Commercial Off The Shelf and Software As A Service Systems – are definitely getting much more prevalent, but there are still cases where we’re building custom code existing systems from the ground up inside our organizations.
In that case, every single feature that you want to build, and that you’re building from scratch, every user goal needs to have a use case defining what those requirements are. That’s what your developers can use to build from and your testers can use to test from, and your business stakeholders can use to wrap their mind around what the system that doesn’t exist yet is going to do from them, and how does it fit into their business process. That’s a big part of it. It needs to go together.
Use case is much more defined and discreet than the business process itself. That’s the second time is when you’re creating a new system from scratch. Definitely want to be analyzing that and thinking through that in use cases.
#3 – Specify Updates to Existing Systems in Use Cases
The final case is what if you’re updating an existing system? A lot of us have existing systems today and we’re making those little tweaks like I talked about in the first scenario. Let’s just update that and add this here, and add this here. It’s a great opportunity to also create a use case, especially if you don’t, if you can combine where you’re analyzing what exists today and what’s the incremental change that we’re making to what exists today.
This helps you think through that impact of all the places that requirement might affect until you put into a use case or thinking, oh, we’re just adding this little field to this page. And then you put a use case around the goal associated with that, and any related goals, and you start to see, oh, added that field affects this thing over here, and it affects this report over here. It helps you start to think through some of those implications.
When you’re updating that functionality, one tip of what I like to do, I like to color code my use case so that the current state functionality is represented just in general black/white documentation and then color code enhancements or the changes so that it’s clear what we’re changing, what we’re retiring, what we’re adding on to, and that can make it easy to break that apart into specific design tasks for user stories, if you’re using user stories to implement your requirements, or to manage your software development process.
Yes, agile software development teams can most certainly benefit from use cases! Here is what Dave Gallant had to say about applying use cases and user stories on an agile team.
Bonus – Design Customizations and Configurations of COTS/SAAS Systems in Use Cases
Related to this enhancing new functionality, a lot of us, today, aren’t actually enhancing the functionality in our company systems; we’re enhancing the functionality of systems that we’ve licensed or bought from third party vendors. That would be the COTS or the SAS system like I talked about before.
You can still use use cases, then, to talk about what those customizations would be, or even like an area that’s going to be heavily configured, you can think of that as an addition to existing functionality. Maybe out of the box the system does one thing and you can configure all of these different ways. It’s mind-bending, I think, to try to jump into what are all the configurations we want out of the box solution.
It’s difficult for a business stakeholder to think what all the configurations are I want. I don’t know. I know when I sit down, and I use the screen I want it to look like this. I know when I go from here, to here, to here, to here, these are the things I need to accomplish. Putting that functionality together in a use case, as opposed to a list of configuration options, can be useful as a way to walk through what that system will be like once those configurations are made, or once any enhancements and customizations are made as well.
Jami Moore did this for an area of functionality on a Salesforce project, and look at the feedback she received:
Use Cases – a Beautiful Way to Get to the Functional Requirements
There are just three scenarios to be thinking about applying use cases in your projects. Again, they’re focused on the functional or the software requirements. The software that’s delivering value to your business users. Use case is a great tool that business users with a little bit of training and walk through can understand and dig their teeth into to understand what the software is going to do from them, and then your technical stakeholders can use to design and build the system, and your testers can use to generate all kinds of test cases. The test cases almost just like fall out of the use cases. It’s kind of a beautiful process.
Be thinking about where you could be using use cases in your environment. What are the tricky project challenges? That functional requirements list just isn’t working for you anymore. I hope this helps you think about where you might introduce my favorite requirements tool, the use case, into your business analysis process.
Again, I’m Laura Brandenburg, from Bridging the Gap. We help business analysts start their careers. Thanks for watching. Thanks for learning more about use cases.
Download Your Use Case Template Today
Get everyone on the same page about software requirements with use cases. Download our (completely free) Use Case Template today.
We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.
Use Cases Are One Way to Analyze the Functional Requirements
Discover how use cases are just one type of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation.
Use Cases vs. User Stories
Another frequently asked question is what’s the difference between use cases and user stories – be sure to check out this video next to understand why even if you are writing user stories for your software development team, you’ll still benefit from analyzing your requirements using use case thinking.