Page History
...
Let's say we're modeling a very simple decision that determines whether someone will receive a discount on some sort of insurance.
Females are eligible for this discount, males are not. The decision requirements graph will probably look something like the one sown below.
Use Ctrl-click on the various elements to open them and verify that the discount is modeled correctly.
Although even for simple decisions the DRG is very useful while designing or reviewing, the true strength of the DRG is exemplified when designing or reviewing multi-layered complex decisions. See the example DRG below, that shows the decision that determines an applicant's risk scoreStrategy. At level 1 this decision looks very trivial.
When expanded to the next level,it shows that the decision consists of three two separate decisions.
At level 4 the we find that there are in fact twelve many more decisions in play:
It is possible to completely expand all decisions, knowledge models, input data and sources in one single graph, but this will most likely result in a diagram that is not usable for any type of audience. Therefore it is advised to expand sub decisions in separate DRG's. Shown below is such a DRG for the sub decision Risk score bonusBureau call type.
Runtime Decision Requirements Graph
Although OMG´s standard DMN does not contain any specifications for it, Blueriq also uses a runtime decision requirements graph. This graph resembles the design time decision requirements graph, but differs mainly with regards to the fact that is shows all given answers and derived values. See the example below, also about the risk score example.
Expanding sub decisions shows exactly what has been filled in by the user or derived by Blueriq at runtime in a specific session.