Return to How to

“Use cases” and “user scenarios” explained

This file contains the responses I received to a message I sent on January 21, 2000 to the TECHWR-L and WINHLP-L discussion lists. It was posted on the Techwhirl website for awhile but was removed during a reorganisation of the site. Other people’s comments are included with their permission.

Here is my original message:

Can someone direct me to a plain English explanation of “use cases” and “user scenarios” as used in designing, programming and documenting software applications?

I have some superficial experience with them, but find that I can’t explain them in plain English, or at least not beyond the superficial. I’ve found some definitions on the net, but the definitions were all in techno-speak and made little sense to me. If there’s anything in the archives of either of these lists, it eluded me.

The context is: writers can use them to help build task lists from which to build online help and user guides.

But what exactly do the terms “use case” or a “user scenario” mean, and how do they fit into the software development cycle?

I saw Anthony Markatos’ comment (on a different thread), “But Use Cases are just stripped-down Data Flow Diagrams… a currently very popular book on Use Cases [is] Larry Constantine’s ‘Essential Use Cases’,” but I would prefer not to buy a book. I don’t need to know this in depth (I hope) but I do need an overview. “Just the executive summary, please!”

Any leads, preferably online ones, gratefully received!

—————-

Tim Altom:

Sure. Find a copy of Hackos/Redish “User and Task Analysis for Interface Design”. It has a fabulous and simple explanation of how to set up an entire user environment study, which is the basis of a user scenario. A user scenario, generally speaking, is a total environment within with the user operates, including the user’s attributes themselves. You might call these “user studies” or something similar. A good user scenario goes far beyond the simple controlled environment of a laboratory and takes into account whatever is in the user’s everyday environment. The book is packed with examples from Hackos’ and Redish’s corporate studies. You can search Amazon.com for it or go to our website, where we have an Amazon link direct to the book. We like it that much.

This is a gross oversimplication; you should read the book for a full explanation.

—————-

Tony Markatos responds to Tim’s comments:

That is a different ‘User Scenario’ than the original question was asking about. The question asked about Use Scenario in the context of functional analysis – specifically comparing Use(r) Scenario with Use Case.

