Use cases and user scenarios

16 May 2008 - 2:31am
8 years ago
5 replies
30814 reads

Is there a concrete distinction between use cases and user scenarios?

Sachendra Yadav


16 May 2008 - 6:14am

On Friday 16 May 2008 03:31:16 Sachendra Yadav wrote:
> Is there a concrete distinction between use cases and user scenarios?

A use case is a description of how a user might use an application to complete
a specific task and can vary in the application-specific detail from
simple "pseudo-code" descriptions to click-level interaction. I've also
heard them described as the "correct answer" for a task. They are used in
software engineering as a way of describing, documenting, and testing system

Use scenarios describe the greater context of a task including the conditions,
motivation, and environment of the task for a particular user group. These
usually include all the details interaction designers need to understand what
the user is trying to do and what they need. Most developers have never
heard of a use scenario, but will adapt use cases to include this rich,
contexual user information.

I've noticed that some IxDers tend to use both cases and scenarios when they
actually mean use scenarios, usually the ones who have the most
developer-designer experience. I've noticed myself slip when I talk to
developers; since they usually aren't aware of use scenarios or the
difference between cases and scenarios, they use both interchangably. I
guess I unconciously switch my language so they know what I'm talking about.

Celeste 'seele' Paul

16 May 2008 - 7:41am
Chauncey Wilson

As a side note, there are many varieties of use cases and scenarios
with some of the types overlapping more than others. Here are some of
the types of scenarios that are described in the literature. They
vary in several dimensions including level of detail, forcus on person
versus technology or organization; descriptions of present versus
future, .....

Alternative world scenario
Organizational Scenarios
Individual task-level scenarios
Making-sense scenarios
Technology scenarios
Concept of operation
Misuse scenarios
Day-in-the-life scenarios
Normal case scenarios
Alternative case scenarios
Exception scenarios
What-if scenarios
Brief scenarios
Elaborated scenarios
Complete task scenarios

Similarly, there are different types of use cases including:

Essential use cases
Concrete use cases
Conversational use cases
(and a few more, but my memory is weak on this).


On Fri, May 16, 2008 at 3:31 AM, Sachendra Yadav <sachendra at> wrote:
> Is there a concrete distinction between use cases and user scenarios?
> --
> Sachendra Yadav
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at
> Unsubscribe ................
> List Guidelines ............
> List Help ..................

16 May 2008 - 8:22am

A use case typically includes information about how systems interact
with each other as well as how the person using the system interacts
with the system. For example, a use case might include information
about when the application interacts with a database or another

User scenarios focus on what happens from the perspective of someone
using the system, so they don't include information about
system-system interaction like use cases do.

You could think of use cases and user scenarios as coming from
different but overlapping perspectives. Use cases focus on the
system perspective and show all the system interactions, whether they
are with a person or with another system. User scenarios focus on the
user perspective. They focus on all the interactions the user has.


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new

16 May 2008 - 11:34pm
Pankaj Chawla

On 5/16/08, Sachendra Yadav <sachendra at> wrote:
> Is there a concrete distinction between use cases and user scenarios?

Here is my take on answering your question:
First the similarities:
Both are functional analysis tools and help to drill down on the
behaviour of a system vis-a-vis another system, components of the same
system and living beings. Both can have varying levels of detailing
and can be described similarly and both are created by people
responsible for defining the behaviour of the system- typically
business analysts, IxDers, architects etc.

Now to the dissimilarities:
Use cases do not qualify a user and hence take all users are entities
in the system that interact with the system. Thus every use case just
lists the behaviour
of how a user will interact with the system. Where the user scenario
differs is that it also qualifies the user by way of persona
definition and hence the user is no more an entity interacting with
the syetm but a living being with specific emotional, physical and
technology-understanding limitations that can impact her inetraction
with the system.

Just to showcase the difference between teh two using an example, lets
take an example of system that requires a Cashier interacting with the
Cash Register.

