Page History

Table of contents

Immediate cause

...

We will provide a step-by-step guide on how to make optimal use of the the power of the Decision Requirements Graph when modeling preconditions. When following these steps conditions used in preconditions and in necessity (required) will be much easier to understand and maintain.

1. Attributes for tasks

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 combination-entity with attributes for multiple tasks, this is subject to the Business Engineer's taste or agreed architectural (project) guidelines.

2. Preconditions on tasks

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 very fictional ad hoc tasks, Approve travel request and Ask for additional information. We now focus on the precondition Approve travel request 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 the task, since the precondition is an expression and not necessarily a decision (derived attribute).

...

1. When following the strategy as discussed in this article, many totally different project projects will have the same structure.
2. Maintenance on projects becomes easier, since it is always clear where to start inspecting existing preconditions.
3. Complexity is not scattered over decisions, processes, tasks and flow but it is concentrated in the area where it belongs, namely logic. 
4. ...

Cons

1. Tasks are modeled in a process module, but the majority of logic elements that infer when these tasks may and/or must be performed are probably modeled in interaction modules. This means that entity and attribute duplication and data mappings are necessary.
2. When a task has a very simple precondition, the strategy described here is quite excessive.
3. ...

...