Joseph Butson

Use Case Myths

The purpose of a Use Case is very often misunderstood. Many firms have selected Use Cases to capture their business requirements. However, to them Use Cases are merely substitutes for their former business requirement documents. I call this the specification myth. The specification myth entraps the adopting firm into a new but vicious cycle of waterfall development. This cycle is where the old [the business requirements document contents] and the new [Use Case document] are joined to create a specifications document of immense page length and maximum file size!

You can always tell the development group who embrace the specification myth. They are the group with churn out the 47 page Create Customer Use Case specification with screen captures, mapping documents, business rules and everything you could think of included in the document. Everyone in the group sits near a printer and has plenty of neat looking binders to keep the paper under control, barely.

I don’t know what could be worse: writing those kinds of documents or reviewing them with the business sponsors who pay for them. The specification myth is really good at smashing the Use Case as an important element of iterative development into an unrecognizable pile of paper. It is so common that it has some firms looking for Use Case mentors to come in and get their requirements back to at least where their were before the “new” Use Case methodology was introduced.

The antidote for the specification myth is finding the essence of a business scenario. There is just no way a Use Case is more than a couple of pages long. For example, consider the universal Create Customer Use Case. A business sponsor who actually knows how a customer account is opened must not have been consulted if the result is a lengthy specification masquerading as a Use Case.

However, if you were to ask the author of the Create Customer specification how they created the document, the author is going to give you a very detailed synopsis of the intricate set steps they went though to create the document without really consulting an individual who opens accounts for the firm! The specification will contain so much extraneous information supporting the business process that the essence of the goal of the business is lost. Finding the essence is about stripping away anything but the essential steps to achieving a goal.

To get to the essence try this approach:

1. Ask for permission to observe the actual people who open accounts for the firm and do it well.

2. Request a half hour of their time and be respectful of it.

3. Ask to watch a typical account opening, not the multi-party, super-corporate, foreign-national account opening.

4. Watch the Actor [the person performing the task], ask a couple of questions and take notes [no laptops allowed!]

After a half an hour, thank that Actor for their time. Then go back to your desk and think a little bit. If you can’t reduce the account opening to less than 10 steps on about one page with this simple template, think some more and then write your Use Case. Once your are finished your draft, ask the Actor to review and correct any mistakes in the Use Case. Draw them a picture of the Use Case in context of supporting business scenarios to set a context for the business scenario Create Customer. The more feedback you receive, the better Use Case you will have but simplicity and precision is the goal.

Isn’t that easy! Seriously, your little set of steps and qualifying conditions is a robust thing of beauty and that is all there is to it. It’s all you need if you want to do what is required to produce better software.

So what is wrong with this picture and why are those clients running from the building after reading those 47 page Use Case specifications? There are some prescriptive process that can tell you how to write and Use Case and where the Use Case fits in their process. Just go to www.google.com and type “Use Case methodology” or something like that. You will find at least a 1,000,000 places to get your Use Case prescription.

But that won’t mean the analysts at your firm won’t slide into the same mistake described herein, even if they have been trained in the art of capturing business requirements with Use Cases. The expectation of what an ideal business requirement should be seems to be elusive but the typical seems to be very long documents. The specifications tend to be produced by analysts with subject matter expertise that are either not used to or unwilling to asking Actors what they really want. There is often unevaluated assumptions about what the Actor is doing.

This requirements conundrum can be a different for every project, but the cure is essentially the same simple process I have described. The important part of the process is the communication with real Actors who need a system to get the job done. The critical ingredient is an analyst open to a new way of doing things, trained in listening and facilitating and respectful of the Actor’s need for a useful system.