IT organizations continually struggle to assure that developed software meets its specified requirements. But how can these requirements be discovered, captured, and communicated most effectively? With the advent of use cases six years ago, a solution seemed close at hand. Although use cases have been assimilated into the authoritative Unified Modeling Language (UML), many organizations are finding that their promise is elusive. While use cases were intended to be simple and straightforward, many IT organizations are finding that identifying and gathering project requirements through use cases is painful, that they are difficult to manage, and difficult to understand.

In this paper I want to share a small set of common characteristics shared by projects which successfully employ use cases. These characteristics are a brief preview of the presentations which I will be making with Bill Nazzaro of MCI Systemhouse at the Software Development '99 conference in San Francisco on May 12th. These ideas come from our combined experiences, and this paper is a collaborative effort by Bill and me. We assume that you have a basic knowledge of what a use case is supposed to be, and hopefully you have written—or have tried to write—a few.

According to Rational™ Software Corporation, a use case "defines a sequence of actions performed by a system that yields an observable result of value to an actor." This is a good starting point. First, it says that an actor—a user of the system—is the judge and motivator of the value the system provides.

Second, it says that the system provides value to an actor in a sequence of actions, i.e. in a transactional metaphor. Actor requests, and system responds. Or, system requests and actor responds. A use case is not terribly useful when there is no dialog between the actor and the system.

Lastly, the value of the use case is observable because a use case has a result—a goal. It might be a goal of the corporation, or of the business model being described, or a goal of the actor who just needs to get some work done. Unfortunately, very little is written on the goal-oriented aspects of use cases, and this will be a topic of a later paper.

Killing A Project With Use Cases

There are many ways to help kill a project with use cases. A few that we will mention without much comment now are:

