Moving From Use Cases to Processes
This article outlines things to consider when transitioning from using Use Cases in the legacy Blueprint product to Processes in the new Blueprint experience.
Processes are newer and were designed to overcome many of the limitations large organizations would experience when using use cases. It should be noted that they are both ‘equivalent’ in their ability to effectively model user-system interaction, but processes in the new Blueprint experience are considered easier to use, more consistent across large groups of users, and they ‘guide’ users to make higher-quality models that result in higher-quality outputs.
The legacy Blueprint’s Use Case capability is very powerful and full-featured with over thirteen years of development investment. The many years of lessons-learned from Use Cases were factored into the design of Processes in the new Blueprint experience but being relatively new there are some capabilities Use Cases have which have not yet been implemented for Processes.
Below are two tables - one that summarizes the advantages of Processes as compared to Use Cases in legacy Blueprint, and another that summarizes the advantages of Use Cases as compared to Processes in the new Blueprint experience. Note that most of the Use Case advantages are in the development backlog for the new Blueprint experience so over time the first table will become larger and the second table will become smaller.
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
Inline help and overall ease-of-use
‘Do Nothing’ allowed on user choices
Include any artifact
Advantages of Use Cases in Legacy Blueprint
Auto-generated traditional tests into ALM/TFS
The new Blueprint experience can auto-generate traditional tests, but the output is to a .csv file only
Use Case Diagrams
There is no single ‘big picture’ view, but users easily navigate amongst interconnected processes
Textual/Doc-Style Editor for Use Cases
There is no doc-style editor, but users create processes with an easy-to-use graphical editor
UI Mockup Artifacts on Steps
Users cannot associate mockup artifacts to steps, but they can associate screenshots
Use Case Simulation
There is currently no simulation capability, but users can walk through manually using the editor
Use Case “Exit”
Currently, the only “Exit” for a Process is the post-condition of that process
Diagram in Document Generation
Currently, Process models in new Blueprint experience don’t get generated into documents, but their properties do
Advantages of Processes in the New Blueprint Experience Over Use Cases in Legacy Blueprint
Enforces Alternating User-System Steps
In Processes in the new Blueprint experience, 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 ‘Business Process Mode’ and ‘User-System Process Mode’ toggle) 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.
Beginners and novices to use cases often have trouble using includes and extends and understanding the differences between them. For processes in the new Blueprint experience, we resolved 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 the new Blueprint experience supports. It allows you to place an ‘include’ on any user step or any system step. To accomplish the equivalent of an extend, that is simply an include that occurs on the first step of a choice.
This makes it far simpler to understand and use, without losing any capability whatsoever.
Model Business, User-System, or System-System
Process artifacts inthe new Blueprint experience can be used effectively to model Business Processes, User-System Processes (Use Cases), or System-System Processes. Especially powerful is the ability to interconnect these to create a comprehensive “top-to-bottom” model of how business functions are supported by interconnected systems.
Explicit Support for Decision Types
Processes in the new Blueprint experience provide support for user “choices” and system “conditions”. While both allow users to model different scenarios, one 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 autogenerated artifacts.
Auto-generate User Stories
The new Blueprint experience automatically generates user stories from the processes. One user story is generated for each ‘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, the new Blueprint experience automatically generates and attached a gherkin feature-file. The content of this file is created based on the information within and the structure of the process model.
Processes in the new Blueprint experience 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 provide an example:
Inline Help and Overall Ease of Use
The new Blueprint experience was designed from the outset to be usable by a broad range of users from casual to expert. Its design also assumes that users have no technical background. Part of this design includes video tutorials and inline / contextual help. In addition, it was designed using an intuitive simple panel layout and the processes have minimal shapes (four in total) from which systems of any size or complexity can be effectively modeled.
“Do Nothing” Branch Allowed on User Choices
Sometimes there are situations where an actor could make one of several choices, or do nothing. Legacy Blueprint use cases have no option for a ‘do-nothing’ branch and users were forced to have an empty step which they would label “dummy” or “null” or “do nothing”. Processes in the new Blueprint experience allow users to have a branch with no explicit task on it, thereby solving this problem.
Include Any Artifact
Processes the new Blueprint experience let you include not only sub-processes, but any other type of artifact as well – including those created using the legacy Blueprint. This 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 process structure in the new Blueprint experience by following ‘includes’ to reach lower and lower levels, a ‘breadcrumb’ trail lets you know the navigation path you’ve taken. You can also click on any part of the ‘breadcrumb’ to quickly traverse back to any prior level.
The new Blueprint experience allows users to restructure/edit their processes simply by dragging-dropping shapes. The new Blueprint experience ensures that any such edits adhere to the process structure rules so users need not be concerned about the integrity of the processes their editing.