Quick temporary note: This post needs improvements to better answer the question, such as 1) additional details should be included from references 2) some citations maybe 3) overall correctness of English 4) overall quality of narrative 5) etc. I'll be back to it. Feel free to improve it yourself.
Taking a look at their templates can give valuable insight into the differences between these terms.
There are multiple templates for use cases. I found 3 after a quick search: 1, 2, 3. Some points they (sometimes vaguely) have in common are:
- Name of use case / title
- Description - some short text describing the scope.
- Actor(s) / Primary actor - person(s) who interact with this particular use case.
- Precondition - anything that this use case can assume to be true prior to beginning it's life cycle.
- Success scenario - a sequence of step describing correct flow of events that take place.
Extensions - flow of application when it deviates from success scenario's flow:
- Alternate flows - other options of correct flow
- Exception flows - flow of events for when things go wrong
Success guarantee (aka. Post condition) - state of application after everything is done
Some additional points that can be included are Level, Minimal Guarantees, Trigger, etc.
Above is what's called fully dressed use case. You can simplify use case creation by using a casual use case by using only the most vital points, for example:
- Sequence of events
Use cases were created and popularized by Ivar Jacobson in late 80s early 90s. Later other people also contributed to his work (one of such people is Alistair Cockburn who is author of Writing Effective Use Cases). To paraphrase Martin Fowler use cases can make use of text and UML diagrams, but their greatest value lies in the text of it. They are best when they are not big and easy to read.
User story - a small story that describes a particular feature. There is a common pattern of how to write a user story, which is:
As a particular type of a user
I want to do something
so that some reason.
In addition, user story can have acceptance criterias.
As you can see this template is much smaller than that of use case. User stories are commonly associated with scrum/agile/xp region of software development. They are meant to be written on small regions of surface, such as post-it notes, and/or on scrum boards. There, they are (usually) given point values which approximate how much effort needs to be invested into that user story ref.
Bill Wake developed INVEST mnemonic to describe what qualities a good user story should have, and I will borrow Martin Fowler's short summary of that from his website:
Independent: the stories can be delivered in any order
Negotiable: the details of what's in the story are co-created by the programmers and customer during development.
Valuable: the functionality is seen as valuable by the customers or users of the software.
Estimable: the programmers can come up with a reasonable estimate for building the story
Small: stories should be built in a small amount of time, usually a matter of person-days. Certainly you should be able to build several stories within one iteration.
Testable: you should be able to write tests to verify the software for this story works correctly.
Usage scenario follow the GWT pattern which stands for Given-When-Then, like so:
Given: a particular fact
And: another particular fact (may be optional)
When: some event happens
Then: some other event happens
Usage scenarios are associated with Behavior-Driven Development. It sounds very similar to a test. Martin Fowler in his blog post gives some history and reasoning behind usage scenarios. Here is the important part:
The given part describes the state of the world before you begin the behavior you're specifying in this scenario. You can think of it as the pre-conditions to the test.
The when section is that behavior that you're specifying.
Finally the then section describes the changes you expect due to the specified behavior.
Usage scenarios can be used for writing test for your application. To quote the last paragraph of Martin's post:
Although Given-When-Then style is symptomatic to BDD, the basic idea is pretty common when writing tests or specification by example. Meszaros describes the pattern as Four-Phase Test. His four phases are Setup (Given), Exercise (When), Verify (Then) and Teardown. Bill Wake came up with the formulation as Arrange, Act, Assert.
References for farther study:
Wikipedia pages for use case, user story, usage scenario
Martin Fowler's blogs on use case, user story, usage scenario