Page History

...

1. When following the strategy as explained in this article, different projects will contain a uniform and recognizable 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. Using this strategy does not interfere with the approach of flow, if applicable.
5. ...

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. Whenever a task is used more than once, with different preconditions, extra attributes have to be declared. This could result in a lot of extra entities and attributes. 
4. Since Blueriq currently cannot generate a Decision Requirements Graph directly from the precondition, an extra layer of (non-functional) entities and attributes is required to enjoy the benefits of the Decision Requirements Graph
5. ...

...

...