10.1 Why Did Use Cases Win?

When we wrote the first edition of Use Cases: Requirements in Context , it was far from obvious that use cases would become popular in capturing software requirements. As our book gained in popularity, and other use case books were subsequently written and became successful, we realized that this was a real revolution in software process. Many, many corporations have standardized on use-case-driven lifecycles. Today, it is difficult to find Fortune 1000 IT departments where use cases are not used in some form or fashion. Although we are not surprised at the fact that people find use cases useful, we have been taken aback by the surge in popularity in an industry where flash usually wins over substance.

But why did use cases win the requirements war? We feel there are several reasons:

  • Use cases are sensible to businesspeople.

  • Use cases are traceable .

  • Use cases are an excellent scoping tool.

  • Use cases don't use a special language.

  • Use cases allow us to tell stories.

  • The alternatives are awful .

10.1.1 Use Cases Are Sensible to Businesspeople

An amazing feature of use cases is that businesspeople tend to understand them fairly quickly, regardless of the businessperson's technical abilities . There are several reasons that this occurs. First, businesspeople prefer to read specifications written as sentences and paragraphs, not as diagrams or pseudocode. Although most people are visually oriented, diagrams created by technical people tend to overwhelm businesspeople. These diagrams include every possibility of a process, all the "else" sides of every possibility and all the "hardly ever happens" stuff mixed in with the basic stuff.

Use cases, by their design, tend to simplify the picture by isolating the "basic path " from all the peripheral, confusing twists and bends of a "complete" business process.

Each use case represents one business transaction. The way they are divided into separate pieces is along the lines of business thought, not technical subsystems. This makes it much easier for businesspeople to visualize each use case and its business goal.

10.1.2 Use Cases Are Traceable

We don't wish to rehash everything from Chapter 8, but we'd like to include traceability as an important benefit of use cases. Use cases are natural for businesspeople and are also natural for elaboration into technical artifacts. The stories in use cases naturally lead into the analysis, design, and testing artifacts providing an answer to the question: Are we working on what we are supposed to be working on?

Traceability, or lack of it, has been a major factor in software applications that are built, perhaps even within budget and ahead of schedule, but not matching business expectations. Use cases help solve that problem.

10.1.3 Use Cases Are an Excellent Scoping Tool

Use cases put the major focus of requirements on the boundary between what is in scope and what is out of scope. Use cases are the stories of what crosses the line between in and out. By creating this focus, they can create a clear division for scoping the project. Does this mean that every use-case-driven project has a tightly controlled scope? Unfortunately, no. But use cases are a requirements tool that help scope creep rather than hinder it.

10.1.4 Use Cases Don't Use a Special Language

Technical people who dabble with use cases usually tend to want to change them to make them, well, more technical. They want to use a language that is absolutely consistent, unambiguous, and even computer-readable. Imagine feeding the requirements of an application into a tool and out comes the code ! However, there's one hitch. Once the use cases become computer readable, they are no longer businessperson-readable. Even when certain words are capitalized ( IF the limit is reached AND the status is PREFERRED ) the use cases begin to look more like computer code than stories. Businesspeople understand stories, but not computer code. The strength of use cases is also the weakness ”English language (or Chinese, German, and so on). The vagaries and problems of our written language come with the territory if we want documents that are readable by a wide audience. Since business analysts who create use cases recognize that, they have a better chance at producing requirements that won't just sit on a shelf.

10.1.5 Use Cases Allow Us to Tell Stories

Much of the fun in life is about stories. Telling jokes, reading fiction , dating , journalism, sales, being friends , and most of the arts revolve around stories. Stories are a central part of life and culture around the world. Use cases give us an opportunity to tell stories about a new software application that does not yet exist. Is there a better way to share ideas about a future state than to tell each other stories? Stories wrap up a feeling of "being there" that no sterile list can supply.

Businesspeople can feel this. In fact, usually when we solicit requirements from businesspeople, no matter what tool we decide to use, they relay information to IT people using stories. It is very natural when we respond to them with software requirements that those requirements would also be expressed through stories.

Generally, technical people harbor some disdain for the idea of "stories" in a software lifecycle. However, businesspeople take stories very seriously. I remember a businessperson telling me the virtues of Fortune magazine over Forbes (or vice versa, I don't remember) because it had "more stories about people's successes." Businesspeople may seem to be interested in cold facts and figures, but the way they really learn is through stories.

A recent business book called The Dream Society (Jensen 2001) has this focus. It states that the businesses that will break through the cacophony of advertising and marketing to succeed will be those that have compelling stories. People can relate to the poor young boy who worked his way up from a busboy to create a great food service corporation. Or the woman who was laid off from a major corporation only to begin a thriving holistic health business. In the future, the book states, those companies with a story to tell will profit and all others will struggle. After the Information Society, he says, comes the Dream Society. The society of stories.

10.1.6 The Alternatives Are Awful

As we discussed in Chapter 1, there aren't any good alternatives to use cases, at least none that we've seen. Contract-style requirements lists are troublesome . They are readable by businesspeople but have no traceability into analysis, design, and testing artifacts. Dataflow diagrams, functional decompositions, and entity-relationship diagrams do not sit well with business stakeholders and users. They cannot relate an abstract diagram to a software application to be built. So use cases, for all their shortcomings, are currently our best alternatives.



Use Cases. Requirements in Context
Use Cases: Requirements in Context (2nd Edition)
ISBN: 0321154983
EAN: 2147483647
Year: 2002
Pages: 90

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net