“Keeping you up to date with everything software engineering!”

User Stories vs. Use Cases for Requirements

Requirements Engineering | October 19, 2004 | 2 comments

I have never followed XP (eXtreme Programing) professionally or in any of my personal projects but I find most if not all practices within XP can be easily integrated into any process that you presently are following. Practices that will improve your process without forcing you to totally change the way you develop your software. Remember incremental improvement is the best improvement.

Mike Cohn is the author of “User Stories Applied: For Agile Software Development” as well as the article that I am covering “Advantages of User Stories for Requirements”. In his article Mike explains what a user story is and what it consists of and then spends the rest of the article comparing and contrasting user stories with use cases and the IEEE 830 standard for requirements documentation.

“user stories, short descriptions of functionality-told from the perspective of a user”

A story consists of:

1. Card: written description (used for planning and as a reminder);
2. Conversation: conversations about the story (serves to flesh out the details of the story);
3. Confirmation: tests that convey and document details (used to determine when a story is complete).

The differences that Mike Cohn states exist between user stories and use cases are not fair observations. The author compares the common problems people make when creating use cases to the textbook implementation of user stories. I initially listed the summary of the differences between use cases and user stories but I really don’t agree with his interpretations of use cases so I removed it.

That does not mean this is a bad article. It really is a very good introduction to user stories and teaches you a lot about them. Just when you read his view of use cases take everything with a grain of salt. Even better you should take all his issues with use cases and make sure that same problem does not exist with your use cases.

I see how user stories can be very effective when you are incrementally improving a pre-existing system. When you are working with a blank canvas you need to be able to picture the whole application before you can implement one specific story/use case/feature and I am not sure user stories can satisfy that.

I think it would be very interesting to work under a XP guru on a project. Any out there who wants to take me under there wing? :-)

Anyone ever use user stories? What are your thoughts on them? What do you think about what Mike Cohn had to say in his article?

Related Links:

• Article: “Advantages of User Stories for Requirements”
• Book: “User Stories Applied: For Agile Software Development” (Amazon: Canada, US)
• Mountain Goat Software (Mike Cohn’s Company)

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

October 21, 2004 02:13 PM | Ness commented:

Use cases as this article describes them seem to describe the “How” which is not really requirements. Requirements - I always thought - where the “What” of the system.

One thing that sticks out in my mind for user stories are that users are probably wrong.

Users most often don’t understand the whole system or even the small part that you are working on. All they know is the portion of the program they use daily, even then it is often on false premises. If they do understand the domain they could leave out important details which seem trivial to them but obviously not to the program itself.

This user story idea is nice for programs that are able to be developed iterativly. But what happens when you need to develop a robot to crawl through a sewage pipe and clean blockages (yes, that’s our thesis project this year). You don’t get a second iteration if the robot doesn’t come back.

October 21, 2004 02:38 PM | John Kopanas commented:

LOL… I hate when robots take off on me like that and never come back. Reminds me of my girlfriends :-).

I don’t believe that there is any process that is good for all projects. User Stories are for applications that users interact with. Yes, users take things for granted and do leave things out but I think it is a good start. From user stories you can build a prototype and get even better feedback.

I find what is even better then user stories, at least for the project I am on now which is to move over a legacy system from an oracle forms solution to a web based solution is too watch the users use the present system and then ask them questions. Well, I could imagine that would be very helpfull to me but unfortunately we are not given that pleasure… argh…

I do have to agree with Ness. The author really does not give use cases any justice.

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)