Knowledge and Information Requirements are essential components of the current version of the DMN standard, which defines them in the section 6.2.2 as follows:
- Information Requirements may be drawn from Input Data elements to Decisions, and from Decisions to other Decisions. They represent the dependency of a Decision on information from input data or the results of other Decisions. They may also be interpreted as data flow: a DRD displaying only Decisions, Input Data and Information Requirements is equivalent to a dataflow diagram showing the communication of information between those elements at evaluation time.
- Knowledge Requirements may be drawn from Business Knowledge Models to Decisions, and from Business Knowledge Models to other Business Knowledge Models. They represent the invocation of business knowledge when making a decision. They may also be interpreted as function calls: a DRD displaying only Decisions, Business Knowledge Models and Knowledge Requirements is equivalent to a function hierarchy showing the function calls involved in evaluating the Decisions. The Knowledge Requirements of a valid DRG form a directed acyclic graph.
When we build decision models with such good graphical tools as Trisotech, one of the most non-trivial tasks is to correctly draw the proper arrows for these requirements and then to keep them in tact with the other DMN constructs which these arrows connect. It is nice to visualize these relationships within DRD or DRG diagrams to better understand our diagrams.
However, why to force a user to draw these arrows manually? If the objects, which these arrows connect, are already defined, the arrows for both knowledge and information requirements can be defined and drawn automatically!
I understand that when we design a decision model in the top-down fashion, we may specify these arrows (relationships) even before we specify the actual DMN elements they connect. At the same time, the drawing tool may automatically check if manually drawn arrows are still not defined and display them in different “undefined” color. If the proper DMN elements are defined, the tool should be able to validate manually drawn arrows and adjust/add them automatically. I can easily envision check buttons “Show Knowledge Requirements” and “Show Information Requirements” to be added to the DMN graphical modelers. Sometimes, even a simple ability to hide information requirements can make our DRDs more readable. I hope the developers of such tools (Trisotech, Signavio, and others) will quickly add these proposed features to their product.
Let’s look at the same issues from the interchangeability perspective. Usually already completed DMN-based decision models can be exported into the DMN XML interchange format. This format has been already well-specified by the DMN 1.1. Again, both Knowledge and Information Requirements occupy an essential part of this format as well. However, do the DMN execution engines need this information? Not really, as they relatively easy can define it automatically. So, why would not a new DMN version simplify knowledge and information requirements probably making them optional?
What is your take on these issues? Am I oversimplifying the situation? Are there some exceptions which I missed? Hopefully, the DMN Revision Task Force will use these considerations to make our DMN standard simpler.