The Community Blog for Business Analysts


Quick Intro to Decision Model and Notation - DMN

Decision Model and Notation in short DMN is a novel way to model business decisions. DMN allows capturing and modeling business decisions in a way that is easy to understand with business people and subject matter experts. It is a combination of:

  1. Decision requirement diagram – DRD
  2. Decision table
  3. Boxed expressions
  4. Friendly Enough Expression Language – FEEL

Decision Requirement Diagram (DRD)

This is a graphical model that allows modeling dependencies between input data, decision, business knowledge and knowledge source.

DRD sample

In DRD, the arrows show the dependencies between different nodes in the model. To put it in a simple way, you can read it as if the output result of some nodes will be passed as the input of the other nodes.

In the table bellow, all the elements on a DRD model are illustrated:

Decision Dmn decision.png The act of determining an output from a number of inputs, using decision logic which may reference one or more business knowledge models.
BusinessKnowledge Model Dmn business knowledge model.png A function encapsulating business knowledge, in the form of business rules, decision table or analytic model. Some of the tool may not support this element. In such case the decision logic is directly linked to the Decision rather than the business knowledge model.
KnowledgeSource Dmn knowledge source.png The authority for a business knowledge model or decision.
Input Data Dmn input data.png Information used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model.
Information Requirement Dmn information required.png Information – input data or decision output – required for a decision.
Knowledge Requirement Dmn knowledge required.png The invocation of a business knowledge model.
Authority Requirement Dmn authority required.png Showing the knowledge source of an element or the dependency of a knowledge source on input data.

Decision Table

In decision model and notation, the Decision Table is a tabular form that models rules based on conditions and actions which they are also called inputs and outputs. Decision Table is the default type of modeling business rules in DMN. But if your tools support other ways to model business rules then you can freely use them along side with decision table.

decision model and notation

Boxed Expressions

In Decision model and notation (DMN) are a simple two column table and effective way to model business formulas, calculations, values and expressions. And then you can share them across multiple decisions and logic.
decision model and notation

Boxed expressions simply allows modeling: constant, values, invocation, formulas… Boxed expressions allows putting together building blocks of logic (i.e. decision table, natural language, flow…) and reuse them over and over again.

Friendly Enough Expression Language

In decision model and notation, FEEL is an expression language for business people. FEEL define a syntax for expressing conditions, actions and formula. Consider FEEL like excel formulas that they allow you formulate your thinking about a domain in a context. FEEL is designed to allow ease of use by business people and subject matter experts.


There are benefits of using decision model and notation over the traditional business rules approach. In the business rules approach, very soon you start thinking about the business rules which they are more about the logic implementation. But decision approach provides a more high-level abstracted layer that allows you to see the big picture first rather than diving deep into implementation and losing the context and overview of the solution.

This change of approach:

  1. Allows scaling business rules in more manageable, reusable visual approach across applications and processes.
  2. Allows better communication between business, domain experts and IT by enabling a productive involvement of business people and subject matter experts.
  3. Allows clearly define decision boundaries and expose the decision as a service with a click!

If your tool supports simulation and executionerror checking at design time and runtime with debugging capability then you will not miss anything from business rules approach, but also will have a better way to reuse and scale your business rules in a systematic way.

Submitted by: FlexRule

This entry was published on Aug 10, 2016 / Arash. Posted in Business Rules, Systems Analysis, Business Analysis, Domain Modeling. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  29 members liked this article

Related Articles


Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC