Moving From Use Cases to Processes

This article outlines things to consider when transitioning from using Use Cases in Legacy Blueprint to Processes in the new Blueprint experience.

Blueprint Processes are newer and were designed to overcome many of the limitations large organizations experienced when using use cases. It should be noted that they are both ‘equivalent’ in their ability to effectively model user-system interaction, but Blueprint processes provide greater consistency across large groups of users and they ‘guide’ users toward higher-quality models that result in higher-quality outputs.

Below are two tables - one that summarizes the advantages of Blueprint Processes as compared to Use Cases, and another that summarizes the advantages of Use Cases as compared to Blueprint Processes.

Advantages of Processes in the New Blueprint Experience

Helps non-expert users create

Better Model Communication

Consistency across users

Alignment across disciplines

Higher quality generated outputs

Enforces alternating user-system steps

✅

✅

✅

✅

Simplifies includes/extends

✅

✅

Model/Connect Business, User-Sys, Sys-Sys

✅

✅

✅

Explicit support for Decision Types

✅

✅

✅

Autogenerate user stories

✅

✅

✅

Autogenerate gherkins

✅

✅

✅

Smart copy-paste

✅

✅

Inline help and overall ease-of-use

✅

‘Do Nothing’ allowed on user choices

✅

✅

Include any artifact

✅

✅

Navigation breadcrumb

✅

✅

Drag-drop editing

✅

Paste images into System Responses

✅

Advantages of Use Cases in Legacy Blueprint

Comments

Live-synchronized Use Case Diagram

There is no live synchronized use case diagram, but use case diagram can be created in a ‘model’ artifact and individual use case shapes linked to process artifacts

Textual/Doc-Style Editor for Use Cases

There is no doc-style editor, but there is a text read-only view

UI Mockup Artifacts on Steps

Users cannot associate mockup artifacts to steps, but they can associate screen shots

Use Case Simulation

There is currently no simulation capability, but users can walkthrough manually using the editor

Use Case “Exit”

Currently the only “Exit” for a Storyteller Process is the post-condition of that process

Advantages of Processes in the New Blueprint Experience Over Use Cases in Legacy Blueprint

Enforces Alternating User-System Steps

In a Blueprint process, a user step is always associated with a corresponding system step to form an ‘action/reaction’ pair. The system step portion can be hidden from view (using the ‘System steps’ switch) but it cannot be deleted. This enforces the standard good-practice of use cases modeling a dialog between two objects. Because of this people can rely on all processes being well-structured, it guides non-experts in proper structure, and as a side effect, the tests that are generated will similarly be well structured.

Note in cases where there is significant system processing that occurs between the user action and the ‘observable’ system response, the user can document a series of system processing steps by clicking the ‘dog-ear’ on the system response as shown in the following diagram.

Simplified Includes/Extends

Beginners and novices to use cases often experienced trouble using includes and extends and understanding the differences between them. Blueprint processes reduce these two down into a single simple construct, yet without losing any the power or benefits. An ‘Include’ is the simpler relationship and that is what processes support. Any process User Task or System Response can have an ‘include’. An extend simply becomes an include that occurs on the first step of a choice.

This is far simpler to understand and use and doesn’t sacrifice any capability whatsoever.

Model Business, User-System, or System-System

Process artifacts can effectively model Business Processes (“System steps” switch off), or can explicitly model dialogs between objects (“System steps” switch on). Those dialogs could be between any objects that interact with each other. Most common however is between a user and a system, but it could be multiple systems interacting with each other. In the case of RPA it would typically be a robot or ‘Digital Worker’ interacting with multiple applications.

Explicit Decision Types

Processes provide support for user “choices” and system “conditions”. The first is based on a conscious choice of the user while the other is based on a condition of the system. While this distinction may sound trivial, it can be extremely important to understand this when building and testing applications.

Having these decision types readily accessible helps keep them top-of-mind with the user and can help them create high-quality models and auto-generated artifacts.

Auto-generate User Stories

Blueprint automatically generates user stories from the processes. One user story is generated for each ‘User Task’ in the process. You can generate the story for a selected task, or for all the tasks at once. The story contains a well-formatted Story Title (As a ___ I want to ___ …), Acceptance Criteria populated with Given-When-Then statements, an attached Feature File with gherkin script, and attached images for all the screen-shots from the model. These user stories can be generated at any level of the model – although it is most typical to generate at the lowest level. They can also be auto-synchronized to agile task management tools like JIRA, Rally, VersionOne, Team Foundation Server, or others.

Auto-Generate Gherkins

For every user story, Blueprint automatically generates and attached a gherkin feature-file. The content of this file is created based on the information within and structure of the process model.

Smart Copy-Paste

Blueprint processes adhere to a set of rules which enforce good practices and help keep models consistent and interoperable regardless of who created them. Smart copy-paste allows users to make copies of process portions while ensuring these rules are always enforced. The diagrams below show an example:

Inline Help and Overall Ease of Use

Blueprint’s design assumes users have no technical background, and is usable by a broad range of user proficiency levels from casual/novice to expert. It includes video tutorials and inline contextual help. In addition, it was designed using a structured, fixed layout with minimal shapes (four in total) from which systems of any size or complexity can be effectively modeled.

“Do Nothing” Branch Allowed on User Choices

There were often situations in a use case where users wanted to have a do-nothing option alongside other choices. Use Cases however didn’t allow for this, forcing users to have an empty step which they would label “dummy” or “null” or “do nothing”. Blueprint processes allow users to have a branch that with no explicit task on it, thereby solving this problem.

Include Any Artifact

Blueprint Processes let you include not only sub-processes, but any other type of artifact as well – even artifacts created by legacy Blueprint. Examples might be a business process, domain diagram, screen mockup, actor, use case diagram, use case, document, storyboard, glossary, or textual requirement.

As you navigate a Blueprint process structure by following multiple ‘includes’ to reach lower and lower levels, a ‘breadcrumb’ trail shows you the navigation path you’ve taken. You can click on any part of the ‘breadcrumb’ to quickly traverse back to any prior navigation point.

Drag-Drop Editing

Blueprint processes can be restructured or edited simply by dragging-dropping shapes. Blueprint ensures that any such edits adhere to the process structure rules so users need not be concerned about the structural integrity of the processes after editing.

Paste Images into System Responses

Many users need to have images in their Use Case system-steps. To do this with Use Cases a user would first have to create a User Interface Mockup Artifact, then upload an image into that mockup, then publish the artifact, then associate the published mockup with the desired system-step of the Use Case. With a Blueprint process the user simply pastes the image into the system-response.