Source: Red Hat ( Matteo Mortari)
Executive summary: by the way the DMN specification stands, the description that Requirements SHALL (== "MUST") be referenced in the expression will nullify any CL1 DMN model and any DMN model not using FEEL, as not-conformant.
In section 7.3.4 InformationItem metamodel we read:
A variable representing an instance of Decision or InputData referenced by an InformationRequirement SHALL be referenced by the value expression of the decision logic in the Decision element that contains the InformationRequirement element. A parameter in an instance of BusinessKnowledgeModel SHALL be a variable in the value expression of that BusinessKnowledgeModel element.
By side effect of this strict mandate in the specification, it is like saying an UNused requirement will fail conformance.
Example: a decision enlist A, B, C as Requirements, but in the formula we use only A and B. According to the current spec, this makes the model failing conformance and invalid.
Granted, it is always a best practice not only for BA but also for developers to avoid "unused requirements/variable"!
But here is giving a strict mandate.
Further, any DMN model which does not use FEEL "only DRG" automatically fail this constraint which is in Chapter 7.
The DMN specification should follow best-practices of Modeling AND programming languages, where is NOT a blocking issue to have "unused requirements/variables", but of course warn when those are detected; this can be easily achieved by switching SHALL to SHOULD in the identified paragraphs in chapter 7.1 and 7.3.4 per proposal.
This issue was detected in the TCK group (ref https://github.com/dmn-tck/tck/issues/487 )
Reported: DMN 1.4 — Sun, 27 Feb 2022 20:45 GMT
Disposition: Resolved — DMN 1.5
Requirements SHOULD be referenced
change text in Chapter 7.1 and 7.3.4 according to the below instructions
Updated: Fri, 30 Jun 2023 20:31 GMT