The use case will be:
1. Cashier enters the cash tendered by the Customer into the system.
2. Cash Register reports back the balance.
3. Cashier takes back the balance from the Register and gives back to Customer.
4. Cash Register prints a cash receipt.
5. Cashier gives the cash receipt to the Customer.

Now if you see the user case nowhere puts in the limitations of the
Cashier in terms of whether he is from first world or third world,
whether the Cashier or the Customer is english speaking or only
understands native language only, whether the shop where the cash
register is at a duty free airport terminal or at a grocery store in
the neighbourhood, whether the Cash Register can take credit card
payments or only cash, whether the Cash Register supports multiple
or only one currency etc etc etc.

Adding all these details is what defines a User Scenario. Do note a
very important point and that is that the User Scenario not only
creates a persona for the living being but also for the system (in the
example Cash Register also has a persona defined as to whetehr it can
take multiple currencies and credit card etc).

So in summary what differentiates a Use Case from the User Scenario is
the additional data in terms of persona creation and how that impacts
the over all behaviours of the system. Hope it makes sense.


19 May 2008 - 3:43pm
Juan Lanus

A use case is the mother of all scenarios. Said this, let's explain (it's a
bit long):

A scenario is a single instance of an operations sequence, for example "Mary
reaches the ATM, passes her card, does not remember the PIN and leaves

In another scenario Mary remembers the PIN but the ATM has no $20 bills so
she leaves enraged again.

These are failure scenarios of the implicit goal "get cash". In a success
scenario Mary reches to the gas station ATM, passes the card, enters the
PIN, selects her savings account, enters a $40 amount and leaves with the
cash in her hand.

A scenario is a description of an operation narrated by a user.

With one or more scenarios, and some background knowledge, a use case can be

It always contains a "main success scenario", in the case of the ATM it
would be the sequence of operations devoid of all specifics like "gas
station", "Mary" and $40". The main success scenario describes the steps as
if nothing could fail:

1. user: pass the card
2. ATM: ask for PIN
3. user: enter PIN
4. ATM: check card and pin
5. ATM: display account options
6. user: choose account
7. ATM: ask for amount
8. user: enter amount
9. ATM: check balance
10. ATM: dispense cash
11. ATM: show continue options
12. user: .. etc ...

Step 4 can fail: the card can be void, or the PIN be wrong, etc. Here is
where the differences between a scenario and a use case are more evident:
for the thing to ba a use case it must contain the alternate sequences of
operation that makes the system ask for the PIN 3 times and if the user
fails then swallow the card or refuse any newer interaction.
In step 9, another that has an obvious failure possibility, if the balance
is not enough the use case must describe the modified path, for example
giving the user to return to step 7 or quit.
And so on, all possible alternative paths some of them ending in success and
some ending in failure.

That's how a use case encompasses all possible scenarios.

The driving force behind use cases is that are documents understandable both
by the users and by the IT developers, its value is that they can be signed
off by both parts and be used after the development to check if the outcome
is compliant.
The detail level is variable, depending on the environment, and does not
change the use-case-ness of a document. For a device like, say, a
dishwasher, you would like to go into minute detail because after the
circuits are burned and the appliance sold it's not possible to make changes
as if it were a beta web site. On the other hand if the team is working in a
very well known domain then it's possible to safely leave out many details
as implicit.

For the use cases to be useful they must comply with a set of guidelines,
the most important are:

1. The UCs must be named after their goal, like "get cash" (an active
verb is required),
2. The "actors" must be identified (i.e.: "ATM", "user"),
3. The users must participate in the development of the UCs, and
4. The UCs must not have references to the UI nor the technology.

The "users" that must participate are not Mary and her siblings but, in this
case, as in the case of a web site, there must be a user proxy incarnated
maybe in a set of personas (synthetic users).
Notice that in the example above there are no "press button" references, the
only explicit technological nugget it the reference to the card, which can
still be considered "environment" as of today.

The UCs fall into the "requirements" category. Next step is design.
Juan Lanus
(sorry for the length)

Syndicate content Get the feed