Writing Effective Use Cases

 

ISBN: 0201702258

Buy this book at www.fatbrain.com

Affecting Use Cases
By Alan Zeichick

Use cases have been a staple of the object-oriented analysis and design world since the 1980s, when Ivar Jacobson took a concept he developed in the 1960s and applied it to the general requirements-gathering process. More recently, use cases were incorporated into the UML spec, with lots of stick figures to show who is doing what to

whom.

That?s both good and bad, according to Alistair Cockburn. He?s glad that management understands the value of use cases?after all, he makes part of his living teaching seminars on effective use-case writing. But it?s bad, because the UML treats use cases in a graphical manner, whereas he asserts that use cases are primarily a text-based construct, designed to tell a simple story in words, not in pictures. The UML?s use-case stick figures, circles and ellipses should evolve out of text-based use-case descriptions, he says, not the other way around.

To that end, Cockburn wrote ?Writing Effective Use Cases,? to serve both as a stand-alone resource and as the tutorial for his two-day use-case seminars. I can?t attest to its value as a text or to his skills as a teacher, but he?s certainly done a fine job of explaining how use cases can define the scope of a project, capture the actions and interests of all parties, and then present functional requirements to the programmers.

Cockburn uses several visual analogies to help describe his concept of a proper use case, and of different hierarchies of use cases. Sometimes he uses too many classification schemes, and they get in the way of clarity. In the introduction of the book, he labels very high-level summaries with a little cloud diagram, summaries with a kite, user-level goals with squiggly lines meant to represent sea level, a sub-function with a fish, and a too-granular function with a bottom-dwelling clam. Cute. Later he introduces another five-level organization scheme with white and gray houses, white and gray cubes and a screw, to show organizational, system-level and component-level development. And there?s a third scheme, based on colors: white, blue, indigo and black. Too much!

What I particularly like about this book is that it?s not theoretical in nature, it?s pragmatic, as Cockburn?s attempt to simplify matters with his various analogies demonstrates. He provides many examples of both casual use cases, ideal for a smaller development team or in-house projects, and ?fully dressed? use cases, which follow a very rigid format and which can potentially be used for contractual requirements documentation. He even shows examples of use cases written by practitioners in the field?to demonstrate that there?s a lot of latitude in the use-case format.

A particularly well-done section is toward the middle of the book, where the author gets right into the action steps that make up an effective use case. Use simple grammar, he says. Show clearly which actor is taking the action?but write from a bird?s-eye perspective, not from the vantage point of either the actor or the system. Show how the process moves forward. Demonstrate the actor?s intent, not the specific movements. Don?t become too bogged down in minutiae. Use the word ?verifies? rather than ?checks??it?s amazing the difference in understanding intent that this one word can make. And so on.

A very short chapter, only two pages long, addresses a very key element of writing use cases: determining when all of the requirements have been captured. I?ve seen situations in which nobody wants to say, ?Well, we?re done.? Cockburn neatly lays out five tests that should help all parties know when the job is complete. Nice and simple.

A lot of ?Writing Effective Use Cases? is like that. Cockburn clearly prefers a prose treatment of use cases, but if you don?t like to write prose, he shows different tabular formats for capturing the same data. If you don?t like bullet points, he shows how you can write use cases as a series of ?if-then? statements, in the outline format used by the Rational Unified Process or even in the Occum programming language. As long as the information is clearly and unambiguously presented, there?s more than one way to define requirements.

Is the book perfect? Well, no. In subtle ways, Cockburn varies what many developers will consider ?canonical? use-case terminology. It?s not always clear when what you?re reading is according to Jacobson, according to the UML specification, according to generally accepted industry usage or according to Cockburn. Does that make a difference? Not really. Just bear in mind that Cockburn?s first mission is to help businesses and developers write effective use cases, and that styles will vary from company to company. As long as you don?t view this book as a standards document, you?ll find it to be well worth the money.

Reprinted with permission of SDTimes.  Originally appeared in Issue 27, April 1, 2001.