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.
OpenRules - Decision Intelligence Platform 
If variable names could not have spaces you’d have a point. But they can, so names in scope must be identified graphically. It’s how the language works.
As long as variable names are unique (either with spaces or without) we can easily identify the links between BKMs if they exists. Otherwise, the “language” wouldn’t work. Sorry, but you need to elaborate.
There are no obligations in DMN to draw requirement links in a DRD. The DRD can be used to visualize any subset of the DRG.
Furthermore DMN 1.2 introduces the ellipsis maker to specifically indicate that not all (or any) requirement links for a Decision are displayed in a DRD. These features are already implemented in the Trisotech DMN Modeler if you to experiment with them.
As for specifically serializing the requirement links in the DMN file this is still required. But the serialization is normally really meant to be machine generated and read and should not be an issue for users but only for tool vendors who implements the standard.
Hope this help.
Thanks, Denis. So, the requirement links are optional in DMN. If we agree that they can be discovered automatically when business logic is defined, then it is only natural to ask: why do we need them in DMN XML? If you have business logic implemented and presented in DMN XML, another DMN implementation can define all links automatically. If you have only diagrams without BKM implementations, then DMN XML can be used only for the diagram interchange. You probably may find situations when it makes sense, but I believe the main purpose of DMN XML is the interchange of executable decision models.Hope, you agree that we should not over-complicate DMN without practical necessity.
The Decision Model & Notation (DMN) is meant to support various use cases in the Decision Management space. This certainly includes the interchange of executable decision logic.
But it is not the only, or more important, use case. All use cases are equal 😉
It includes the specification of Decision Logic as literal expressions or using the Boxed Expression structure (some do, some don’t). It also includes the interchange of Decision Requirement Diagrams (DRDs) without any Decision Logic specified (some do, some don’t). DMN is explicit about what is needed for tools to claim compliance at different levels.
Further more the “notation” is meant to be a transferable skill, a visual recognizable depiction of Decision Requirements even without any interchange.
As per my comment above, the XML serialization is meant to support all possible use cases and is really meant for machines consumption. As with anything else the spec tries to make things as complete as required by the various uses cases without trying to over-complicate the resulting artifacts.
Hope this help.