Use Cases Do Not Have Alternative Flows!

How Can This Be?

Where do alternative flows fit in UML? In the UML 2.x Specification, Chapter 16 describes use cases. It is interesting, and maybe even surprising, that the following words do not appear in Chapter 16:
- alternate
- alternative
- flow
- happy (e.g., happy path)
- main (e.g., main flow)
- path

So how did these concepts become associated with documenting a use case? The answer may surprise you.

A Use Case History

When use cases were first introduced, the primary tools available were Microsoft Word and Excel. A use case had to be documented and read in a textual format.

Sometimes a use case had complex structure because there were many ways, typically called alternative flows or alternate paths, that the use case could follow and deliver its benefit. That raised an organizational problem. How can we document all of them while making sure they are complete?

A common answer became to define one path as the anchor so to speak and branch off that one path. The one path was called some combination of happy/main plus flow/path.

Note that this designation is not due to anything inherent to the nature of a use case itself. It is simply a mechanism to handle complexity for textual requirements.

Glazed Eyes Syndrome

Suppose you had a use case with twenty different ways to deliver its benefit. (In this discussion, we leave aside the question of whether this use case is well-formed or should be split into multiple use cases.)

Various numbering schemes were attempted to add order to the discussion. They varied in their clarity.

Reviewers had a hard time reading all these alternative flows and determining if the behavior was what they wanted and if it was complete. Eventually, their eyes glazed over and the quality of the review plummeted

Some Say: I Hate Use Cases

Forced to review too many of this kind of use case, many people came to dislike, or even hate, use cases. Do you blame them?

We have consulted at organizations or departments within organizations where we could not even say use case without a strong negative reaction.

Which Path Is Most Important?

To make matters more confusing, use case gurus did not agree on how to determine which alternative flow or alternate path should be the happy/main one. Should it be the most straightforward one? Vote of BA team? The most common one? If so, by whose criterion? Absolute number? Usage of department funding the project?

It is not surprising that this question caused and still causes confusion.

The Medium Causes the Problem

Typical flowchart diagram with multiple branches that lead to the same last step - except for early exits.

Remember that the idea of a happy/main flow/path was introduced because of textual representation. See discussion on the right medium for use cases for details.

By using a tool that can handle this complexity and present use cases visually in a simulation, it is unnecessary to designate one flow/path over the others.

If you were flowcharting, you would simply have branches where they were warranted. No one branch is better than or superior to any other.

This is the way the Building Requirements Consensus™ Methodology addresses it. Any flow/path that leads to the completion of the use case and the delivery of its benefit has equal validity.

Problem Solved

It is not necessary to artificially designate one of them as happy/main. With simulation tools, we can leave this historical artifact behind.

From Alternative Flows to UC Concepts 201

From Use Case Alternative Flows to Building Requirements Consensus™ Home