Page History

...

Business process modelers that have a lot of experience using classic BPM might argue that this shift in modeling has two downsidedownsides.

The first downside has to do with the fact that preconditions might become complex and therefore not understandable. This is arguably true, since because complexity of the business will not magically disappear when using preconditions instead of flow. However, the complexity of preconditions is maintainable even at even a very large scale, the complexity of flow will - at one point or another - grow beyond repair. Flows become more complex when the scale increases, with more arrows, duplicated activities and decisions used for the sake of control. When using tasks with preconditions, the number of tasks grows with an increasing scale, not the complexity of the tasks.

A second argument downside often heard is that flow has a visualization, namely the flowchart, whereas preconditions do not have such a visualization. This is not correct with regards to Blueriq!

...

Create an entity for each ad-hoc Task, with the attribute <TaskName>.MayBePerformed and if applicable <TaskName>.MustBePerformed.
Of course it is also possible to create a single combination-entity with a may-be-performed-attribute and a must-be-performed-attribute for all tasks, this is subject to the Business Engineer's taste or agreed architectural (project) guidelines. In this document we use an entity for each task.

...

Create a precondition (and possible conditional requirement) that uses the attributes mentioned before. The structure will always be the same: the precondition will be <TaskName>.MayBePerformed.
In the example below we have two ad-hoc tasks, Approve travel request and Ask for additional information ApproveTravelRequest and AskAdditionalInformation. We now focus on the precondition Approve travel request ApproveTravelRequest may be performed.

3. Logic for attribute

Use any logic element to infer when the task may and/or must be performed. Below a decision table is sketched that states when the task ApproveTravelRequest may be performed.
Note that the column on the right might be considered redundant, since the attribute also has a default value False.

4. Inspect with Decision Requirements Graph

Use the Decision Requirements Graph to inspect the logic underneath the derived attribute. This Decision Requirements Graph can be generated from the logic element or from the attribute itself, in both cases by clicking the scale icon .
Unfortunately the Decision Requirements Graph cannot be generated not from the precondition in of the task directly, since  as the precondition is an expression and not necessarily a decision (derived attribute).

...