There’s an adage the a “classic” novel is one that everyone admires, but that no one has actually read. Were one simply adventurous enough to approach the subject matter, one would relish the simplicity and joy the experience would bring.

Use cases, to a Business Analyst, are perhaps the most “classical” of tools. Use cases, like classic novels, are held in the highest regard, but rarely understood or properly executed upon.

In this article, we will look at a simple historical event, and deconstruct it into a simple use case. Given a known approachable context, the perceived complexities of a use case are quickly demystified.

From Anna Karenina, a classic historic novel, to Paul Revere’s ride, a classic historic use case, the truth is that the classics are not as intimidating as they might first appear.

Let’s start by defining a use case, looking at its constituent parts, and then taking Paul Revere’s midnight ride and see how a known scenario from our nation’s history can be represented as a use case in the classical sense.

A use case is a detailed description of a user’s interaction with a system.

That’s it. It’s pretty simple; somewhat general, rather vague. That’s the way it should be. A use case really amounts to nothing more than plain old “documentation.” It can be applied to a business process, a complex software system, your morning routine, a wedding ceremony, or a historical event. The only requirements are an “actor” and an object to be acted upon.

A brief word about “actors.” You will hear the term actor with some frequency. It is a core term to the Rational Unified Process (RUP). There are a lot of terms specific to RUP and other established processes and methodologies. RUP is a great methodology. Many great minds were involved in its creation and design. But RUP is also complex. RUP can sometimes cause people to avoid use cases. The intent of this article is to encourage analysts that might not have considered using use cases to go ahead and do so. Don’t let words like RUP, SDLC, methodology, process, and use case throw you off. The thing that has made RUP so successful is its dependencies on core fundamentals based on common sense. So if you hear actor, feel free to replace the word in your own vernacular: Actor, user, analyst, person… whatever you want to call them. There is no right or wrong. The only right process and methodology to use is the one that is right for you and for your environment.

A use case consists of seven components: Name, Description, Pre-Conditions, Scenario, Results, Alternate Paths, Additional Business Rules. Let’s define them:

• Name

The name is the identifier for the use case in question. It should be represented in the form of an action.

“Throwing a Baseball”

• Description

The description expands on the name and provides additional detail regarding the actor and system’s interaction.

“This use case discusses the mechanics involved in the throwing of a baseball from one actor to a designated target. This use case does not include a discussion regarding the pitching of a baseball (a more specific variation of throwing a baseball), nor does it cover the mechanics or interactions required in the catching of a baseball. Those use cases are documented separately elsewhere.”

• Actors

Actors are the individuals who will interact with the system.

“Thrower.
Catcher (optional)”

• Pre-Conditions

Pre-conditions are criteria that must first be met prior to the execution of the scenario. Pre-conditions can be the successful execution of other use cases, or they can be assumptions.

“A baseball is required for the execution of this use case.
Another actor or a pre-defined stationary target is also required.”

• Scenario

The scenario is the anticipated series of actions and responses. Depending on the complexity of the use case, the scenario may be as simple as a couple of lines, or span several pages.

“Thrower throws the baseball.
Catcher catches the baseball.”

Length should be taken into consideration. If a use case is overly long, you may want to consider a means of dissecting the scenario into separate use cases. For example, you probably wouldn’t want a use case for “Playing a Baseball Game.” 

• Result

The result is the final result of the actor system interaction and reflects the successful completion of the use case.

“The catcher now holds the baseball and becomes the thrower.
The thrower becomes the catcher.”

• Alternate Paths

The alternate paths are variations on the anticipated scenario and represent failures of the system interaction.

“The catcher drops the ball.
The thrower fails to throw the ball the entire distance to the catcher.”

• Additional Business Rules

Business rules are rules that govern the use case. They should be presented within the scenario or within the alternate paths where they are contextually relevant. The Additional Business Rules section is the place to list additional business rules that govern the entire use case and do not have a location for inclusion within the context.

“Baseball gloves (while the greatly increase the chance of successfully accomplishing the scenario) are not required.”

PAUL REVERE'S MIDNIGHT RIDE

Now let’s apply the same concepts as we did above to a classic historical event: Paul Revere’s midnight ride.

Paul Revere was charged with notifying the militia of the impending advance of the British military. In addition to Revere, William Dawes (whom history has not remembered as well) was tasked with the same responsibility, taking an alternate route in the cause. So, we can get a good start at breaking down the events into a use case.

• Name

An action-oriented summary of the use case.

“Alert Militia of British Attack”

• Description

Providing additional detail to expand on the name of the use case.

“Ride from Boston to Lexington to alert the Sons of Liberty of the advance of the British army."

• Actors

Who are the individuals involved in the execution of the use case? Paul Revere and William Dawes. Revere and Dawes were told to enlist the assistance of additional Sons of Liberty that they encounter on their ride. So our actors would be:

"Paul Revere, William Dawes, and additional Sons of Liberty."

• Preconditions

Before we continue with the use case breakdown, we need to consider the preconditions that must have been achieved or set to a state to allow us to proceed with the use case execution. What did Paul Revere and William Dawes need in order to depart on their midnight ride.

