User stories or use cases can be used with Building Requirements Consensus equally well. They can both be written at various levels of abstraction that can overlap. Without getting into a method war, it can be practical to think about it as follows.
On one project, a use case was a container for several finer-grained stories. We used use case notation, because it was easy with the modeling tool we had, with header text to differentiate them.
The entities were then entered into the tracking tool and named in a way that differentiated which kind a specific entity was with the USE-CASE-xxxx or USER-STORY-xxxx classifications. This approach worked out well for the project. (The developers on this project organized their work between UI developers and SERV, or service, developers. So we wrote a story of each type to track the work done by different developers as needed.)
It turns out that semantically there isn't much difference between the two. It is more about which form does the team prefer and what level of abstraction the team agrees is appropriate for the project. Both can be written with lesser or greater detail. Do what works!
This site uses primarily use cases. There are two reasons for this:
Again, either one can be use equally well with the concepts described on this site.
The quotes below come from this discussion.
I coined the term User Story, as far as I know, so I'll tell you what I had in mind.
My purpose is to maintain a balance of political power between business and development. Use cases as I have seen them used are complex and formal enough that business doesn't want to touch them. This leads to development asking all the questions and writing down all the answers and taking responsibility for the resulting corpus. Business is reduced to sitting on the other side of the table and pointing.
I want a very different dynamic. I want business to feel ownership of and take responsibility for the care and maintenance of "the requirements". I want business to feel comfortable making priority decisions about the requirements. I want business to feel free to add new requirements, and add new detail to existing requirements, as development progresses.
This requires a form of expression that is more approachable than a formalized use case. It also helps if the communication medium is something approachable, like Index Cards. So I say, "Tell me the stories of what the system will do. Write down the name of the story and a paragraph or two."
I think the difference between using nothing and using either User Story or Use Case is more important than the difference between User Story and Use Case. As long as one is used in a good way, the final product will be better than when nothing is used.
Thank you for reminding us of that. You are so correct.