Re: Confused betwen user cases and user stories

Responding to Kong...

I am wondering if you can sort out my confusion concerning user
stories and use cases:
1. When is appropriate to develop user stories, instead of use cases?

Use cases are a form or requirements specification. They will be invariant regardless of the way the software will be developed (e.g., how one breaks up the development into increments).

A user story describes the functionality of what will be developed in a particular IID increment. To that extent it reflects design and project decisions. That may or may not map directly to a use case, depending on a variety of factors that mostly involve how the project is broken up. Thus in certain types of agile development environments where there are no formal requirements, the user stories /are/ the use cases.

2. When is appropriate to develop use cases, instead of user stories?

When there is a need to preserve the requirements beyond the initial development or there is need to provide arm's length communications among different development teams. However,...

3. Can one capture the business requirements [stakeholder requests] as
user stories, as part of the process of elaborating the business
problem domain, and then define the solution requirements with use
cases? Or for the first iteration, capture user stories, and for the
second, more detailed iteration, define use cases from the user
stories?

The content of use cases and user stories in total will be the same because both define requirements. So the differences are primarily cosmetic and scope. That is, the content of individual uses cases and user stories may not map 1:1 on an individual basis and they may be formatted differently, but the set of use cases and the set of user stories have equivalent overall content.

If one does both, then the use cases will usually be done first because they represent the customer view of the system that is independent of development. The user stories will be developed second because that involves design and project level decisions about things like allocation of resources.

3. Can one develop UML models from user stories?

Yes. The only limitations are completeness and precision of specification. Quite often user stories are inadequate because they are not rigorous enough. That's because agile processes usually provide additional mechanisms (e.g., feedback) to define requirements.

4. How do user stories fit into an RUP framework?

You should be able to use a user story anywhere you would use a use case, provided the story is complete and precise.

5. When one is capturing user stories, should one also define the
acceptance test for that user story at the same time?

That's a process issue that depends upon the particular development environment.

6. What are the limitations for user stories?

In theory, none. In practice, though, there may be issues about completeness and precision, depending on what sort of other mechanisms are available for communicating requirements. (Use cases are usually design to be standalone requirements specifications while user stories may not be.)

7. How does user stories work with requirements management tools such
as Rational RequisitePro: do you need to define special requirement
types and attributes for them?

I don't know enough about the tool to answer that. I would hope not, but it will depend on how informal the user stories are.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.