How to use the power of the Decision Requirements Graph when using preconditions in business proces modeling [editor]

Immediate cause

There is a trend among business process modeling, where modeling with preconditions is taking precedence over modeling flow. When the business requirements grow, classic BPM flowcharts become less and less readable, until they finally burst with complexity. Maintenance on such complex flowcharts will become difficult and eventually maybe even impossible.

Using independent ad hoc tasks that have preconditions that state when such a task may be executed and when it must be executed, will result in far better readable and maintainable business models, a quicker time to market and happier customers.

Using ad hoc tasks and preconditions requires a shift in business process modeling. In stead of thinking about a task and possible next tasks, the business process modeler needs to figure out when a task is applicable and necessary.

Complexity and traceability

Business process modelers that have a lot of experience using classic BPM might argue that this shift in modeling has a downside. This downside has to do with the fact that preconditions might become complex. This is arguably true, since complexity of the business will not magically disappear when using preconditions in stead of flow. However, the complexity of preconditions is maintainable even at a very large scale, the complexity of flow will - at one point or another - grow beyond repair.

So how do we maintain complex preconditions? By using the power of Decision Requirements Graphs, a diagram that is available within Blueriq 9.3 an onwards and is based on the Decision Model and Notation (DMN) standard by the Object Modeing Group (OMG). Shown below is an example of such a graph.

For more information about the Decision Requirements Graph see Decision Requirements Graph.

Step-by-step guide

In order to use the power of the DRG in modeling preconditions, follow these steps:

1. Create an entity for each task with two attributes: Task.MayBePerformed and Task.MustBePerformed.

It is also possible to create a combination-entity with attributes for multiple tasks.

2.Create a precondition (and possible conditional requirement) that uses the attributes mentioned before.

In the example below we have two ad hoc tasks, Approve travel request and Ask for additional information.

3. Use any logic element to infer when the task may and/or must be performed.

4. Use the Decision Requirements Graph to inspect the logic underneath the attribute.

Note that you can generate this Decision Requirements Graph from the logic element or from the attribute itself. Unfortunately not from the precondition in the task.