Decision model and notation (DMN standard explained. A worked example by Nick Broom

www.visionalysis.co.uk © Visionalysis Ltd 2014
The Decision Model and
Notation (DMN) standard
A worked example
May 2014
Nick Broom

The Decision Model and Notation
(DMN) standard – a worked example
Page 2 of 25 © Visionalysis Ltd 2014
This paper provides a worked example of decision modelling using the beta spec of the
Decision Model and Notation (DMN), approved by the Object Management
Group (OMG) in January 2014. This paper started off as a blog post by Nick Broom written
in January 2014, which was based on the initial alpha spec.
 This paper gives a taster of DMN - what it looks like, how it fits in with the
Business Process Model and Notation (BPMN) and how it can be used to analyse
real world situations. It is based on learnings from the spec so far - a tough read,
but the specs themselves are not necessarily designed for 'business' use.
 It's not a comparison of DMN to other notations or models - DMN is a standard
and primarily a notation; other approaches provide both a notation and a method,
such as Knowledge Partners International’s (KPI) ‘The Decision Model’ (TDM). For
example, DMN will prescribe a format for Decision Tables, but TDM has principles
that underpin how tables should be constructed, normalised etc.
 It's not an in-depth review of the full scope of DMN - DMN's got a lot of moving
parts - predominantly this paper looks at the graphical notation and the
modelling of Decisions using Decision Tables, but, there's more to the scope than
just Decision Tables.
 It’s not a history of DMN or decision modelling in general – it provides a brief
overview of what decision modelling is, but there’s many other sources of
information that can provide a more detailed background to the interested reader
(see Further reading).
 It’s not about tooling for DMN – it’s looking at the notation from an analysis
viewpoint; this paper specifically excludes any discussion on tools that support
DMN, either now or in the future.
Business Rules Subject Matter Experts, Business Analysts, Project Managers, Enterprise
Architects, Testers, IT Developers.
Objective
To provide a view on what DMN is and how it might be used as part of the business
analysis toolkit.

Definitions of a decision:
decision /dɪˈsɪʒ(ə)n
Noun
 a conclusion or resolution reached after consideration: “I’ll make the
decision on my own”; “the editor’s decision is final”
 The action or process of deciding something or of resolving a question:
“the information was used as the basis for the decision”
late Middle English: from Latin decision(n-), from decider ‘determine’
(Oxford Dictionaries, n.d.)
 the act of determining an output value (the chosen option), from a number
of input values, using logic defining how the output is determined from
the inputs.
(Object Management Group, 2014)
Decision, or business, logic:
represents the ‘rules of the business’ that operate perhaps thousands of times a
day in service to customers and partners. Yet many … are buried in program code
or in people’s heads. They are an important consideration in implementing
change and delivering enterprise agility.
Even when captured separately … they are managed as a catalog or list of
business rule statements… They are not managed in a common model as data is
managed today.
(von Halle & Goldberg, 2010)
The primary goal of DMN is to:
provide a common notation that is readily understandable by all business users,
from the business analysts needing to create initial decision requirements and
then more detailed decision models, to the technical developers responsible for
automating the decisions in processes, and finally, to the business people who
will manage and monitor those decisions.

DMN creates a standardized bridge for the gap between the business decision
design and decision implementation.
DMN notation is designed to be useable alongside the standard BPMN business
process notation.
(Object Management Group, 2014)
Decision modelling provides a way of packaging rules into discrete, modular, and
manageable pieces. It separates out declarative rules from procedural behaviour, that is,
process models are simplified by removing those things that are not actually governed
by a specific order. Rather than complicated configurations of ‘decision points’ in
traditional flowcharting terminology or ‘gateways’ in BPMN terminology, the conditions
that have to be met are governed by their own model, which makes them infinitely more
responsive to change.
Appreciating that the evaluation of conditions are often not governed by a specific
sequence is the first major cultural mind-set shift in adopting decision modelling. There
are times when sequence is hugely important for distinct reasons and that is
demonstrated during the worked example in the body of this paper. However,
understanding how they can be handled as a unique asset really unlocks the power to
make those rules clearer and more responsive to an ever-increasing rate of change in
modern industry.

Contents
Introduction ....................................................................................................................................... 2
What’s covered? ................................................................................................................................ 2
What's not covered?......................................................................................................................... 2
Who should read this paper? .......................................................................................................... 2
Decision modelling ........................................................................................................................... 3
Worked example context ................................................................................................................6
The business process....................................................................................................................6
DMN - Decision Requirements....................................................................................................... 7
DMN - Decision Logic.......................................................................................................................9
First Decision – ‘Applicant Demographic Suitability’............................................................. 10
‘Applicant Demographic Suitability’ Decision Model ..........................................................11
‘Applicant Years of Age Calculation/Applicant is Existing Customer’ Decision Model 13
‘Applicant Private/Student Credit Card Demographic Suitability’ Decision Model......14
Second Decision – ‘Applicant Credit Card Eligibility’ .............................................................15
‘Applicant Credit Card Eligibility’ Decision Model...............................................................16
‘Applicant Balance Transfer Credit Card Eligibility’ Decision Model................................17
‘Applicant Credit Score’ Decision Model...............................................................................18
Expressing Decision Logic without invoking a Business Knowledge Model .....................19
Worked example conclusion..........................................................................................................21
Business glossary, and data modelling .......................................................................................22
Final observations ...........................................................................................................................23
References ....................................................................................................................................... 24
Further reading................................................................................................................................ 25
Decision modelling......................................................................................................................25
Business process modelling ......................................................................................................25
About the author............................................................................................................................. 25
Disclaimer .....................................................................................................................................25

The example is something relatively straightforward - a credit card application. It's not
dissimilar to the concepts used in part of the worked example in the Section 10 of the
spec.
The example is based on some of the information from the public website of one of the
UK's banks. Other information has been assumed, for example, credit scoring because it's
highly complex and not readily available. A BPMN 2.0 Process Model has been drafted to
provide the context (it's a stub - the process in practice would only be considered
successfully complete when a card was issued) – see Figure 1.
The business process
Process brief
An Applicant submits an Application for a credit card, which is received by a member of
the Credit Card Processing Team. The information is recorded and basic information about
the Applicant assessed to determine whether it is worth requesting their Credit File from
an external Credit Reference Agency. If it is, then the Credit File is requested and the
Applicant is assessed based on specific criteria for the card for which they've applied.
The process ends successfully when the eligibility for the card has been determined and
the Applicant informed of the result.

Figure 1: BPMN process model showing the receipt and assessment of a Credit Card Application,
with two key Decisions
The Business Rule Tasks (small table marker in top-left corner of the activity) denote that
Decisions are required at those points.
From an analysis perspective, DMN's got two main bits: Requirements and Logic. The
Decisions required in a given 'domain' are represented in a Decision Requirements Graph
(DRG). That could get quite big. So the DRG itself can be made up of one or
more Decision Requirements Diagrams (DRDs).
As mentioned above, the process in the real world would probably continue until the
card is actually issued. There are also other elements associated with the credit card
once it is issued: statements; interest charges; defaults; closure etc. All of the Decisions
across those processes would represent the entire domain and thus a DRG.
However, the scope of this paper looks at the requirements for ‘Credit Card Eligibility’
and thus the DRD for that process scope. There are two key Decisions from the initial
process analysis:

 'Applicant Demographic Suitability' and
 'Applicant Credit Card Eligibility'.
The analysis starts at that point and begins to define the Decision requirements. In
summary, it looks at the key bits of information that need to be evaluated by talking to
the project stakeholders and establishing how they might be packaged to make those
Decisions more manageable, resulting in the DRD shown in Figure 2.
Figure 2: Shows the DRD for decisions required in assessing a credit card application
In practice, the diagram was developed iteratively along with the logic and the process,
but that evolution is not in the scope of this paper.
Figure 2 shows that:
 the two main Decisions require other Decisions as their inputs, along with
other Input Data;
 the logic for those Decisions are contained in the Business Knowledge
Models that they invoke. Those Business Knowledge Models may be
governed/owned by Knowledge Sources.

There’s some relatively ‘techy’-sounding terminology there, so in an attempt to simplify:
The Decision provides the output information, the thing that’s of interest, but it has to
ask a Business Knowledge Model to work it out (usually, but see Expressing decision
logic without invoking a Business Knowledge Model). Put another way, the Business
Knowledge Model could be seen as the script writer for the Decision speaker. The
speaker tells people what they need to know (hopefully) but he's called upon his script
writer to evaluate the necessary information (Input Data) and present it in a format
where that output can be communicated as required to his audience.
Referring back to Figure 1, the diagram shows that the Data Items associated with the
User and Service Tasks match the Input Data in the DRD.
The next step is to get into the detail of the logic that sits behind the Decisions:
 DMN has created a standard for Decision Tables;
 a Decision Table is a Business Knowledge Model, but not all Business Knowledge
Models are Decision Tables.
What that means is that a TDM Rule Family View could be used as a Business Knowledge
Model (von Halle & Goldberg, 2013). Other examples include the use of an analytics
model or a natural language expression.
DMN has also created a standard language for expressing Decision Logic called FEEL
(Friendly Enough Expression Language), although that depends on who you are as to
whether it's friendly enough for you! As many of the following examples as possible are
expressed using FEEL but it can be hard going using the spec alone. This paper does not
go into a great deal of detail on FEEL.

First Decision – ‘Applicant Demographic Suitability’
Figure 3: portion of the process model highlighting the first Decision
Figure 4: The portion of the DRD showing that Decision

From the process, there are two main outcomes defined by each gate following the task:
‘Suitable’ and ‘Unsuitable’.
To arrive at that conclusion, the partial view of the DRD in Figure 4 shows that it depends
on:
 two other Decisions;
 two lots of Input Data and;
 a number of Business Knowledge Models.
The reason that this is a separate Decision rather than just forming an overall input to the
eligibility assessment is because there are basic criteria that need to be met for a given
credit card product before putting a footprint on a credit report. This talks back to the
point made at the start of the document where sequence does become important for
distinct business reasons.
‘Applicant Demographic Suitability’ Decision Model
Figure 5: A Decision with an invoked Business Knowledge Model in the form of a Decision Table
Figure 5 shows both the Decision itself and the Decision Table invoked by it. The details
of the structure are broken down below but, in summary, the Decision Logic is
encapsulated in Boxed Expressions.

The type of Boxed Expression for the Decision is a Boxed Invocation - it's the speaker
asking his script writer to do what he does. It passes the required Input Data into the
Business Knowledge Model.
The red numbers against Figure 5 show a number of components associated with the
model:
1. Applicant Demographic Suitability - the Decision itself.
2. Applicant Demographic Suitability Table - the Business Knowledge Model that
the Decision 'invokes'; in this case, a Decision Table.
3. Boxed Expression - this whole structure at the top of the diagram represents a
Boxed Invocation (a type of Boxed Expression).
4. Applicant Years of Age Calculation – another invoked Business Knowledge Model
that will return the required outcome into this model.
5. Applicant is Existing Customer Rules – as ‘Applicant Years of Age Calculation’.
6. Existing Customer Products Held with Lender - for the invoked Business
Knowledge Model 'Applicant is Existing Customer Rules', this defines the Input
Data that represents the logical input expression 'Existing Customer Products
Held with Lender' to that model.
7. Decision Table - this is a Single-Hit Decision Table with Hit Policy of First (the 'F'),
meaning that the output returned will be the first rule hit. These can be hard to
validate manually because it is so dependent on the order of the rows. A Decision
Table is also a type of Boxed Expression. The 'C' following 'F' says that the table is
complete1
, that is, all rules have been included in order to reach an outcome.
8. Input Data values – value under test provided where appropriate to the rule; a
dash means that the input value is irrelevant to a particular rule.
9. Input Expression domain values - an optional section used to show the valid
domain values where appropriate.
10. Output Data values – can be an absolute value, or the value can come from the
output of another decision. In this example, rows 3 and 4 are provided by
‘Applicant Private Credit Card Demographic Suitability’ and ‘Applicant Student
Credit Card Demographic Suitability’.
1
There is some justification for stating that completion should only be handled by an
appropriate tool, rather than allowing the analyst to judge when the table is complete
(Feldman, 2014)
Example
Applicant is 19, applying for a Student card but is not an existing customer. Row 2 would
be triggered, giving an 'Unsuitable' outcome.

‘Applicant Years of Age Calculation/Applicant is Existing Customer’
Decision Model
Figure 6: The two other Business Knowledge Models invoked by the Decision, providing input data
to the Decision Table
The Decision Table takes two of its inputs from two other Business Knowledge Models.
Rather than Decision Tables, these use Boxed Contexts. These are good for calculations.
This example highlights that a company will most likely derive the ‘Applicant's Years of
Age’ - applications typically ask for a date of birth instead of years of age.
These models return the required Input Data to the Decision Table from the previous
figure. The numbers in red show:
1. Boxed Context - the structure represents a Boxed Context (another type of Boxed
Expression).
2. Natural language expression - a natural language expression that defines how the
‘Years of Age’ is calculated.
3. Output - the value returned by the expression. This will then be used as the Input
Expression in the 'Applicant Demographic Suitability' Decision Table.
Example
An Applicant applies for a Private Credit Card, they are an existing customer and they
have mortgage borrowings of £350,000 and a sole annual income of £200,000. Both rows
1 and 2 will be triggered, where both outputs are 'Suitable'.

‘Applicant Private/Student Credit Card Demographic Suitability’ Decision
Model
Figure 7: The two Decision Tables required for the logic assessing Student and Private Credit Card
Demographic Suitability
Another couple of Decision Tables for the two Decisions that are 'required' by the main
'Applicant Credit Card Demographic Suitability' Decision (the Boxed Invocations for the
Decision itself have been left off this example).
These are both Single-Hit Decision Tables, the first with Hit Policy of Any. This means
that any rule can be hit during the Decision, but in the event that multiple rules are hit,
they will only return the same conclusion. So if the Customer has both £150k in annual
income AND £350k in outstanding mortgage borrowings, both rules 1 and 2 will be hit,
but will only return "Suitable". The second is Unique, meaning no overlap is possible and
rules are exclusive.
The outputs of these two tables are required as Input Expressions in the 'Applicant
Demographic Suitability' Decision Table.

Second Decision – ‘Applicant Credit Card Eligibility’
Figure 8: portion of the process model highlighting the second Decision
Figure 9: Partial view of the DRD showing the Applicant Credit Card Eligibility decision and its
requirements
From the process in Figure 8, there are two main outcomes defined by each gate
following the task: ‘Eligible’ and ‘Ineligible’.

The second Decision uses the Credit File obtained from the external Credit Reference
Agency. This information is used in the ‘Applicant Credit Score Table’ Business
Knowledge Model, which is dictated by the Credit Policy of the Lender (shown as a
Knowledge Source).
‘Applicant Credit Card Eligibility’ Decision Model
Figure 10: The Decision and its invoked Decision Table to determine the eligibility of the Applicant
for the Applied Card
1. Single-Hit Decision Table with Hit Policy of Unique - only one rule can be hit
during the execution of the Decision.
2. Limited set of Input Data - some of the criteria were established in the first
Decision; on that basis, the process would never have got to this point without it
the Applicant being a fit for the target demographic. So that Input Data is not
required by this Decision.
Example
Applicant is applying for a Balance Transfer card and they have a credit score of 570
resulting in an outcome of 'Ineligible'.

‘Applicant Balance Transfer Credit Card Eligibility’ Decision Model
Figure 11: The Decision Logic for the Applicant Balance Transfer Credit Card Eligibility decision.
As with the ‘Applicant Years of Age’, application forms usually get applicants to list their
address history, so this requires another expression to return the information. The
associated calculations have not been included here.
1. List of Input Data - application forms typically list address details and range of
dates for each, rather than the number of years being available as a specific item
of input data. Therefore, there needs to be an expression to derive the value using
that data.
Example
Applicant has a sole income of £15,000, hasn't applied for the card at any time in the last 6
months, has 5 years of address history and lives in France. Row 3 would be triggered with
an outcome of 'Ineligible'.

‘Applicant Credit Score’ Decision Model
Figure 12: Credit Scoring Multi-Hit Decision Table that aggregates the outputs together as a sum
Points to note on Figure 12:
1. This table is entirely fictitious - the numbers are arbitrary, as are the Input
Expressions, but the main purpose is to demonstrate the Multi-Hit Decision Table
with a Hit Policy of No Order (that is, the order in which the various values are
output from the table is of no consequence).
2. Ranges of values are shown between brackets - where the type of bracket
defines whether the first and last values shown are included in the range. Square
brackets indicate inclusion of both values.
3. Multi-Hit Decision Tables have an Aggregator - in this instance, Sum, which
means the output values are summed together. It is the summed value that is
used as the Input Expression to the 'Applicant Credit Card Eligibility' Decision
Table.
4. Available credit used > 100 - whilst this looks unusual, technically it is possible for
all credit available to have been used and to have exceeded the limit as well.
The input and output values in a DMN Decision Table are specified by FEEL and that has
been included in Figure 12. Ranges of values are of particular interest and FEEL

accommodates all combinations of start and end points being included/excluded in the
expression.
Expressing Decision Logic without invoking a Business Knowledge
Model
The spec states that:
In most cases, the logic of a decision is encapsulated into business knowledge
models, and the value expression associated with the decision specifies how the
business knowledge models are invoked, and how the results of their invocations
are combined to compute the output of the decision. The decision’s value
expression may also specify how the output is determined from its input entirely
within itself, without invoking a business knowledge model: in that case, no
business knowledge model is associated with the decision.
(Object Management Group, 2014).
What that means is that it is possible, should you wish to do so, to include a Decision
Table within the Decision itself, rather than in a separate model. Reusability is the
primary goal for this approach. Expressing logic in a separate Business Knowledge Model
allows that logic to be reused in multiple Decisions, potentially with different Input Data.
So there could be two Decisions that use the same Business Knowledge Model, but it
might be evaluating the same logical information using different physical data sources.
Figure 13 shows an alternative way of expressing the ‘Applicant Credit Score’ Decision.
Example
Example: Applicant has defaulted once in the last 12 months, has not declared bankruptcy,
has 4 years with their bank and has used 67% of their available credit. This triggers rows 1,
6, 9 and 12, giving individual scores of 100, 250, 250 and 150. This is aggregated to give an
overall score of 750.

Figure 13: Alternative expression of the Decision, showing the Decision Table as part of the
Decision. Note that there is no longer a reference to the table underneath the Decision name.

Imagine now if all of the rules defined in the previous tables had been built as gateways
within the process? Each Input Expression would probably have needed its own gateway
and ensuring coverage for each combination of conditions would have been
exceptionally difficult. As it stands, there are three key points that have been
demonstrated by this example:
 Simplified process – two tasks have taken the place of numerous gateways. This
allows the process model to focus on its primary objective: the flow of activity.
The logic that governs which path should be taken from a gateway is now
encapsulated in the Decision Tables.
 Processes driven by decisions – processes can be architected to focus on
reaching outcomes of key Decisions; the process becomes about how you ensure
those Decisions have the right data at the right time.
 Flexible rule management – additional criteria for evaluation become another
column in a Decision Table. Additional values associated with the Input
Expressions that need to be assessed become new rows. Rules that are not best
managed through a table can take other forms, such as a natural language
expression.

Business terms and glossaries have not been covered in this paper. These are still a
critical aspect of expressing Decisions effectively. However, a lot of the modelling
practices that are part of TDM have been used in this worked example in naming the
Input Expressions (Fact Types in TDM-speak). DMN doesn't mandate a glossary; this is
potentially because there is an expectation that the other OMG spec, 'Semantics of
Business Vocabulary and Business Rules' (SBVR), provides the appropriate model.
Consideration of SVBR is out of scope of this paper.
In order to come up with the meaningful, accurate, names for the Input and Output
Expressions, the following portion of a Concept/Fact model was produced:
Figure 14: The concepts defined to help guide the naming of the input and output expressions
This model helped in defining the in-scope concepts and their relationships between
them in order to properly qualify the terms used.

As mentioned at the start, the intention of this paper is to provide a view of DMN, not
critique it. However, a few final observations have been included below:
 Decision domain view - providing a graphical Decision-oriented view of the
domain has a huge benefit. Whilst a lot of Decisions are executed as part of a
process, understanding the full context in which a decision is made is impossible
without reference to that process. By providing a DRG and associated DRDs, there
is now a specific view of Decisions that will speak more appropriately to a specific
demographic of stakeholders.
 Decision Table flexibility - the flexibility of the types of tables is beneficial for
handling different scenarios, particularly in terms of the different Hit Policies for
Single-Hit Tables and the Aggregator for Multi-Hit Tables.
 Potential Decision Table complexity - whilst the flexibility of the Decision Tables
is a plus, it's also a drawback, particularly to business usability, because the way in
which a table is read is down to people spotting the one-character indicator in
the top-left of the table. They've also got to know which of the Hit Policies the
indicator belongs to, although the Aggregator at the bottom of the table should
help that. Tool vendors may make their own decisions as to how many types of
decision table will be supported. In this paper, only Decision Tables that are rules-
as-rows have been considered; it is also possible to have rules-as-columns as well
as Cross-tab.
 Terminology - 'invocation'; 'boxed <insert name here>' may provide a cultural
challenge to adoption, as the terminology may be seen as too ‘techy’.
 Method and style - as described, the example in this paper has been produced via
learning from the spec, but a big part of doing the decomposition of the decisions
was based on applying the principles and practices from TDM. A standard
notation is good, but without guidance on how best to apply that notation, there
are inherent risks to its effective use in industry. For example, most of the
Decision Tables in this paper were created using 3 Input Expressions. However, it
would have been simple to create very large tables in terms of rows and columns
and this will be the most likely first step for the new person attempting this
notation; large tables are inflexible and unmanageable. What DMN will need is
something akin to the Method & Style approach used by Bruce Silver for BPMN.
However, this is all based on the beta spec – the development between BPMN versions 1
and 2 was huge, so there is a lot of work that will be done over the next few months and
years to really bring DMN to fruition.

Feldman, J., 2014. Another DMN Decision Model (executable!). [Online]
Available at: http://openrules.wordpress.com/2014/01/08/another-dmn-decision-
model-executable/
[Accessed 20 May 2014].
Object Management Group, 2014. Decision Model and Notation. [Online]
Available at: http://www.omg.org/spec/DMN/1.0/Beta1/PDF/
Oxford Dictionaries, n.d. Decision. [Online]
Available at: http://www.oxforddictionaries.com/definition/english/decision
von Halle, B. & Goldberg, L., 2010. The Decision Model: A Business Logic Framework
Linking Business and Technology. 1st ed. Boca Raton: Auerbach Publications.
von Halle, B. & Goldberg, L., 2013. The OMG Decision Model and Notation Spec (DMN) and
The Decision Model (TDM). [Online]
Available at:
http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView
/articleId/2757/The-OMG-Decision-Model-and-Notation-Spec-DMN-and-The-Decision-
Model-TDM.aspx

Decision modelling
 DMN LinkedIn forum – many of the early discussions were held on this forum and
it is a great resource for getting in touch with the DMN submitters, and learning
more about the standard.
 The history of modelling decisions using tables – first part in a three-part series by
Professor Jan Vanthienen from the University of Leuven.
 List of publications on Decision Tables, Tabular Decision Models, and Business
Rules, again by Professor Jan Vanthienen.
 Decision Management Systems – ‘a practical guide to using business rules and
predictive analytics’ is a book by James Taylor of Decision Management Solutions.
 Understanding business data using The Decision Model – a slideshare
presentation by Nick Broom on KPI’s ‘The Decision Model’, showing the different
concepts used in the model and its application in practical scenarios.
Business process modelling
 Bruce Silver’s ‘Business Process Watch’ blog – great articles on the latest views on
BPMN. Links to training courses using his ‘Method & Style’ approach
 BPMN Method & Style – widely recognised as one of the best authorities on how
to apply BPMN, this book is also the basis for Bruce’s training. This is the link to
the book on amazon.com.
Nick Broom is a Business Analyst of 13 years and has been a freelancer since 2005. He’s
delivered projects in a number of different business and technological environments.
Specialising in Business Process Modelling, and Decision Analysis, he has been the lead
analyst on a number of decision modelling projects with major clients in the UK.
He currently lives in York, UK and has been Director of Visionalysis Ltd since its inception
in 2011. For more information on Nick’s professional portfolio, see his LinkedIn profile.
Visionalysis Ltd is a company registered in England and Wales, providing independent
business analysis consultancy services.
Disclaimer
The author is not a member of the DMN committee or affiliated in any way, and has not
been financially compensated by any party for any of the content found herein. All
referenced works have been cited appropriately.

Decision model and notation (DMN standard explained. A worked example by Nick Broom

More Related Content

What's hot

Viewers also liked

Similar to Decision model and notation (DMN standard explained. A worked example by Nick Broom

More from Harmony

Recently uploaded

Decision model and notation (DMN standard explained. A worked example by Nick Broom