It is easy to mix up the definitions of use case and use case scenario. A use case represents the actions that are required to enable or abandon a goal. A use case has multiple “paths” that can be taken by any user at any one time. A use case scenario is a single path through the use case. This article provides an example use case and some diagrams to help visualize the concept.
An Example Use Case
Most example use cases are very simple. Unfortunately, a simple use case does not help get a clear understanding of the differences between a use case and a use case scenario. For this article, please refer to the sample use case provided in yesterday’s article.
This use case involves 17 steps in the normal flow, and three alternate flows that represent another 10 steps. The details of each step are provided in prose in the previous article. To understand the difference between a use case and a use case scenario, we can look at visualizations of the use case, drawn as a flow chart. As a reader commented earlier today, an activity diagram would be a “better” artifact than a flow chart. This is true, but this article will use flow charts, as they require no “additional” learning for most readers. Activity diagrams can be used, if that is your preference.
Diagramming The Normal Flow
The example use case includes 17 steps in a normal flow that involves the system being developed, and three actors (two of whom are other systems). The actors are the user, the fulfillment system, and the billing system. The actions of the system being developed are represented in the “System” swim lane. You can see that control flows from the user to the system and back again, and occasionally from the system to external systems and back again.
Diagramming Alternate Flows
The alternate flows can also be diagrammed using the same approach.
Each alternate flow is drawn in this example with different colored arrows (red, green, or blue) in order to present an alternative visualization of the flow of the use case.
Simpler Visualization Of A Use Case
The essence of the diagram, for the purpose of discussing use case scenarios, is the branching behavior. You can create a much simpler diagram like the following:
The normal flow is represented as a straight line from the solid black circle to the “END” object. Each alternate flow is represented as a curved line that breaks away from the normal flow. The “3A1”, and “5A2” alternate flows return to the normal flow (bypassing one or more normal flow steps). The “5A1” alternate flow returns to a step in the middle of the 3A1 flow. The “10A1” flow has one or more steps that end in the use case being abandoned.
The colors have been added only to simplify the mapping of this diagram to the cross-functional flowchart above. If anyone knows of a formal name for this type of diagram, please add it in the comments.
Use Case Scenarios
The use case is represented graphically as the following diagram.
The diagram depicts every possible branch of the use case that might be executed in either the completion or abandonment of the goal of the use case. The use case may take any of the alternate flow branches or may follow the normal flow.
A use case scenario is a single path through the diagram.
This diagram shows the normal flow – one of the possible scenarios.
Another possible scenario would be to follow alternate flow “3A1” and otherwise follow the normal flow. The simple diagram would look like the following:
Specifically, this diagram indicates the following path as shown in the cross-functional flow chart:
Finding All Use Case Scenarios
The next step is a somewhat mechanical exercise – identifying all of the possible use case scenarios for a single use case.
The user can take alternate “3A1” or not, and then can take either “5A1” or “5A2” (in either case), or both “5A1” and “5A2”, and then can either take alternate “10A1” or not. This yields 12 distinct scenarios. You could arguably consider that taking “5A1” multiple times is a valid scenario.
Summary
A use case defines all of the paths that lead to the success of the use case. The use case also defines all of the paths that lead to the abandonment of the use case without achieving its goal. Each unique combination of those paths that can be taken by an actor during a single “pass” through the use case is a use case scenario.
Scott,
Fantastic content on the site. I just found this after hearing about it at Pragmatic’s PPM course.
One comment on this page: Pragmatic uses the term “use scenario” (not “use case scenario,” as you use here) as a means to describe a market problem that needs solving. That is, what is the user trying to accomplish, and is not able to, that creates the problem at hand?
That’s quite different from the “use case scenario” described here, which is essentially a path through a use case — which is also a useful concept, just different. It might be worth differentiating between these two concepts on the site.
Thanks again for the great content.
Brian
Thanks Brian, very much! And welcome to Tyner Blain – I hope you stick around, and keep contributing like you just did.
There are at least the following similarly named things: use scenario, user scenario, use case, use case scenario.
Cockburn, at least, defines “use(r) scenario” to mean the same thing as what I called a “use case scenario”. I intentionally included the word “case” to make sure that people didn’t confuse it with the abstract market situation that Pragmatic describes.
As you point out – I didn’t explain that very well. Now, hopefully, others will find this discussion. Thanks for pointing it out.
Scott,
I thought your post was quite insightful. I work in the cybersecurity industry. The path you described in your post is exactly what we use when we conduct our walk through exercises. For me, you are spot-on in your description.
Carlos
Thank you scott , you are super techer . But can tell me the compartive between context daigram and usecase daigram . thanks .
Thanks Yamen! A context diagram is a description of which systems (either physical or abstract) interact as part of a solution. A use case is a depiction of what is done by/with the system. Use case diagrams provide some information about how use cases are structured within a body of documentation (who uses which use cases, how was the problem structured as a set of use cases (extends, etc)). Personally, I find use case diagrams to be almost pure overhead – a mapping of actors to use cases provides almost all of the benefits, is easier to consume, and much easier to create and manage.
Thanks again!
i am new to this field, if u provide complete information abt how to convert use cases into test scenarios and scenarios to test cases with the given example “Place Order”. It is too tough to understand this use case. Normal layman cannot understand this.
please help me software project using use case diagram for student status
Thanks for providing example.
Hi Scott,
This blog is one of the most interesting I have seen explaining use cases and scenarios. The structure of the graphics is also fantastic to help with planning of test cases.
What tool do you use to produce the diagrams?
Julia.
Thanks, Julia, and welcome to Tyner Blain!
I used Microsoft Visio to create all of those diagrams. I ended up creating templates for the types of drawings I do the most, since creating them from scratch can take some time, and having a template assures a consistent delivery when producing multiple documents. Thanks again!
Hi. Can you give examples of a use case scenario, because my university teacher doesn’t know how to teach and is confusing.
Can you do an example of a use case description?
If a use case can consist of a smaller use case/s, then should that use case be a main use case?
Liked how you walked thru the process. Take away: A Use Case is a summary of Use Case Scenarios.
We have recently started adopting User scenarios in our company(never did it before). I like the concept of user scenarios but to me, its more like doing a workflow in a narrative which ties the string s togetehr and paints a cohesive picture. And I like it for that, except, I am struggling with how to document an alternate flow. So e.g. After my invoice is done, I may not have approval rights and someone else might have to approve it. How do you document that in a user scenario.
Also, I personally feel user stories are much easier since they break out chunks of work and BAs can identify the alternate flow etc.
Thanks for the information about use case and use case scenario. can u please help me know about the relationship between scenarios and use cases in a requirements document. thank you
Very good explanation. Would you say that use- case scenarios are similar to E2E, flow through or operational scenarios?
Keep up the good work!
Thanks, Hamid! Probably operational scenarios, but I guess it depends on precisely how you define both “operational scenario” and E2E & flow-through.
Hi sir tnx for the example. but my problem is how can i apply it .my teacher want me to create and search for scenario. of a ceratain company that try’ed to do a system but field . im just new to it pls provide im a student. i would appreciate your reply. tnx …….
Great examples, You can find some system specific use case example scenarios in the diagram community. There are many templates and examples to get started with.
Thanks, Shalin, and good luck with creately.com