Use Cases? : LUSENET : Joel on Software : One Thread

Hi, I assume that most readers of this discussion board are developers, and I seek your opinion on use cases. I'm a business analyst for a startup enterprise development company and I spec functional (behavioral) requirements with use cases. I was wondering what everyone thinks of the use case approach (how they help, how they hurt, what we could do to make them better, etc.). I know Joel stresses that specs should be readable and easy to understand. The intent of use cases is just that- to make specs "compilable" by the human brain. Any thoughts? (By the way, this is a great site... keep it up!)

-- Anonymous, December 13, 2000


If you are going to use UML you must use use cases. I think you can make a very powerful argument that UML can help develop applications that actually produce what the users want.

-- Anonymous, December 14, 2000

Use Cases

Sorry for the delayed reply.

I have lead several workshops for business analysts describing the use case approach for requirements management, and have drawn a few conclusions from those sessions:

First, use cases are helpful for managing functional requirements. It is still up to you to ensure that your requirements management process includes the non-functional requirements, while using the use cases to manage the functional requirements.

Second, there are pitfalls to using use cases, particularly if you are using them for the first time. Reading Alistair Cockburn's and Daryl Kulak's book on the topics shoudl be a pre-requisite. Or hire someone who's done it before to mentor your team. The most frequent challenge comes from use case writers that attempt to design the system by writing use cases.

Third, use cases have several audiences, and use case writers should remember that keeping them textual is important since the different audiences have different needs. Testers use them to derive test cases and test scenarios, developers use them for design, and technical writers use them to write user manuals or help lines. Focusing only on the developer audience is a common pitfall that I see teams fall into.

Please also remember that scenarios are the important things, not the use cases (scenarios realize use cases). They are what objects are to classes; they actually exist when the system runs. Scenarios bridge the boundary between analysis and design, and paying attention to identifying them and characterizing them will help you.

-- Anonymous, January 01, 2001

I guess I am kind of biased, since I wrote a book on use cases, but I encourage you to at least try them.

Getting mentorship is a great idea. What I have found is that organizations commit to trying the use case approach and end up spending a lot of time arguing over the proper approach. Who should write the use cases? Who should review them? How many iterations should we do? How big is a use case? How do use cases apply to development iterations? How do use cases drive test cases and user documentation?

With a mentor, rightly or wrongly, it seems like the organization has a place to focus and one "right" answer to each question, which is a good thing only if the person supplying the "right" answer has done this stuff a lot before.

Both books mentioned are good, I like Cockburn's book too, even though I guess it is our competitor. Other use cases books I cannot heartily recommend. BTW, I did not write the book on my own, my co- author is Eamonn Guiney. We contributed equally.

My firm, Water-Logic, does use case mentoring, among other things. We are mostly doing work in Ohio and Michigan in the U.S., but we have worked a little with companies in Silicon Valley and Dallas. We are trying to stay somewhat local just to keep travel from wearing our people out too much. However, if you are interested in getting help, you may contact us.

Daryl Kulak

-- Anonymous, February 25, 2001

Moderation questions? read the FAQ