tags:

views:

873

answers:

4

Is there an exact, but simple and understandable defintion of the distinction between "use case", "User Story" and "Usage Scenario"?

there are quite a bunch of explanation, but right now, I see no one that explains the differences in a single sentence, or two...

(e.g. http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison very long and hard to get, full of discussion)

+3  A: 

A User Story is a more informal, friendlier and smaller version of a Use Case, minus the UML diagram; it is typically used in iterative scenarios.

A Usage Scenario is a Use Case drawn out into a step-by-step procedure, sometimes accompanied by a flowchart.

Robert Harvey
+2  A: 

There isn't an exact definition of any of this stuff. It all varies a little bit (or a lot) from company to company and from system to system.

Your best bet is to find an example already in place for your current project and follow it.

If you are creating a new system, you can find definitions of different types of use cases for whatever system you prefer--Just pick the pattern that seems to communicate your intentions best.

Don't get hung up on names.

Bill K
> Don't get hung up on names.Don't worry, I won't! :) on the other hand, it's a quite desireable goal when in a team all members mean and understand the meaning of a word in a similar manner
Henning
I totally agree-but at a team level. I just find that a "Global" level, I've never seen two people define "Use Case" the same way.
Bill K
Not same, but on similar tendencies... and it's at least these tendencies I wanted to know and understand
Henning
+2  A: 

To me, the biggest differences between a User Story and a Use Case are:

  • A user story is a lightweight document that can be written on a card (In order to , as a , I want ). A User Story doesn't capture all the details, it's an informal support for the discussion.
  • A use case is an heavyweight document that needs a word document. It describes a "Normal Flow" of steps and/or actions and "Alternative Flows" which are detailed. A Use Case captures all the details, it's a formal specification.

According to Scott W. Ambler on Usage Scenarios, these artifacts look like a Use Case's flow:

A usage scenario, or scenario for short, describes a real-world example of how one or more people or organizations interact with a system. They describe the steps, events, and/or actions which occur during the interaction. Usage scenarios can be very detailed, indicating exactly how someone works with the user interface, or reasonably high-level describing the critical business actions but not the indicating how they’re performed.

Honestly, the differences with a Use Case's flow is not crystal clear, even after reading this paragraph (the last sentence being maybe the most important):

As you can imagine, there are several differences between use cases and scenarios. First, a use case typically refers to generic actors, such as Customer, whereas scenarios typically refer to examples of the actors such as John Smith and Sally Jones. There’s nothing stopping you from writing a generic scenario, but it’s usually better to personalize the scenarios to increase their understandability. Second, usage scenarios describe a single path of logic whereas use cases typically describe several paths (the basic course plus any appropriate alternate paths). Third, in UP-based processes use cases are often retained as official documentation whereas scenarios are often discarded after they’re no longer needed.

I may be wrong, but Usage Scenario really sounds like Use Case flow but rebranded with an Agile touch.

Pascal Thivent
A: 

I am not familiar with User Story, but when I looked into this several years ago:

A Use Case is a major task.
User Scenarios are the various ways that task can play out. So, Every Use Case has one or more scenarios. The Use Case is the abstract, the User Scenarios are a catalog of all possible instances of that abstract task.

So:
Use Case A: User authenticates with id and password.

Scenarios:
1. ID is recognized, password is correct. ("sunny day" scenario)
2. ID is recognized, password is incorrect.
3. ID is recognized, password is incorrect for third time.
4. ID is not recognized.

I have always thought of use cases as a way of defining requirements in a narrative way for the client in their terms. w/r/t the above, if the client says "But what if they try to log in in between midnight and one when the system is down?", we have discovered another scenario for the authentication task, and some additional requirements.

cvsdave