Well, the obvious precondition is that they have horses to ride. It rarely hurts to be too specific or literal when stating preconditions. Try not to get too “Zen” or look at events in the distant past. Stating that the actors have been born for example, or that the actors allegiances lie with the militia resistance, while they may be preconditions are ultimately going to create very long, philosophical documents that turn off your readers.

In addition, the use case is not to be executed until “The British are coming.” Although as most members of the resistance still considered themselves subjects of the British Empire and British themselves, it is more likely that Revere and Dawes called out “The Regulars are coming!” in reference to the British Regular Army.

Another common convention you will see in the construction and documentation of use cases is the reference to other use cases. Revere and Dawes were to be notified of the British approach with the well known “One if by land, two if by sea.” The well-known phrase referred to the number of lanterns that would be placed in the Old North Church by Robert Newman. This pre-requisite step was necessary to allow the midnight riders to communicate the British attack plan. Without it, Revere and Dawes cannot proceed with the use case.

To relegate the lighting of the lanterns to a single line in our use case doesn’t seem befitting of the event, which itself has a description, preconditions, actors, and all the other makings of a use case. Robert Newman, the actor of the use case, needed lanterns, fuel, access to the tower… So as another precondition, we can add “Robert Newman has completed the use case, “Lighting of the Old North Church Lanterns”

• Scenario

The scenario is the desired progression of events to achieve the successful completion of the use case. In our scenario, it would look something like this:

• Look for signal at the Old North Church.

• If one lantern is lit, the British army is approaching by land.
• If two lanterns are lit, the British army is approaching by sea.

• Ride on horseback to Lexington.
• While en route to Lexington, alert militia members of the advancing British army.
• Arrive in Lexington and inform the Sons of Liberty of the advancing British army.
  

• Results

Once the scenario is accomplished, this is the final result of having accomplished the use case. Again, in our case, to summarize, the desired result would be:

• The Sons of Liberty, led by Samuel Adams and John Hancock, receive advance notice of the British approach.

• The advantage of surprise is lost.
• The Sons of Liberty organize the militia in advance of the arrival of the British army.

• Alternate Paths

It may seem as if there was little to be said about the scenario and results for our midnight ride. This is not unusual. Whether a business process, a software system, or a pivotal event in the American Revolution, the best plans are often the most simple. The desired scenario and results unfortunately are not always easily achieved. The best plans take into consideration the alternate paths that may be necessitated by chance or misfortune. Ideal execution by our actors (or users) is often the exception, and the best analysts will often anticipate accordingly, and the Alternate Paths section of your use case will quickly become the largest section.

Advice for documenting alternate paths is quite similar to that when documenting preconditions. Detail is ever-important; but don’t go overboard. Alternate paths, if not properly identified in advance by the business analyst should quickly become evident to others involved in the process, whether it be developers or quality assurance analysts. Alternate paths represent that old 80/20 paradigm. Eighty percent of the use case executions may fall under the happy-path scenario, while the remaining twenty percent of the executions will fall under the alternate paths category. And those twenty percent alternate paths? They will account for eighty percent of the development and testing effort, resources, and hours.

So for our midnight ride, what would the likely alternate paths be? Well, the one that the militia had planned for was the eventuality that Revere and Dawes would be captured or killed by the British. Other scenarios to consider, although no historical record exists that Revere and Dawes were ever trained for the possibility, are that no lights are seen in the Old North Church steeple—or perhaps that three lights were seen? Did that mean the attack would come from both land and sea?

• Additional Business Rules

Business rules will appear in a use case scattered throughout, presented where relevant. But if any given business rule governs the entire use case, it should be given special attention in the final section of the use case.

As previously described, the popular “One if by land, two if by sea” were described in our scenario as the following contextually business rules: “If one lantern is lit, the British army is approaching by land. If two lanterns are lit, the British army is approaching by sea.” These are captured contextually in the use case.

Also, as discussed previously, in the identification of actors, if additional riders are encountered en route to Lexington, encourage them to set out to assist in the execution of the use case. Additionally, as mentioned previously, the reason for the lighting of the lanterns in the Old North Church was in the event that Revere and Dawes were captured or killed, the lights should be visible from Charleston so that others might take up the midnight ride in their absence.

So what is the point of all of this? Hopefully by describing a well-known historical event in a simple, clean, and professional structure, the complexity and intimidation of use cases can be diminished.

I have attached the original PowerPoint presentation from which this article was generated, as well as a sample template in Microsoft Word format that includes the Paul Revere use case for you review and re-use. Look at the document and use it as a model. Remember that there is no right or wrong format for preparing use case documentation. The only right way is the way that works for your project team, for your organization, and for you.

Oh, and for the record, I’ve never read Anna Karenina. I’ve been meaning to, but I’ve been too busy writing use cases.

PowerPoint Presentation

Midnight Ride Use Case

This article and the accompanying presentation come from a September presentation to the International Institute of Business Analyst, Twin Cities, MN chapter by the author.