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
Model/Connect Business, User-Sys, Sys-Sys
Explicit support for Decision Types
Autogenerate user stories
Inline help and overall ease-of-use
‘Do Nothing’ allowed on user choices
Include any artifact
Paste images into System Responses
Advantages of Use Cases in Legacy Blueprint
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.
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.
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.
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.
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.