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 navigation breadcrumb 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