Use cases and user scenarios

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

-- Sachendra Yadav
sachendra.wordpress.com

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 functionality.

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
www.obso1337.org

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
Vignettes
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).

Chauncey

On Fri, May 16, 2008 at 3:31 AM, Sachendra Yadav sachendra at gmail.com wrote: Is there a concrete distinction between use cases and user scenarios? — Sachendra Yadav sachendra.wordpress.com Welcome to the Interaction Design Association (IxDA)! To post to this list . discuss at ixda.org Unsubscribe .... http://www.ixda.org/unsubscribe List Guidelines http://www.ixda.org/guidelines List Help http://www.ixda.org/help

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 application.

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.

Dann

Posted from the new ixda.org
http://www.ixda.org/discuss?post=29133

On 5/16/08, Sachendra Yadav sachendra at gmail.com 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 currencies
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.

Thanks
Pankaj

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 enraged".

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 developed.

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)

http://alistair.cockburn.us/index.php /Resources _for _writing _use _cases http://www.amazon.com/Writing -Effective -Cases -Software -Development /dp /0201702258