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.
=====================================
Now it is your turn.
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?
=====================================
You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…
START BYLINE
* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.ResourcesForBusinessAnalysts.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.
END BYLINE
