Use Cases for Business Analysis

You and I interact with systems every day and all day long as I create this lecture, I'm interacting with a variety of recording systems. And as you watch the lecture, you are interacting with an application or website. Well, these are all systems. And perhaps the people who designed these systems used to use cases and they probably did. Everything that we're talking about right now is what use cases are all about. A use case, simply put, is a description of how users interact with systems. We're going to spend a lot of time diving into the details, but there are three key attributes that we need to keep in mind as we go through this course. First, use cases are process driven, there are many different ways to develop use cases, but they all have one big part in common. They all describe the process undertaken by a user to achieve some goal use cases, describe that process or flow, as we call them. They describe that process in a very methodical step by step fashion. Second, use cases are goal centric, we as users interact with systems for a reason, right this moment I am interacting with the recording systems because I have a specific goal I want to accomplish. I want to record training. And you also have a goal as you interact with our website or app, you want to view training. And it's because of these goals that you and I are sitting here today. Use cases describe how users of a system use that system to get something accomplished, and this is good because it keeps us focused on solving people's problems rather than just building systems or designing processes. And third, use cases are user focused. When we use cases, we're thinking about how the experience of interacting with the system is going to be from the perspective of a user, and this helps us to build systems or processes that are user friendly and user-friendliness is very important. And if we can start thinking about that before a single line of code gets written, we're setting ourselves up for success. This all begs the question, when exactly do we create use cases? Well, in short, it's when our project has significant user system interaction and this is going to be most of the projects that immediately come to mind. But it's certainly not all of them if you have a project that is heavily data oriented. For example, there are much better ways of writing the requirements or if your writing requirements for a system that will be purchased rather than developed from scratch, I would recommend using methods other than use cases. Use cases are a really effective business analysis method, there are understood by the vast majority of stakeholders and they serve double duty both as requirements and as models, but they're not perfect. Developing use cases is a fair amount of work, sometimes you can just document these cases for a system and be done with it, but more often we create use cases in addition to traditional requirements or user stories. My advice, particularly for those boys just getting started, is to ask one question. Does the project call for some process to be put in place or for an existing process to be changed? Well, if so, start out with use cases. And if you decide later that the method is unwieldy or awkward or whatever, change to another method. So now let's start thinking up some actual use cases and we'll take a look at three different types of systems and the use cases that would make sense for them. Let's consider a consumer website and we can use Amazon as our example. You probably know it, you know, Amazon is a company that sells stuff to customers online and they also operate a marketplace where other companies can sell stuff to consumers. Well, what are some of the use cases I would envision for their website? Things like searching for a product, comparing two or more products, buying a product and returning a product, and each of these is going to sound familiar to you because you as a user, you've probably done most of them. You can see how each one of these use cases represents some kind of small goal that a user is trying to get done. Let's take another another look at another type of system, this time ERP systems. Airports are big application suites used by large enterprises to handle areas like accounting, human resources, supply chain management and a bunch of other functions, you don't need to be an expert on them. But let's look at some of the use cases that would apply and we'll use examples from the human resources models. So first one could be searching for resumes, also hiring candidate and promoting an employee. Cool again, we see how each one of these represents some goal. Well, let's do one more example, and that'll be CRM systems. CRM systems track the relationships that companies have with their customers and prospective customers. Some use cases for a CRM system might be viewing the emails sent to a prospective customer, assigning tasks to a user or creating customer reports. Great, and these, again, represent goals that are accomplished and maybe you've even done some similar work yourself. OK, to wrap, let's revisit what use cases are they are descriptions of interactions between users and systems, and we categorize them as being process driven, goal centric and user focused. Now that you have an idea of what use cases are, our next lecture is going to cover what they look like and how they're structured. And that'll be coming up next.