• Expecting use cases to capture all your requirements.
  (They don't; they just capture functional requirements and enforce business rules.)
• Emphasizing notation over business goals and content.
  (The use case diagram is like a Table of Contents; it is not the book itself.)
• Designing inside use cases.
  (Use cases are not part of the design process and should not discuss technology issues; use cases are a way to capture the requirements so you can then do analysis and design.)
• Coding from Use Cases.
  (They are not part of the design process; they are a way to capture the requirements so you can do analysis and design and then implementation.)
• Trying to use all the defined notations just because they are defined.
  (Just because UML 1.3 introduces generalization between use cases, are you going to look for ways to use it?)
• Identifying system functions as use cases.
  (Yes, system functions e.g., validateAccount, are important; but a use case describes a business process and business goal, and the system functions which will be used to achieve that goal will be determined in design, not requirements capture.)

If you have been involved with use cases on a project of any size at all, you may have experienced some of these symptoms. But we want to be more upbeat and take a positive approach. So let's talk about what you can do right to raise your chances of success with use cases.

The Right Stuff

To capture requirements successfully with use cases, you must not confuse use cases with code, or design, or any other part of the software development lifecycle. My most recent visit to Rational's UML Caf?(http://cafe.rational.com/HyperNews/get/hn/umlcafe.html), amazed me a how many persons fall into this confusion. To succeed with use cases we have found that how you think about the process of capturing requirements is even more important than what you do in that process.

Staff For Skillsets, Not Job Positions

You need people who have the right skillsets, not just people who are "available". To do use cases successfully you need:

• Subject Matter Experts (SMEs), and
• Analysts.

The SMEs are resources who provide raw material for the business content of the use case description. They are the ones who absolutely should understand the business as-is, but much more importantly, are willing to define the system to-be.

The analysts facilitate the use case development and mentor the SMEs, but it is the analysts who analyze and write the use cases—period. The analysts must be able to think abstractly and have a high tolerance for incompleteness. The analysts need to thoroughly understand the process and goals of use case development. They also must be comfortable with intentionally circumventing the process so they can achieve the goal of developing use cases.

Don't Let Developers Write Use Cases!

Now that we have your attention, let me explain. By "developer" we mean that person who is a linear thinker: one who starts at point A, and proceeds one by one through intermediate steps to arrive at point Z. The linear thinker cannot comfortably jump around within the use case description process. Some persons are linear thinkers by nature—they were born with this skill—and some by nurture—they have been trained this way. Some persons adopt a strongly linear approach to solving a problem if they are uncomfortable with the solution process, so they fall into doing the rote mechanics. Some don't understand the goal to be achieved—i.e., they do not have a vision of the end result—and become retentive about rigidly following a prescribed set of steps because they mistake making the journey for reaching the goal. However they come to this unique skill, linear thinkers are invariably uncomfortable when there are holes in what they are doing.

Use cases are text: i.e., prose. They are not derived like theorems—they are composed. This is why linear thinking is a decided liability in use case development. Writing a use case has nothing in common with writing code or writing a Fault Isolation manual for a Field Engineer. A use case is closer in style to writing a short story than writing a technical specification, and for this reason linear thinking developers will not be successful at writing them. Use cases often grow in fits and starts, almost organically until they express their goal. They are not technical documents, so don't let your technical people be the ones to write them. Various instances of "The World's Worst Use Case" float around the OO community: some of them are textual flowcharts, some are pseudo-code replete with IF…ENDIF statements. This is not how to succeed with use cases.

Now, realistically, some very technical people are also very good at written expression, and some business people cannot speak in complete sentences. To succeed with use cases they must be written well, by people who have the skills to accurately express the interplay between the system and its actors.

Bill and I have spent a lot of time pulling groups out of quagmires of use cases written by people who cannot write a simple narrative describing "What I Did on my Summer Vacation". They were, however, very competent and skilled in other areas. The problem is that they were assigned to write use cases and this was not one of their areas of expertise.

One of the best use case writers I have found is a woman who was a banker. She was very business savvy, and not at all technical. We spent three 2-hour sessions together developing some use cases for an electronic commerce system. At the end of these sessions the light came on for her, and she became a true-believer. She applied her new knowledge with her excellent writing skills and immediately produced a complete set of use case requirements for a new system. They were wonderful: not one word of technology, just clearly articulated business process.

In use case development our total focus is on what work the system must do for the user, not how the work will be done. Bill and I were involved in a project where part of a use case involved producing a Bill of Materials for a transportation system. A developer (actually a pretty decent C++ coder) spent a significant amount of energy trying to interject into the discussion that whether the Bill of Materials was electronic or hardcopy entailed separate use case descriptions. He just could not rise to a higher level of abstraction and see that the important system service was that a Bill of Materials (a concept, not implementation) be produced, and that its manifestation as a view on a window or as a printed report was not at all significant in the conceptual modeling of a use case.

Bill uses a wonderful analogy to capture this cognitive opaqeness. Have you seen the stereograms that are sometimes called "Hidden Pictures"? Until you know how to view them they look like random jumbles of color-dots. When you can let your eyes drift just the right amount, however, a 3-dimensional picture suddenly leaps into your perception. But some people just cannot see the hidden picture. No matter how long someone tells them the secret, they just can't see it, and some never will. That's just the way it is with linear thinkers: some will just never be able to think abstractly, and will never be able to produce useful use cases.

The bottom line: choose your use case writers very, very wisely. They are not technical documents, so why would you have technical thinkers doing them?

Think High-Level…Business Level

Bad use cases describe isolated system functions that seem useful from a technical perspective. A good use case represents an identifiable business transaction that has business value from the end-user’s perspective. In other words, a use case must provide a meaningful result of measurable value to the end-user. Use cases that only deal with a low-level, elementary process (e.g., Retrieve Reservation or Update Reservation) are likely to be too simple, and are invariably modeled on the technical CRUD- functions of a relational database management system: Create, Retrieve, Update and Delete. Typically a use case will include the series of steps the actor must go through and require significant business policies and rules to implement. But a good use case does not itself describe design, performance, or implementation issues. A good use case does not describe the relationships between subsystems. A good use case does describe how the system to-be carries out the work that the actor needs done to accomplish his/her business goals.

A use case "Manage Reservation" would include the following: entering the reservation details, locating the customer (establishing the customer if necessary), determining applicable discounts, calculating the bedroom rate, and storing reservation details. The use case "Manage Reservation" could also include updating the reservation, as well as canceling the reservation.

Follow a Process—Loosely

Use case development is not like building a model airplane: just putting known pieces into the proper place. It is a discovery process. It is a process of defining that which does not yet exist, and which may not yet be understood. It is depressing to Bill and me how often we enter an engagement and find that a project team have read books on use cases, have selected use case description templates, and have written perhaps dozens of use cases—yet do not understand any of the dynamics of the process for developing the use case descriptions. Some will have taken expensive courses on Requirements Gathering with Use Cases, or some similar title in which they learn about <<include>>, <<extend>> and generalization relationships. But they don't understand how to "compose" a use case iteratively, in pieces, often in fits and starts.

The basic use case description process is rather simple. For each candidate use case in your system-to-be:

1. First, articulate the goal of the use case.
2. Second, produce an outline use case description focusing on the "Happy Path". The "happy path" is that sequence of steps where everything works perfectly (so we don't have to worry about exceptions and errors yet) and the goal of the use case is achieved.
3. Next, construct a simple use case description framework to think about the happy path. This framework lets us write an accurate, but non-detailed, use case description. At this point our description is analogous to a pen and ink drawing: it conveys the overall form and structure of the use case but without any "color" yet.
4. Fourth, flesh-out the use case description framework with more business-process detail for the happy path (but not technology detail!). This is equivalent to filling-in our pen and ink drawing with oil colors. Now our use case description has depth and personality.

What is not simple is that although this use case description process is written as a time-sequence of steps, you do not want to be linear here—especially within steps 3 and 4. Detail does not flow in an orderly fashion from top to bottom. This is a dynamic detective and discovery process, and the single most unique characteristic of developing use case descriptions is that your approach must be opportunistic rather than deterministic, lateral rather than linear. We hunt and scrounge for any piece of relevant information and do not care whether we find it in the "right order". A deterministic thinker wants to build a jigsaw puzzle from top left to bottom right. An opportunistic thinker will look for patterns and first will put together small groups of pieces (perhaps arranged by color or edge shape) and then will build the puzzle from these groupings in what seems a haphazard fashion. (It is also interesting that the opportunistic approach will complete the puzzle sooner than the deterministic approach! We can prove this using Sorting theory.)

It is this pseudo-random, opportunistic approach that is absolutely central to developing use cases successfully. It is a pseudo-random approach because an experienced use case facilitator will always have an appreciation for what remains to be done, and knows just what he or she wants from the use case under development. It is also an approach that drives linear thinkers over the brink, and makes them dig in their heels, trying to bring "order" to the process. Alas, it is this "order" which too often results in missed and misunderstood requirements.

Conclusion

There is so much more that we could add to this, but our goal is share a few proven ideas to help you become more successful with use cases. And we will be adding more ideas in the near future. The promise of use cases is real and they can be a tremendous vehicle and catalyst for identifying and capturing functional requirements. We will share other ideas about this area through White Papers on my website. Personally, I really don't like doing use cases. I prefer analysis and design activities, with some fun coding thrown in. The problem Bill and I continually run into, however, is that we seldom get good use cases, use cases that we can use as a springboard into analysis and identifying the classes in my system-to-be.  So, we usually end up writing, or severely rewriting, the use cases on my projects. It's not a perfect world, is it?