1 - Creating a Decision Requirements Diagram

Last Updated: May 07, 2018 06:51AM PDT
At the core of DecisionsFirst Modeler is the decision requirements diagram. These diagrams allow you to describe how, exactly, your organization wants to make a decision or currently does so. There is also a short demo
​From the home page, click on the New Decision Requirements Diagram .

Palette​A new tab will open. On the left hand column of the page are the three objects you can create from the diagram. These objects are Input Data (oval), Decisions (rectangle) and Knowledge Sources (document). Objects are solid shapes and are created in the database so they persist independently of the diagram. Sketch Objects, seen in the Sketch Object tab, are open shapes and saved only with the diagram so are not available to other users or other diagrams (more on this later). Connectors create the dependencies between objects that are stored in the database.

You can create as many of these diagrams as you like – multiple perspectives, “as is” and “to be”, overview and details, whatever works for you. Decisions and other objects can appear on many diagrams and the DecisionsFirst Modeler database stores all the links you make on all the diagrams.

Let’s get a decision requirements diagram created. Using the properties fields on the right hand side, name the diagram “Support Decisions.”

Creating Decisions
The first step in any decision requirements modeling exercise is to brainstorm the set of decisions you think you are going to be working on and put them on a diagram. For BigCo, four decisions have been identified in the support and service area of the business - Determine Refund Eligibility, Determine Return Eligibility, Calculate Price and the new one Select Marketing Offer. Let’s go ahead and create these four decisions.

Select the Decision Object and drag it onto the diagram. On the right hand side of the diagram enter its name and description next to the decision icon . Name the decision “Determine Refund Eligibility” and enter the description “Customers often request a refund to a fee on their bill and a decision must be made each time as to whether to refund all or part of the fee. #support #tutorial” This decision now exists on the diagram and in the database. Click the save button to save the diagram.

TIP: You will notice that we added "#support #tutorial" to the description. This tags the object with these two tags. You will also notice that subsequent objects will also contains tags. You don't have to include tags in descriptions and you can include one or more if you do - simply type the tag text anywhere in the description field. Additionally, tags can be used in object titles. These tags can be used in search, as we will see later, to help you find the objects you are looking for. This is particularly helpful once you have multiple projects in the database. Adding #tutorial to every object you create will mean you can rapidly find the tutorial objects in the future once your database contains your own projects.

Repeat this sequence to create the other three decisions. You will want to move each Decision as you create them so they don't overlap:
Name Description
Calculate Price When an order is defined a price must be calculated that applies volume, promotional and customer discounts as appropriate. #tutorial
Determine Return Eligibility When a customer requests a return it must be assessed to see if a return is allowed or not. #support #tutorial
Select Marketing Offer Every time a positive or neutral interaction happens with a customer BigCo wants to make a marketing offer to cross-sell or up-sell them. #marketing #tutorial

When you are done you should see four decisions on your diagram.

TIP: When you are doing this for your own decisions, remember to focus on repeatable decisions. You can use DecisionsFirst Modeler to create models for one-off decision making (“should we drop this product line” for instance) but it is primarily designed for modeling the approach you want to take to a repeatable decision such as those listed for the tutorial.

Before we do anything more to this diagram, let’s introduce a few of the diagram features:
  • You can make any of the shapes larger or smaller by selecting a node and then dragging one of its corners
  • You can move nodes around by clicking on them and dragging the node itself. If you drag to the right or bottom edge the diagram will enlarge itself so you can keep dragging
  • If you have a single node selected you can edit its name or description using the properties on the right hand side.
  • You can select several nodes by dragging a box around them and you can then move the group by clicking and dragging any of the members of the group
  • Clicking anywhere in the diagram not on a node deselects all the nodes
  • You can use the + and – buttons to zoom in and out on the diagram. You can also select a zoom level from the button next to them.
  • You can select any object and click the edit button to open the object for editing
  • You can save the diagram to a PNG file using the Export to Image button

Creating Input Data
Next we will add some Input Data. Making Decisions requires information – information about the case being decided, reference information, information about customers and more. While DecisionsFirst does not model databases, it does allow you to document the sources of information available so you can identify which input data are relevant to which decisions. For BigCo relevant input data include Product Catalog, Issues List, Orders, Customers, Bills and Marketing Offers. Right now we will create one of these Input Data from the diagram. In the next lesson we will create the rest via a bulk create feature.

Drag and drop one Input Data Object onto the diagram. On the right hand side of the diagram enter the name "Shipments" and the description "Shipments made to customers #tutorial" next to the Input Data icon .

Tip: Be fairly granular with the input data you use. Many of BigCo's input data identified here would be in the same database but they are modeled separately to make it clear which information is used where.

Creating Knowledge Sources
To make a Decision we must know how to make it. We must know what steps to take, how to pick the right option and so on. This knowledge is modeled in DecisionsFirst Modeler in terms of knowledge sources or collections of know-how. These can be linked to Decisions to show which know-how is needed to make which decisions. For BigCo relevant knowledge sources include Return Policy, Product know-how, Customer Loyalty, Customer Propensity to Accept, Service Expertise and State Return Regulations. Right now we will create one of these Knowledge Sources from the diagram. In the next lesson we will create the rest via a bulk create feature.

Drag and drop one Knowledge Source Object onto the diagram. On the right hand side of the diagram enter the name "Return Policy" and the description "The company's policy for returns - who can return what #support #tutorial" next to the Knowledge Sources icon .

Creating Requirement Links
A Decision requires something when it is required in order to make the Decision at all or to make it accurately. For instance, we cannot decide who is eligible for a return without access to information about shipments made to customers so our Determine Return Eligibility Decision clearly requires the Shipments Input Data. Similarly we cannot make this decision unless we understand the return policies we have in place so our Decision also requires the Return Policy Knowledge Source. These are the kinds of requirements we can build on the diagram.
In the palette are two links: A solid arrow with a point that represents information requirements and a dashed line with a round end that represents authority requirements . Information requirements are used to show that a decision requires information. For instance a decision might require the information in an input data. Authority requirements are used to show where the authority for something comes from. For instance the authority for how to make a decision might be the knowledge recorded in a knowledge source.

To create a link you simply click the appropriate button to enter link drawing mode and then drag from the source of the requirement to the target of the requirement to create a link. The link will have two ends – the one with the arrow or circle should point to the object that has the requirement and the blunt end should rest on the object that is required. So, for instance, if a Decision requires an Input Data then the blunt end is at the Input Data end and the arrow at the Decision end.

​Let's create requirements from the Shipments input data to the Determine Return Eligibility decision and from the Return Policy knowledge source also to the Determine Return Eligibility decision. Click on button with a solid line and arrow to start creating an Information Requirement then mouse down over the Input Data and drag to the Decision before releasing. This creates a requirement from the Decision to the Input Data. Click on the button with a dashed line and circle to start creating an Authority Requirement then mouse down over the Knowledge Source and drag to the Decision before releasing.

Note: Make sure your links are snapped into place so when you drag the objects the links stay connected. The object border will be highlighted in red when snapped. The snap creates a link in the database.

The Support Decisions diagram now looks like this:

(You can also create new objects from the Create New toolbar on the home page. This creates an object in the database that can be associated with one or multiple diagrams.)

In the next Tutorial, we will use the Bulk Create feature to add additional knowledge and input data, use the Search feature to add these to the diagram, and add additional requirements.

<Tutorial Overview> <Next>

Contact Us
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found