The concepts of Happy, Alternate, and Exception Paths originated with Use Cases, but turn out to be applicable to any graphical modelling technique that depicts Flow. This article presents examples of Business Process, Activity, and State Transition diagrams with these concepts represented simply using the common “Traffic Light” colors green, amber, and red. The benefits to both business analysts and stakeholders are discussed.
NOTE: This article is not intended to be a tutorial on any specific graphical modelling technique. Examples presented are intended to demonstrate adding color to model elements to indicate the applicable path types.
Use Case Path Type Concepts
The concepts of Happy, Alternate, and Exception Paths are part of the detail of a given use case. That detail includes steps the actor or the system performs, grouped within named paths. A use case will have one Happy path and can have any number of paths designated as Alternate or Exception paths.
- Happy Path – the preferred or most common sequence of steps that successfully leads from the start of the activity to achieving the use case goal.
- Alternate Path – a sequence of steps to be performed when a complication arises from performing a particular step in the Happy path or an Alternate path.
- Exception Path – the sequence of steps to be taken when a complication arises from performing a step that can prevent achieving the use case goal.
Examples:
Paths for a “Payment by Bank Card” Use Case involving a “Retail Salesclerk” Actor:
- Happy Path - The customer utilises a bank card for which payment is approved.
- Alternate Path - Payment is not approved but customer has another bank card for which payment is approved.
- Exception Path - Payment is not approved and customer has no other bank card to offer for payment.
Steps within a path are described textually. The default flow of steps is sequential. Conditions that cause a variation to a sequential flow (i.e. to a different step within the path, or to the start of another path) are also described textually. When a use case involves numerous, complex sequence-altering conditions difficult to describe textually an Activity Diagram is recommended (i.e. “A picture is worth 1,000 words”).
Activity Diagram Paths
The original UML Activity Diagram was a variation of the traditional software program logic-representing Flow Chart. A developer would map out the steps to be coded, including conditional branching and looping. Flow chart-style diagrams these days are often used as a graphical technique to represent manual steps within a business activity. For example, a customer service rep dealing with a complaining customer.
What is not a standard practice of flow charting or producing UML Activity Diagrams is identifying the steps that belong to different path types. Fortunately most diagramming tools include the ability to modify the color and/or line styles of selected elements. The following is a before-and-after example of an activity diagram. In the second example, path-type-specific “Traffic Light” colors have been applied to line and step elements.
Ideally each condition element within a path in an activity diagram would be worded so that its “Yes” indicates continuing to the next step within that path.
Within the context of this article we define the term Activity (whether diagrammed or not) as follows:
“An Activity consists of defined Steps sequenced within one or more condition-dependent paths. The steps are intended to be performed by an Actor. That actor can be an individual, a system, or an individual interacting with a system. The activity is expected to add identifiable Value towards the achievement of an overall Goal.”
Given the above definition we proceed to discussing Process paths.
Process Diagram Paths
The primary difference between an Activity Diagram and a Process Diagram is that in an activity diagram the “rectangle” shape represents a Step while in a process diagram that shape represents an Activity. Because an activity is performed by a designated Actor it’s common for a process involving multiple activities to involve more than one actor.
NOTE: Support for process models in UML was achieved by enhancing the original UML Activity model with the capability to include Swim Lanes. A swim lane identifies an actor-like Role indicating who is expected to perform all the Activities positioned within the lane.
As was demonstrated with activity diagrams above, it’s possible to apply the Use Case concepts of Happy, Alternate, and Exception path to process models. The definitions of these concepts are conceptually the same, but substituting appropriate process-level terms yields:
- Happy Path – the preferred or most common sequence of activities that successfully leads from the start of the process to achieving the process goal.
- Alternate Path – a sequence of activities to be performed when a complication arises from performing a particular activity in the Happy path or an Alternate path.
- Exception Path – the sequence of activities to be taken when a complication arises from performing an activity that makes it difficult or impossible to achieve the process goal.
Examples:
A Retail Self-Checkout Process involving Customer and Customer Service Staff:
- Happy Path – includes a “Pay by Bank Card” activity performed by a Customer because the organization prefers to avoid dealing with cash.
- Alternate Path – includes a “Pay by Cash” activity performed by the Customer allowing the process to still reach its goal.
- Exception Path – if the “Customer Unable to Pay” business event occurs then one of the [manually performed] activities performed by the Customer Service Staff is “Retain Products”.
As with Activity diagrams, applying Use Case path concepts does not impact any existing process modelling techniques. It’s only a matter of applying a three-color scheme, as seen with the following examples:
Path-Based Process Analysis
Use Case path type concepts can be beneficial to both the business analyst tasked with producing process models and the subject matter experts (SMEs) that provide the business knowledge of a given process. Having identified a process to document, the discussion with SMEs should initially focus only Happy path activities.
Given that set of activities, conditions can be explored that would require alternate activities to keep the process moving towards its goal (one path at a time):
NOTE: Some diagramming tools offer a layering capability. This allows path-base views to be produced which are useful when documenting the process path by path.
And given Alternate paths that still achieve the process goal, SMEs ideally can identify Exceptions that can prevent the process from succeeding.
When accompanying a business process model with supporting text, the most natural organization for a narrative is path by path.
State Transition Diagram Paths
State Transition is not a commonly used business term. As a result, Business Analysts are not often asked to produce a State Transition Diagram as part of detailed requirements documentation or user story refinement. However, what is commonly encountered in an information system are records that include a Status field (e.g. Account Status, Product Status, Employee Status).
NOTE: This article uses (and recommends BAs use) the more business-friendly term “status change” instead of “state transition” when dealing with stakeholders regarding information system records. See How to Create a ‘Less is More’ Stakeholder-Friendly Data Model in Minutes.
A common technique for documenting valid and invalid status changes is a “From/To” matrix. The following would support a record’s status field having eight possible values:
What such tables do not capture are the types of business events that instigate a given change. These events can be:
- A specific Activity’s success, delay, or failure
- A specific Process’s success, delay, failure, or the need to revert to a previous activity
- An internal, external, or time-based event
A From/To matrix is certainly worth 100-ish words. But a (renamed) Status Change Diagram has the potential of being worth closer to 1,000 words. The following is an example of an eight-value status field with its status values and their valid status changes represented diagrammatically:
NOTE: In the diagram above a bulleted list implies a given change can occur as the result of any of the listed business events.
Even better would be for such diagrams to highlight status changes based on Use Case path concepts. Those path definitions require slight alterations to accommodate a context dealing with status field value changes:
- Happy Path – the most common or preferred sequence of changes between path statuses. The path begins with the initial (default) status and ends with the status that indicates that the record instance has no further operational value to the organization.
- Alternate Path – a reverse-direction change between Happy path statuses, or a change that leads away from and ends on a Happy or Alternate path status.
- Exception Path – a change from a Happy or Alternate path status that does not end back on a Happy or Alternate path status.
The following diagram presents the same status changes example diagram but with Traffic Light colors applied based on path type:
The benefit of representing a record’s status value changes in a status change diagram increases with the number of values involved. A business analyst should explore with subject matter experts the business events that can effect a given change, rather than simply recording “yes or no” between value pairs. That exploration can be guided by initially considering Happy, then Alternate, and finally Exception paths.
Conclusions
The take-away points from this article should be:
- There can be benefit to a business analyst factoring Happy, Alternate, and Exception paths into their thinking, outside the context of Use Cases.
- There can be readability benefits from enhancing diagrams involving flow paths with traffic light colors representing path types.
The Trips-R-You Web-Base Flight Booking Case Study offers further examples diagrams applying these concepts as part of detailed requirements analysis.
Author: Dan Tasker, Author & Requirements Expert
Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].