Decision Requirements Diagram

Goal

The diagram maps a complex business decision and breaks it into a network of sub-decisions, each of which is described, governed and maintained separately. It answers a question the logic of a single rule leaves aside: what does this decision need in order to be taken, which data, which knowledge, which authority and how do these pieces fit together. The deliverable is the diagram itself, the requirements layer of a decision model, onto which the detailed logic is later grafted.

Its value concentrates on two fronts. It separates the decision logic from the process flow, which lets one be governed without touching the other. And it supplies the skeleton of an executable model, the starting point of rule-based automation.

Usage

When to use it

• Complex decision to break down: split it into a network of sub-decisions described and governed separately.
• A large body of rules to organise: group them by decision for reuse and impact analysis rather than one unmanageable table.
• Decision buried in a BPMN process: pull the logic out of the flow so a business rule task calls it.
• Rule-based automation as the target: the DRD is the structural layer of a model a decision engine executes.
• A shared picture of a decision to reach: a drawing stakeholders can read that carries impact analysis across boundaries.

When not to use it

• A single atomic decision: one decision table captures it, the network adds nothing, reach for the decision table.
• A simple decision welded to the process: keep it in the flow, a separate model only adds complexity, reach for BPMN.
• Mostly behavioural rules (conduct, obligation): the DRD frame does not address them, reach for business rules analysis.

Description

The requirements graph and the diagram

DMN distinguishes two objects. The decision requirements graph (DRG) is the complete model: the whole set of decisions, data, knowledge and the dependencies that join them. The decision requirements diagram (DRD) is a view of it, complete or partial, the one that is drawn and shared. The DRD is one of the three notations BABOK groups under decision modelling, the one that works at the level of the network rather than at the level of a single rule.

Four nodes and three links

The drawing rests on four shapes, each carrying one type of element.

• The decision, a rectangle: it takes a set of inputs and draws an output from a defined set, applying a decision logic. It is what gets decided.
• The input data, an oval: a datum supplied to the diagram, the raw fact a decision consumes, an income, an age, an amount.
• The business knowledge model (BKM), a rectangle with its two top corners clipped: a reusable block of logic, a set of rules, a decision table or tree, even a predictive model, that describes precisely how to decide.
• The knowledge source, a document shape with a wavy base: the authority the logic is drawn from, a document, a regulation or a person.

Three links express the dependencies, and this is what makes the drawing a requirements diagram.

• The information requirement, a solid arrow, joins an input data to a decision or a decision to a higher-level decision it feeds. It is the backbone that breaks a complex decision into sub-decisions.
• The knowledge requirement, a dashed arrow, joins a business knowledge model to the decision that invokes it: that decision is taken by means of this logic.
• The authority requirement, a dashed line ending in a filled round head, joins a knowledge source to a decision or a knowledge model: that document or person is the authority over the logic.

Building the network

You start from the top decision, the one the scope calls for, then decompose it: each sub-decision that feeds it becomes a node joined by an information requirement, down to decisions elementary enough to be described by a single logic. To each decision you attach the input data it consumes, then the business knowledge that governs it and finally the source that knowledge draws its authority from. The resulting network breaks the complex decision into simpler blocks, each describable and governable on its own.

The DRD stops at the level of the network. The logic of an elementary decision, the rules that map input values to an output, sits in a decision table or a decision tree attached under the node. Drawing those conditions in the DRD itself is the commonest mistake: it confuses the two levels and clogs the diagram with detail that is not its own. Conversely, opening a DRD for an atomic decision one table captures is a ceremony that buys nothing: the network is justified only by decomposition or automation.

Separating the decision from the process

The DRD pairs with BPMN notation, and the division of roles is clean: BPMN models the flow, the sequence of activities, while DMN models the decision the flow invokes. In the process, a business rule task calls the decision, which lives in its own DMN model instead of scattering into a cluster of branches in the flow. The point lies in their rates of change: decision logic changes far more often than process structure, and pulling it out of the flow lets it be modified and governed without touching the process.

You'll find more detail in our BPMN tutorial.

This structure also serves automation. A DMN model is designed to be read by the business and executed by a machine: the DRD gives its skeleton, and the underlying tables, written in the FEEL expression language, carry a logic a decision engine runs directly. This is what makes DMN robust for rule-based automation, without ruling out manual decision or predictive analysis.

Three pitfalls come on top of confusing the levels and over-modelling. A documented model can give the misleading sense that the organisation decides coherently when it does not. Because a decision often crosses several organisational boundaries, getting the model approved takes an effort that must be planned for. And an automation is reliable only if the business terminology is defined clearly and in common: vague terms propagate into data-quality defects the engine will inherit.

AI considerations

Two uses hold. The first is the first draft: from a regulation or a written policy, a language model proposes an initial decomposition, candidate decisions, the data they seem to consume and the sources cited, which the analyst corrects instead of starting from a blank page. The second is the form check, mechanical and delegable: does each decision receive its input data, is each business knowledge model attached to a decision and an authority, is the graph acyclic, is any input data left unused?

What does not delegate belongs to meaning. Settling that an element is a sub-decision rather than merely a datum engages an understanding of the business. Identifying the source that holds authority, telling the applicable regulation apart from a document that is only a commentary on it, takes knowledge of the frame. And deciding that a decision must be automated or stay with a human is a choice of accountability no model carries on the organisation's behalf.

Examples

The concept the drawing makes visible is the assembly of the four shapes and three links on one small network: a decision, its input data, the knowledge that governs it and the source of that knowledge. The decision chosen is a household's eligibility for the individual reduction of health-insurance premiums, the cantonal subsidy provided for by the LAMal.

The decision "Determine subsidy eligibility" sits at the centre of the network. It consumes two input data, the relevant income in CHF and the household size, and rests on the "Cantonal subsidy scale", a business knowledge model. That scale is itself a decision table, an income threshold per household size, whose logic is detailed in a decision table attached under the node rather than in the DRD: this is the separation of levels, the diagram carries the network and the node refers out to its logic. The scale draws its authority from the "Cantonal regulation on premium reductions", the network's knowledge source, which makes impact analysis immediate: a change to the regulation ripples along the links up to the decision. Five nodes are enough to carry the four types of element and the three types of link.

Visualizations

The shape carries the meaning. A node's type is read in its silhouette, the rectangle for a decision, the oval for an input data, the rectangle with clipped corners for a business knowledge model, the wavy base for a source. A dependency's type is read in the line, solid for an information requirement, dashed for a knowledge requirement, dashed with a round head for an authority requirement. A reader who knows DMN reads the network without a legend.

Cost

Tooling

A whiteboard is enough for a first sketch: a few nodes and their links fit on a sheet and are corrected on your feet. General-purpose diagramming tools, diagrams.net, Lucidchart or Visio, carry DMN stencils and give a clean drawing, but they stop at the drawing: the link to the logic tables and to execution has to be made elsewhere. Dedicated DMN platforms, such as Camunda's open-source DMN editor, Trisotech, Signavio or Red Hat Decision Manager, hold the DRD as the top layer of an executable model: you descend from a decision node to its table, validate the model, then deploy it to a decision engine that runs it. These tools usually connect with a BPMN modeller, so that a business rule task in the process calls the modelled decision directly.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.17: the decision requirements diagram among the three notations of decision modelling, the list of its elements and the stated strengths and limitations of its use.
• OMG (Object Management Group), Decision Model and Notation (DMN), version 1.5, Clause 6 (Requirements): the decision requirements graph and diagram, the four element types (decision, input data, business knowledge model, knowledge source) and the three requirements (information, knowledge, authority) that link them.