Anatomy of a Use Case: Skip the Outline and Dive into the Main Scenario

This article discusses Stephen King’s creative writing method and provides an example of using it in developing a use case narrative: the main scenario with alternate and exception paths. Yes, that is correct – Stephen King, the prolific writer of contemporary horror, science fiction and fantasy novels. 

Recently, I read the book “On Writing” by Stephen King [1]. I recommend it. In the first part of the book, King provides an honest reflection of his life. In the second part, he provides insight on how to write a fictional novel. What surprised me was his method of writing a story.

Many writers, perhaps most, start by developing a plot or an outline of their work. However, Stephen King has a different approach. He creates a situation and then places his characters in that situation. He purposely makes these characters “flat and unfeatured.” [1] With the scene and characters set, he begins the narrative and allows the characters to develop their own personas via a series of “what if” [1] questions; essentially the characters build their personalities by the choices they make; much like the adage “we define ourselves by the choices we make.” In reality, Stephen King makes their choices; however, it is always in the context of the character (i.e., given this character in this situation, what would this character do?).

King rationalizes this method with a profound and true statement: “our lives are largely plotless.” [1] I agree with him. My life is an undefined plot even though I am plan driven. However, Stephen King is a storyteller, whereas I am a writer of use cases. I outline my use cases stating the main scenario and the alternates and exception paths. Oops, come to think of it, use cases are stories. I guess I am a storyteller. Perhaps, King’s method is another way of developing use cases. There may be something to learn here or at least obtain more insight with my current approach.

Our Example

Our situation is located in a restaurant. A restaurant waiter approaches a seated customer with the purpose of taking the customer’s order. Currently the waiter writes the order on paper and then hands it to the chef in the kitchen. The goal of this use case is to automate the order submission process via an Order System.

Note use case descriptions consist of several components such as pre and post conditions; I only show the main scenario, which is our focus. Also for the purpose of brevity, I have omitted references to business rules.

Traditionally, many of us would first write an outline of the use case scenario. We would provide titles for the main scenario and the alternative and exception paths. When we write a factual report, outlining provides us structure and keeps us on topic. However, writing a fictional novel, a story, or ause case is creative. The situations and character decisions in those situations develop the story itself. Therefore, the benefit of the outline is limited since alternate and exception paths from the main scenario are mostly unknown. They need to be developed.

Note that if we are documenting an existing system using use cases, it is similar to writing a factual report; in this case, an outline is beneficial.

Here is an outline or plot for our restaurant situation – Take an Order. We are not subject matter experts on the waiter’s job – unclear what all of the alternate and exception paths are. For this outline example, we identified the main scenario, but only alternate A1 and exception E1; A2 – A6 are unidentified.

• Main Scenario – Take an Order

A1) Alternative – Check Order Status
A2) Change an item on an Order – unidentified
A3) Alternative – Retain the Order – unidentified
A4) Alternative – Add an item to an Order – unidentified
A5) Alternative – Delete an item on an Order – unidentified
A6) Alternative –Draft an Order – unidentified
E1) Exception – Change a Completed Order – unidentified

Using King’s method, we instead skip the outline and write the main scenario (happy path) directly. Within the main scenario, we highlight the actor choices by using the verb “decides.” [2] For example:

Note the use of the verb “decides” for actor choices. [2] This technique allows for easy identification of the alternative and exception placement later on in the process.

Main Scenario:

1. The Waiter initiates a conversation with the Order System by asking for service.

2. The Order System responds by asking what service the Waiter needs.

3. The Waiter decides to request the order service.

4. The Order System provides an order menu.

5. The Waiter fills out the menu by selecting the table number, the menu item, quantity, and order comments for each customer.

6. The Order System responds by asking the Waiter to submit the order.

7. The Waiter decides to submit the order.

8. The Order System stores the order with a status of “submitted,” and confirms the order with the Waiter.

9. Use case ends.

Note that an actor’s decision choice in the main scenario is the one that accomplishes the use case goal in the fewest steps without error (happy path).

After we have finished and validated the main scenario, we then analyze each of the actor’s decisions. Upon each “decides” verb, we put the associated actor through a series of “what if” questions allowing the actor to develop its own persona. However, here we have an advantage. We can observe stakeholders doing the current process (AS-IS) and then conduct an interview or facilitate a meeting with the stakeholder on their vision of the new (TO-BE) process. For each stakeholder “what if” answer, we write an alternative and/or exception path.

Alternate A1 to Main Scenario at step 3: What if the Waiter checks order status

3a) The Waiter selects the order status service.
3b) The Order System lists all the orders with their status.
3c) The Waiter decides to change an order.
3d) The Order System submits the order change.
3e) Return to the main scenario at step 4.

Alternative A2 to Alternate A1 at step 3c: What if the Waiter retains the orders

3c.1) The Waiter retains the orders.
3c.2) Return to the main scenario at step 9.

Alternative A3to Alternate A1at step 3c: What if the Waiter adds to an order

3c.3) The Waiter requests to add to an order.
3c.4) The Order System submits the order addition.
3c.5) Return to the main scenario at step 4.

Alternative A4 to Alternate A1 at step 3c: What if the Waiter deletes an order

3c.1) The Waiter deletes an order.
3c.2) The Order System submits the order deletion.
3c.3) Return to the main scenario at step 4.

ExceptionE1 to Alternate A1 step 3c, Alternate A2 step 3c.1, and Alternate A3 step 3c.1: What if the Waiter selects a completed order

3c.1) The Order System gives the Waiter the following message“ Only draft or submitted orders can be changed.”
3c.2) Return to Alternate A1 step 3b.

Alternate A5 to Main Scenario at step 7: What if the Waiter drafts an order

7a.1) The Waiter saves a draft of the order
7a.2) The Order System stores the order with a status of “draft.”
7a.3) Return to the main scenario at step 9.

Note it is a best practice that the use case authors write alternates and exceptions without changing the main scenario. This practice avoids revalidation of the main scenario due to changes.

Summary of using the King Method for writing the use case narrative:

1. Define the situation (use case goal).

2. Define the characters (actors involved in accomplishing the use case goal).

3. Write the narrative (main scenario using the verb “decides” when an actor makes a decision). [2]

4. After the main scenario is complete, write alternatives and exceptions together with the stakeholders asking the question “what if” at the point where an actor makes a decision in the main scenario.

You may consider King’s method a subtle difference from writing an outline. Certainly, there is the advantage of having an outline for documenting an existing system since we know the alternates and exceptions. However, writing a use case for a proposed system is creative – alternates and exceptions are unknown. This is why we struggle in identifying alternates and exceptions in a use case outline; this is particularly true when we have limited domain knowledge.

Perhaps, using Stephen King’s method, we should bypass the outline for proposed systems, directly write the main scenario, and then later ask our stakeholders to fill in the gaps (alternates and exceptions)along with us at each decision point.

Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) International, and the International Association of Facilitators (IAF).

Mark is the President of Monteleone Consulting, LLC and author of the book, The 20 Minute Business Analyst: a collection of short articles, humorous stories, and quick reference cards for the busy analyst; available on amazon.com and extended networks. He can be contacted via – www.baquickref.com.

References

1. King, Stephen, “On Writing”, Simon & Schuster
2. Monteleone, Mark, “Document Decision Separately and Explicitly – A Proposed Use Case Scenario Best Practice,” www.modernanalyst.com