Over the last few years, visual modelling has been a useful tool for effective software development. In fact, product teams are always on the lookout for good visual modelling tools that can enhance their development efforts.
Our Storyteller Process Editor is a powerful visual modelling tool that drives mature agile practices and bridges the gap between business and IT. The Process Editor will also automatically generate well-formulated user stories, gherkin feature files, and test cases that feed directly into your Agile development practices. Our customers can leverage this functionality to easily understand visual paradigms and create models that express:
- Complex user-system interactions
- Communicate the user experience
- Define the customer's journey across your applications
In this 4-part series of Blog posts, we will be looking at best practices and modelling techniques that will allow you to take full advantage of the Process Editors powerful feature set. These best practices and techniques are essential, if you want to generate high quality user stories and test cases from your process models.
In part 1, we will be looking at the importance of defining actors and system boundaries when creating Process Models.
Defining Your System and Actors
A metaphor for a Process Model could be a User Action followed by a System Response. In other words, the user does an action on the system described in the model, which then generates a response from the system. A Process artifact is built by sequencing these User-System actions in a logical order that describes the flow of the system being described.
The first step in creating a good process model is to define the system boundary. In other words, you have to be able to clearly articulate what’s “in’ the system and what’s “outside system”. To create a good process model, the system you are modelling must be treated as a black box. The system response step in a process model should only describe what is externally observable to the User performing the action. If you don’t have a well-defined system boundary, you will be more likely to try and describe the inner workings of your system which will lead to poor results.
Example: ATM System
The above example shows an ATM system that has two subsystems (Dispenser, Lockbox) and interfaces with two other systems (Core Bank System, ATM Maintenance).
Model 1: ATM Machine
In this example we have selected the ATM and its two subsystems to represent our Black Box system. (If you wanted to describe the subsystems in detail you would create separate process models that you could link as includes. We will be covering includes in a future blog post.)
Now that the system boundary is defined, that Actors that you will use in your process model will clearly emerge. In this case, the possible actors are the User, the Operator, the Core Banking System and the ATM Maintenance System. The Actors you choose for your model will depend on the scenarios you choose to represent.
A well-defined system boundary and actors will result in high quality user stores and test cases, which will ultimately lead to the development of applications that meet the expectations of your customers.
A Note About Actors and Personas
By default, the Process Editor will use a generic user for your Actor when you add a new user-system block to your model. Your models will be much more effective once you replace the generic user by linking to a Storyteller Actor artifact. The actor artifact allows you to create rich user persona’s that will add an extra dimension to your models. Your personas help bring your users to life and provide more context to your models. Given below is one such user persona of a ‘Young Professional. Take a minute and go through the Persona Description.
This added dimension, of knowing what the user is doing but who the user is will help your team make better decisions when turning your model into working software.
Having a well-defined system boundary and carefully choosing your actors is one of the keys to creating effective process models. A model with these attributes is easier to understand to both technical and non-technical users. This promotes a common understanding among different stakeholders which helps bring alignment between the business and IT.
A well-defined process model also leads to better user stories and test cases which ultimately leads to better applications with a high level of built-in quality.
The next blog in this series will look at the differences between User Choices and System Conditions.
To learn how your organizations can harness the power Storyteller to create the most effective process models, attend our upcoming webinar Accelerating Enterprise Agile Innovation with Storyteller, Thursday March 7th.
Share this
Blueprint Enhances Industry-Leading Enterprise Automation Platform with Next Phase of Process Design Modeling
Accelerate High-Quality Application Delivery with Blueprint Storyteller and Cognizant