As I (seperately) posted, in the main, a Use Case is the same as a Use(r) Scenario – they are both functional analysis techniques to specify processes (tasks) accomplished and the detailed steps within. The following quote is from an on-line Larry Constantine article (http://www.foruse.com, Select ‘Resources’, Select ‘What Do User Want’, Goto to pages 4-6.)

*****Start quote from article:

“USE(R) SCENARIO is a concrete description of a very specific interaction, but one that is chosen to be typical or representative.

Example: Ian Smith calls TechnoTech Support line at 4 am and hears the Enter Customer ID prompt. He then keys 17682002 on the telephone keybad, after which he hears the menu of TechnoTech product lines.

USE CASE is a generic scenario, describing one kind of interaction with a particular interface.

Example: Customer calls, the support line and hears the log-in prompt. Customer then keys in an ID number and hears a menu.”

*******End quote from article

Not so when talking about comparing Use Cases vs Use Scenarios (which is what the orginal question asked about.

—————-

Suzette Seveny:

I’ll give you our company’s definition of these terms:
USE CASE: A visible and identifiable system behaviour associated with one or more actors external to the system.
USE CASE SCENARIO: An elaboration of a Use Case into a precisely defined statement of system behaviour. A Scenario is represented as a Use Case plus a set of assumptions (initial conditions) plus a set of outcomes. Many Scenarios may be derived from one Use case.

Now in my words: Developers create use cases that define how the system or application works. The use case defines the Actors (users), a Brief Description (Maintain Competitor Information), and pre-conditions (Competitor must already exist on the system – refer to the use case to Add a Competitor), the main flow and any alternate and sub-flows (e.g. Search for a Competitor and Associating a Competitor with a geographical group of our stores), and any exception flows (Competitor cannot be deleted because it has stores associated with it).

The Use Case Scenarios are more detailed and from a user’s task perspective – i.e., Modify a competitor location – Success, or Delete a Competitor – Success, or Delete a Competitor – Failure. It describes in detail the exact behaviour of the application.

I use both of these in creating my documentation. A particular application will have several use cases. I make a list of each use case (including sub-flows and alternate flows) and identify who the users are. This helps me to plan out the order of the manual and identify which functions are most frequently performed, and which functions are dependant on another function being performed first.

It also helps me when I double check my documentation to make sure that I haven’t missed anything, such as an error message and what to do in those situations.

I hope some of this rambling is useful. I’ll ask around the department about any online resources.

Incidentally, most use cases and scenarios are created very early in the development cycle. Using them allows me to start the documentation even before a prototype is available for me to look at. I currently have several manuals in various stages of development. One is waiting for the prototype so that I can verify my documents against what I see, as well as grab some initial screen shots; another has the prototype developed and I am currently verifying the accuracy of the documentation and making suggestions to the developer on the GUI and the usability of the application; another is in the final stages – development was completed last week, it took me 2 days to polish up the documentation, and it goes into initial alpha test next week (application and user guide together), etc.

—————-

Thom Randolph:

This isn’t so much a synopsis of others’ writings, as it is my first-hand experiences with usage scenarios. We’ve found user-based scenarios quite helpful in our documentation. We don’t often include them inside the documentation, but we use them in the document specifications and for deciding the content. In our case, we are somewhat lucky, because the software release is based on them, which makes it much easier to choose which scenarios are appropriate.

In the normal development process, the product team does a lot of brainstorming, which yields incredibly long lists of small and large features. The Product Managers take those features and envision how the customer would use the product. These are very high level things the user would do. For example, “Send and Receive email”. There should be a usage scenario that covers every major aspect of the product feature-set.

As the estimates of development and test time are made, it becomes clear what parts of the product are going to be more difficult or time consuming. In interviews with potential customers the PMs further learn which features are most important to customers. In a magical moment of inspiration, the Product Manager declares the priorities of the usage scenarios. From those scenarios, the priority is then applied to the features. If features are a low priority based on their expected usage, they are dropped or delayed from the next release. Same goes for features that are not needed by any of the usage scenarios.

If we’re lucky, the documentation group is alerted to, and allowed to participate in the customer meetings. In them, we stay focused on what skills they are bringing to the table; what things they already know. We use that to create a “customer profile”, and we extend that profile to include special-case users. If the Marketing plan indicates that our customer profile doesn’t completely cover the target market, we can see where we need more customer interviews. Or, if the extrapolation isn’t too far-fetched, we can extend the customer profile to cover those people as well.

This is where the documentation scenarios begin. Using the high-level usage scenarios, we develop our own, much more detailed scenarios. These include specific steps the user must perform to accomplish the tasks in the high-level scenarios. Now that we know what the customer will be doing, we can extrapolate what information they will require to perform that. This isn’t limited to what we think they will or won’t know when they sit down to use the product; it’s an inventory of knowledge they will require. Whether they already have it, or gain it from our documentation isn’t really important in the scenario.

Okay. So now we’ve got a good idea of how the user will use the product; what specific things they’ll be doing based on the high-level usage scenarios. And by extension, we have a long list of the information they will need to do those things. We also have a very detailed understanding of what things the customers will already know. The things we expect them to know become our assumptions; the difference between what’s needed to perform the tasks and what they already know is the information we need to cover in the documentation.

Some of our products rely, contain, or are integrated with other large products that we sell. Because of this, we can look at the component documentation and see if some of the must-document information is already captured there. If so, that becomes material that we reference in our documentation.

The things left are those that the customer doesn’t already know, and those that are not documented elsewhere. So, we now have a list of 80-90% of the topics our documentation will need to cover. The other 10-20% will come in things we need to describe to them anyway, like product architecture, introductory material, and so on.

As the product changes, as features are added or removed, we can easily adjust the usage scenarios to cover them, and that leads directly to the documentation item lists, and then to the documentation itself. It also helps the entire product team see why particular features are so important. If feature A is cut, no one on the development or test teams might care, but the users will care because four out of ten usage scenarios are no longer possible without that feature. This also directly impacts the Marketing predictions for sales and market acceptance.

One place where usage scenarios can be directly applied to the documentation is in tutorials. Depending on the complexity of the product, we can construct core-subject, or theme-based tutorials, based on the scenarios. This can provide the reader with exposure to many of the product capabilities, since the users drive the scenarios, which drive the features, and which drive the documentation. Also, it means the tutorials will be much less contrived, and the user will be much more able to envision themselves being productive with the product. After all, the scenarios are based on what they want to do with the product.

That is how we apply “usage scenarios” to our documentation work. It has very much taken the guess-work out of deciding what’s important and what’s not. While it’s not nearly as rigorous as data-flow diagrams, I’m not convinced that it’s possible or wise to create a data-flow diagram that includes ALL the interactions of a user with a system. Data-flow diagrams are best (in my opinion) in defining how components interact, not how users accomplish tasks. It’s difficult to see the user experience from a data-flow diagram, but it’s easy to empathize with the story of a user trying to get their work done.

—————-

Tony Markatos:

A Use Case is basically a “typical end-user scenario” – differences between Use Case and User Scenario are very minor (“John Smith goes to the store” vs “An End-User goes to the store”). A Use Case is a systems analysis tool (or task analysis tool). More specifically a functional analysis tool.

One of the main principles of analysis is that it is not possible to rigorously analyze a system from all angles, at least not in the initial iterations. It would take to long. So analysts focus on the most frequent uses of the system.

[In a separate thread, Tony said:]

My all time favorite quote: “It is only by following the flow of data [using Data Flow Diagrams] that it is possible to understand the underlying logic of a system.” Tom DeMarco, ‘Structured Systems Analysis and Specifications’.

That statement is a true today as it was 25 years ago (when DeMarco wrote the book.) Many believe that DFDs are “cave-man-like” tools. A current rave (for task/function analysis) in the OO culture is Use Cases. But Use Cases are just stripped-down Data Flow Diagrams. Indeed, the primary input used to create a currently very popular book on Use Cases (Larry Constantine’s ‘Essential Use Cases’) was a book on creating essential Data Flow Diagrams (called ‘Essential Systems Analysis’ – I forgot the two author’s names).

Use Cases are merely DFDs with the interfacing data flows removed.

—————-

Marilynne Smith:

I may botch this explanation, but here is what I experienced.

Company A wants to build a new computer system that will satisfy the needs of its customers.

Company A holds meetings with customers and asks:
What tasks do you do?
How do you do this task now?
How do you think this task could be done better?
How does your task related to other tasks?
What information feeds to you?
What information do you feed to others?
What sort of processing needs to be done with your task?
Are there any reports, etc. connected to this task?
Etc.

This information is used to develop the Use Cases. Each task or sub task has a Use Case that explains what the task is, how it should function (at user level), what reports are generated, and what the relationships are to other tasks. The meetings also discuss how the new system could work. There is a lot of interchange in these meetings. They continue until the company has a good idea of what is needed. What you end up with is a kind of computer system on paper. You know what you want the system to do, but it’s all on paper, you don’t have the electronics.

System developers use the Use Cases to build a kind of tree of functions.

After holding many of these meetings and developing the Use Cases, Company A asks its developers to develop a system that will support these tasks. As they begin to develop the system, they use computer modeling to show what appears to be a working system. They ask the customers: Would this work for you?

Eventually they build the system itself.

Does this help? The Use Case development I was involved in projected an Object-Oriented environment.

—————-

Chris:

Good questions! I am on a Help project right now and have been stumped on getting this terminology straight in my head as well. I’ll try to pass along what I’ve learned:

Use Case

At least on my project, a use case is somethin a business analyst has written that defines a user action. While usually vague, these map out actions an application is being designed to handle. The use case lists what the actor should do, including:
information they’ll need
assumptions they should have to perform the action

The downside to use cases, in my opinion, is that they often get too bogged down in what the system will be doing based off the user action. This does not help when you want to create user-centered documentation, not system centered.

User Scenerio

A user scenerio is a detailed description of each user action based off the relevant use case. Example: while a use case might say a user will need to do tasks 1-3 to perform an action, a user scenerio will spell out how tasks 1-3 will be performed, based off the user interface. A user scenerio is a great way to begin planning a Help project as it really gets you thinking on where a user might get stumped on an interface.


Printer-friendly version

Last updated 19 June 2003