What is a Use Case?

Tom and Angela Hathaway
A free video tutorial from Tom and Angela Hathaway
BA-EXPERTS: Business Analysis for Anyone Wearing the BA Hat
4.3 instructor rating • 12 courses • 44,374 students

Lecture description

Discover whether our way of defining a Use Case is in line with the type of Use Case you want to learn about.

Learn more from the full course

Lean / Agile Business Analysis: Writing BUSINESS Use Cases

Enabling Stakeholders to Capture, Organize, and Communicate Functional Business Requirements for a Digital Solution

03:22:34 of on-demand video • Updated January 2020

  • Document user interaction in Lean Use Cases descriptions and diagrams
  • Define and defend the need for Lean Use Cases
  • Describe the major components of a Lean Use Case
  • Determine how to handle alternate and exception situations
  • Extract Use Cases from a Vision Statement
  • Apply Business Event Analysis to discover Lean Use Cases based on business activities
  • Analyze business scenarios to discover Lean Use Cases
English [Auto] In the context of information technology I use case is a form of communication. It explains the features and functions that a proposed software application should support. From the perspective of the business community like customer signs in a visitor creates profile and so on and such. It's a form of requirements that avoids imposing technological limits on how the software is implemented. It's first and foremost a tool for defining what the software should do not how it's going to be developed. Focus is on the use of the application. Use Cases can be and typically are documented or presented in diagrams and in textual descriptions. They represent how the actors are going to interact within with the application. In response to a request or an event more specifically the use case represents a form at some level of detail of the interactions amongst the actors that ultimately handle the initiating event. In order to achieve a desired business goal or outcome it's important to recognize the use cases ultimately have to provide value to the initiating actor the value to the visitor in the visitor creates profile use case is probably that he or she is able to access these restricted features or products and services that are not generally available to casual visitors. Visitor becomes a member more or less of an exclusive group that has access to these things. The value is an integral part of every use case description and it should motivate the actor to interact with the use case to completion. They should be able to start to use case. They should know what they're gonna get out of it and the value should motivate them to actually complete the use case. As you'll learn in the course the interactions can be depicted at a wide variety of levels of detail and with a very wide range of associated or related documentation along with it. We'll also going to address how important it is to keep the details appropriate to the to the purpose of the use case at any given point in time. As you can imagine early in the process details are going to be pretty skimpy is not going to be a whole lot of detail in the use case because you don't know a whole lot yet. The closer you get to handling this use case off to developers to actually implement the more detailed and specific. The description has to get in order for them to be able to do their job. So the levels of details are kind of a moving target and that's actually one of the areas that lean is going to play a huge role. Properly used the use case in the end not only serves the developers and the business community and communicating. It also provides the basis for acceptance testing to ensure that the developed software or implemented software in the end performs as the author of the use case intended. So more specifically key elements to think about or the key things to remember when you're thinking about a use case. First and foremost a use case has to be triggered by an external event of some kind or a request somebody has to say something do something or something has to happen before the use case can start. Because of that we're going to spend some time in the course talking about event analysis how to identify events that will trigger use cases. It's also very very important to recognize that the use case has to provide a value to one or more actors. Typically the initiating actor is going to get the most value out of the use case although that's not entirely always true. That's just the most common component. It shows the interaction between actors which may by the way be people or technology actually. An actor can be a person a device or another application an API in the world of the web and it can be a crude or proposed application or interaction but it's going to. Its purpose is going to be to handle the event in the manner that the business community dictates as appropriate. It actually shows the sequence of functional steps that are going to take place or we've got talk about in the use case parlance it is the course of events that has to happen in order to handle the event or the request from when it is received until the desired business outcome has been achieved. So it contains functional requirements and it contains business rules on how we want this application to really handle the situation. Key to it is it is only defining what we call the externally observable behavior of the application it doesn't get into what the software does specifically. It just says it's going to do things like display to the visitor to display the profile screen. It's going to process a user profile or update the user profile. It's actually a because we're talking always about interaction. Key thing about it again is the use case is a dialogue between actors human and technology because we've talked about what a use case is a lean use case fundamentally it is a use case that is at the appropriate level of detail that will support imminent decisions meaning it is detailed enough for whoever is reading or evaluating the use case to be able to make the decision. They need to make at this point in time so we don't want to try to get the use case fleshed out in all of its full blown glory at the beginning of the project because ultimately this use case may never get into production. Its purpose at this point at each point in the end the process is to foster communication amongst the diverse audiences that need to understand what the use case is going to be doing here. These are the various stakeholders within your organization. Key to the lean use case is making sure that it is at the appropriate level of detail for the person who needs to make a decision at this point at any given point in time.