Use Cases Not All Things to All People

Author: Geri Schneider Winters

An interesting question came up in another forum, and I would like to address it here because I think it is a common one.

I am currently struggling introducing use cases into a large product development organization and a prime obstacle I am facing is that one use case should be all sort of things to different people. For Product Managers it should be dead simple focusing on high-level application functionality and scenarios (probably close to user stories), for the Developer it should be much more detailed and written with great rigor (scenarios described with activity diagrams); not to mention the Usability team who see use cases as Alan Cooper in About Face. I am wondering how to address all this. In architecture we came up with the View Points. I am wondering which way is better: (a) providing different perspectives on one use case by filtering some portion of its description, or (b) deriving more detailed use cases from one higher-level use case. Although it may lead to duplication, I intuitively bend towards solution (b). It provides better separation of concern. Any thoughts on this?

I think use cases are a wonderful tool. I have been using them, writing about them, teaching them to other people since sometime in 1996. But they are only one tool in my toolbox.

I think of it this way – a use case is not a kind of information, it is a form of information, a template, a way of structuring information. If you are describing a process, a procedure, a sequence of steps, then a use case works very well. But other forms may be better at describing your information. A use case is a poor choice for sequences with a lot of decision points (for example). In that case, I would look at activity diagrams, flow charts, or state machines to describe the information.

When choosing the form I will put my information/requirements into, I think about the information itself (as I just described), but also the people who will consume the information and what form will make it easier for them to consume it. When I was working on an embedded system with a bunch of electrical engineers, I used a lot more state charts, which I do not use at all with my IT business stakeholders. There is nothing wrong with producing the same information in different forms – user stories for the project sponsor, state machines for the engineers, for example.

While use cases started out as a way to describe telephone switching networks (see Jacobson’s early work in the 70’s for example), they have become a tool for describing user driven behavior. I have used them for embedded systems, but in that case, you really need to be careful about what is driving the system. It is very likely not a person, so the use case should be focusing on the actor/thing that is driving the process/behavior of the system. That may be hardware or another system, or even a clock.

So the answer to the question is, figure out the best form of information for each audience and create the appropriate documentation/diagrams/whatever. Just like the different Architectural Views Ponits, we have different views of requirements for different audiences, and those different views will probably not all be use cases.

What kinds of forms have you used for presenting requirements to different audiences? Do you write use cases for everything? Do you maintain different versions of the use cases for different audiences? Or do you maintain your requirements in different forms – user stories, use cases, sequence diagrams, state diagrams, flow charts – for different purposes?

This entry was posted in Tips for Business Analysts, Tips for Business Analysts and tagged , on by .

About Geri Schneider Winters

Geri Schneider Winters is the primary author of the popular Use Case book "Applying Use Cases: A Practical Guide" and the founder of Wyyzzk, Inc. She has over 25 years experience spanning the software development lifecycle. Geri has learned her craft working with folks such as Grady Booch, Jim Rumbaugh, Ivar Jacobson, Walker Royce, Scott Ambler, Warren Woodford, Philippe Kruchten, and Kendall Scott, along with many less well known, but equally talented, people. Geri has worked in many companies in many industries, including IBM, Boeing, Lockheed, Adobe, Intuit, Delta Dental, United Healthcare, Blue Cross Blue Shield, The Money Store, Charles Schwab, The Federal Reserve Bank, Visa International, USAA, Stanford University, University of California, Carnegie Mellon University, HiLCoE College, Agilent, Knights Technology, Deloitte and Touche, Safeway, and Coca-Cola Enterprises.