DRA

DRA in Design

2010-09-11T09:04:00.006+01:00

Design tends to be the prerogative of techies – and is therefore elegant from the bottom up: it uses the computational resources very efficiently. Good design should also be elegant from the top down: the structure of the solution should be parsimonious and reflect the structure of the decisioning. Bottom-up design is very specific to the platform, so it is not possible to discuss it in this platform-neutral forum anyway. Top-down design, however, can be purely functional. This posting suggests how the decisioning structure exposed in the DRD can be used as the basis for designing a decision flow and an object model.

Designing a decision flow

For each decision point, identify in the DRD all the top-level decisions and all their sub-decisions. These, together with their dependent knowledge and data nodes, comprise a "sub-DRD" defining the decisioning to be implemented in the decision service to be called at that decision point. Note that if any decision occurs in more than one decision point you have two design options: the results can be persisted externally after the first decision point and provided to the second decision point as data, or the decision can be evaluated at both decision points. Which approach you choose will depend on a number of factors, including whether the data might change between the decision points.

Having prepared the sub-DRD for each decision point, strip it of all nodes except the decisions. The arrows between these nodes specify a partial ordering of the decisions to be evaluated at this decision point. This reduced network can be simplified further by removing tautological dependencies: whenever two decisions are connected both directly and indirectly, remove the direct connection. The partial ordering below is for the example DRD used in previous postings.

Partial ordering of decisions

Now linearise this partial ordering by choosing an arbitrary sequence for parallel nodes. The result is a decision flow for a decision service providing the decisioning required at the decision point.

One possible decision flow

This of course assumes you need a decision flow, which is essentially a procedure for ordering decisions in a forward-chaining environment. Excuse my bias as a Blaze user! If you are working in a predominantly backward-chaining environment this may be unnecessary: the dependencies between the decisions in the DRD may be used directly for chaining.

Designing an object model

During rule discovery the business terms required by the rules will have been identified and mapped to nodes in the DRD. Input data will belong to data areas; derived values will belong to decisions. This natural structure should be used for the object model, because it is a whole data area or decision which is relevant or not to any particular decision point: that is the unit of re-use. The high-level structure below is based on our same example DRD. All the detailed data properties and decision results should belong to one of the terminal nodes in this structure.

A natural object model structure

When decision values are persisted externally they should be presented back to subsequent decision points in exactly the same structure (i.e. in decision objects, not data objects). This means that another decision using these values does not have to know whether they originated "locally" or from another decision point. A safe (but sometimes costly) approach is that all the decision results from each decision point should be presented to every subsequent decision point.

This will be the last of my series of postings giving a basic introduction to DRA. I hope it will be useful.

Rules Discovery

2010-02-10T11:58:00.006Z

The key to successful rules discovery is that all rules must be contextualized in specific business decisions. This statement may be seen as heretical by those who have signed up to the Business Rules Manifesto, but my concern here is with the practicalities of delivering decision services to a tight budget and timescale, not with the quixotic task of modelling the behaviour of an entire organization. So my advice is this: do not try to define universal rules which apply across all business processes and activities; establish only the specific rules required to make each decision which is in scope.

This is my fifth posting in this series, and I have only just got to rules discovery. That is as it should be: discovery does not lead the process but falls out of it. The scope of your decision management project has been agreed using DRAW and depicted on a DRD; you have planned the project by partitioning the scope into a number of iterations with discrete discovery tasks for all the knowledge nodes in each; you have built an empty prototype decision service to demonstrate the technical architecture is sound. Now you can start rules discovery, decision by decision, extending the functionality of the decision service as you go.

In any particular discovery task you are gathering only the knowledge required to make a particular decision at a particular point in the business process. This is what I mean by “contextualized”. So as part of the first task in my planning example you might be asking “What are the rules for deciding whether an application should be accepted, referred or declined at the post-bureau decision point?” This is a very specific question capable of being answered very precisely.

There is a substantial literature on the art of knowledge elicitation, and I don’t want to add to it, except to observe that a lot of the problems evaporate if the process is properly guided and constrained. In a nutshell, as you gather the rules you should ensure that they are:

Complete: the set is sufficient to make a decision in all possible scenarios
Consistent: either the rules are mutually exclusive (i.e. only one rule fires in any particular scenario) or there is some clear system for resolving conflicts (e.g. priorities associated with decision values)
Independent: the rules do not depend on each other or on the order of evaluation.

As I said in the last post, you should also be checking the scope:

The rules should only determine the values relevant to the decision
The rules should only use the data available to the decision in the DRD

If the client proposes rules which determine new decision values or use new areas of data, an extension to scope may need to be agreed.

All the above talks only about rules (well, that's what we like to talk about, isn't it), but typically many of the knowledge nodes on the DRD involve other forms of business knowledge: particularly calculations and analytic models. Calculations are very similar to rules in how they are harvested; in fact they could be represented as rules, although it is usually more convenient and closer to the business view to collect them as algorithms and implement them in functions. Analytic models are more interesting because they are the output of another Decision Management process: see Paul’s comment and my reply.

DRA in Project Management

2010-01-12T16:18:00.005Z

In the good old, bad old days of Knowledge Engineering, the “iterative approach" often meant in practice "keep adding rules until the client runs out of money". This mindset persisted as our field came to be called Business Rules, when there was a common assumption that one could simply gather whatever rules the "experts" considered pertinent, arrange them into groups, and deploy them as rule services. Now Decision Management (DM) has turned this deeply misguided idea on its head by stressing that one must first define the business decisions to be automated, before harvesting the specific rules to implement them (see for example James Taylor on "Using Decision Management to improve Requirements”).

Decision Requirements Analysis (DRA) formalises this top-down process, allowing a rigorous specification of the decisioning requirements at the outset of a rules project. The main benefit is improved project management: DRA results in better plans, less risk, and tighter control on scope.

Scope of supply

DRAW is essentially a scoping exercise, and should therefore be carried out as the very first task in a rules implementation project. The results can then be recorded in a document which will define the scope of supply, to be signed off by the client before any further work is carried out. Since it covers only the decisioning requirements (which may not be all the functional requirements) FICO calls this the Decision Definition Document (DDD). It contains the following sections:

Business Context: the background to the project including the goals of Decision Management
Decision Points: a description of the client’s business process, specifying the points at which decisions are required of rule services and the principal decisions to be made at those points
Decision Requirements: the Decision Requirements Diagram (DRD), supported by verbal definitions of all of its nodes (including estimates of size and complexity of knowledge and data nodes)
Scope: a statement of the scope of supply, defined as sets of nodes on the DRD, and illustrated with a diagram, as below.

Scope Boundary on the DRD

The DDD is a simple, brief document, but provides a very clear definition of the decisioning requirements, allowing the scope to be tightly controlled. This is not to prevent changes during the project but to allow them to be properly managed. Every harvested rule should directly determine one of the decisions in scope, belong to one of the knowledge areas in scope, and use only data provided by the data areas in scope. If rules are discovered which do not fit into these constraints, the agreed change control procedure should be followed to consider the cost of extending the scope to include the new decisions, knowledge areas or data. Provided a thorough requirements analysis has been conducted such changes should seldom be required.

Planning

Rules discovery is in itself one of the major sources of risk in a traditional rules project, because it is open-ended and often far too large to be managed as a single task. This risk cascades to many other tasks which are dependent on it. Introducing DRA before rules discovery allows the production of complete and detailed plans at the outset of a project, with specific discovery, development and testing tasks for each knowledge node on the DRD. The effort required for these tasks may be estimated using the information in the DDD.

DRA can also provide a higher-level structure to the plan. If a phased or iterative approach is being used, increments of functionality may be defined as sets of nodes on the DRD. The objectives of this partitioning are that:

Each increment can be delivered in one phase or iteration
Each increment provides some distinct functional benefit to the client
The increments are loosely coupled: i.e. there are few arrows between nodes in different increments
Each decision node is in the same increment as the knowledge node(s) it requires.

This example DRD shows the decisioning functionality partitioned into three increments:

Increments on the DRD

A typical project plan under RUP would then have the following high-level structure:

Inception: establish the scope of decisoning using DRAW; establish high-level technical and non-functional requirements; agree project goals, plan and governance
Elaboration: establish the detailed technical requirements and retire the most significant risks by building a simple "empty" prototype decision service integrating with the client architecture
Construction: over a number of iterations, gradually add increments of functionality to the prototype until the decision service is complete, performing rules discovery as required for each increment
Transition: perform user testing, training and handover.

DRA therefore allows us to achieve a new "iterative approach", more in step with mainstream IT project management principles, which is committed to the delivery of an agreed set of decisions within an agreed budget and timescale.

DRAW

2009-12-14T13:06:00.016Z

DRAW (Decision Requirements Analysis Workshop) is a structured workshop technique for defining the decisioning requirements for a rules project, using the DRD described in my last posting. There are two typical contexts for DRAW:

It can be carried out as a self-contained activity, to establish the resources required for a potential rules project (e.g. to establish feasibility, to prioritise alternative projects or to produce a road-map for multiple deliveries)
It can be carried out in the first few days of a rules development project, to define the decisioning requirements (as a Requirements task in waterfall, or an Inception task in RUP).

This posting can only offer a brief description, of course, but I will be happy to answer questions, and FICO offers training courses in DRAW and the surrounding methodology as part of our Operational Excellence programme [sorry - end of advert ;-)].

Resources

No special facilities are required by way of accommodation or software. The workshops can be held in any quiet meeting-room with a flip-chart and whiteboard. Interaction is improved if the participants sit around a table, rather than all sitting facing the leader as in a presentation. The DRD can be sketched on the board during the workshops, and drawn out formally later using any commonly available diagram editor (I use Microsoft Visio).

The success of DRAW is entirely dependent on the calibre and commitment of the people involved, so it is important that the right team is assembled for the workshops. I will assume that the project involves staff from two parties: a supplier and a client. These might be separate groups within the same organisation.

Supplier: Although DRAW can be carried out by a single consultant, it is better to have a second person as scribe, and I would recommend that the following staff are available at least part-time:

Project Manager: responsible for project planning, management of supplier staff and status reporting
Rules Analyst: responsible for defining the functional requirements and possibly for the rule service design
Technical Architect: responsible for defining technical requirements and technical architecture.

The Rules Analyst will lead the workshops, conduct the analysis and produce the outputs. The Technical Architect should ideally be present throughout, but must attend any meetings concerning data sources and interfaces. The Project Manager should be present for the initial meeting and for any decisions on scope.

Client: The client should commit to making the following staff available at least part-time:

Project Sponsors: ultimately responsible for the business success of the project
Project Manager: responsible for day to day project management, liaison and reporting
Operational Experts: contributing subject-matter expertise; instrumental in driving and fostering user acceptance and involvement
Business Analysts: responsible for business design and definition of functional requirements
IT Analysts: providing IT support, e.g. interface development, hardware configuration, environment preparation.

Most of the input will come from the Project Sponsors, the Operational Experts and the Business Analysts. IT Analysts should be available support the workshops and analysis as required, e.g. with data mapping and legacy systems expertise. The Project Sponsors and Project Manager must be present when the scope is agreed.

Scheduling

DRAW works best in small groups (6-10 people), rather than large workshops. You should start with one or more plenary workshops to draw out the top-level requirements, then pursue more detailed analyses with sub-groups or individual specialists as necessary. It is not necessary to explore the whole network with each person: individual areas of expertise or responsibility may correspond to different regions of the network. It is however a good idea to cross-check results with multiple staff: individuals will miss items and there may be differences of opinion which reveal important issues which need to be clarified. After the results have been analysed and documented, the draft DRD should be presented at a final plenary session for general agreement.

Although it is possible to carry out a very high-level DRAW in a single day, it is more typical for it to require a number of workshops over several days. A good approach is to set aside a week, but schedule only about half of the time; I usually schedule workshops for the mornings, leaving the afternoons free for overruns or follow-up work. Be flexible. It is unlikely you will be able to conduct all the interviews according to a pre-arranged schedule; as the network is revealed you may find it useful to contact and interview additional people.

In principle, DRAW consists of a standard sequence of stages:

Identify the decision points
Define the top-level decisions
Decompose the decisioning
Describe all the nodes in detail
Define the decision service boundaries.

These are described below. Of course, no real workshop will run quite this smoothly: things will emerge which require you to backtrack and modify or add detail to the results of previous stages. This is not a problem, so long as the basic principles are followed (for example, any decision, whenever it is added to the DRD, has to be defined and decomposed).

Stage 1: Identify the decision points

Start by inviting the client to describe their business process, and what they hope to achieve from this project. Try to understand the drivers: What transformations does the client intend to bring about in their business? What benefit do they hope to achieve through Decision Management?

Investigate in detail all the points in the business process where decisions will be required of decision services: these are the decision points. Give each decision point a name, and define:

The stage in the business process where this decision point occurs
The decision-making carried out at this stage
The intended role of the decision service in the decision-making
The role of any users or other system components.

Document the results using some sort of business process flow or workflow diagram, as in the example below. Here there are two decision points: Decide Pre-Bureau Eligibility and Decide Post-Bureau Status.

Decision points in the workflow

Stage 2: Define the top-level decisions

For each decision point, establish the decisions which the client requires to be made by decision services, expressed in the most general possible terms. Wherever similar decisions are made at multiple decision points, try to generalise the decisions across those contexts. Even if there are expected to be multiple decision services do not at this stage attempt to allocate decisions to particular services, just identify which decisions have to be made.

Give each decision a name, then establish the following:

A question which characterizes the decision, expressed clearly in natural language, with a defined set of answers
Any other results which are required to be returned with the answer
The decision points at which the decision has to be made, and any variation in the required decision across these.

In our example above, the first decision point makes the decision Is the application eligible?, and the second makes the decision How should we deal with this application?. The answers to both questions are ACCEPT, REFER or DECLINE, which are used to route the application appropriately in the workflow.

Stage 3: Decompose the decisioning

Now we can build our DRD. Start by drawing the top-level decisions exposed in stage 2 on the board as separate, unconnected boxes. In our example these are Is the application eligible?, and How should we deal with this application?. Then follow an iterative process. Choose any decision which has not yet been addressed, and ask the client: “What information is required to take this decision?”. Fully explore the following possibilities:

Business knowledge (guidelines, policies etc currently existing in human heads, documents or legacy systems)
Data (specific data describing the case or external reference data)
The results of other decisions (sub-decisions).

Add nodes to the DRD as required: knowledge, data or decision. Each new decision node should be defined like the top-level decisions and labelled with its question. It can then be addressed in its turn. Note that because this process is recursive, and only analyses one decision at a time, it is not more difficult to decompose a large decisioning requirement: it just takes longer.

For example, when you ask the client “What information do you need to decide how to deal with the application?”, they might reply “Well, you need to know whether the application is eligible, whether the risk is acceptable, and whether the repayment is affordable. We have policy rules saying what to do in each case.” This tells you to link Is the application eligible? to How should we deal with this application?, add two further sub-decision nodes (Is the risk acceptable? and Is the repayment affordable?), and provide a Policy rules knowledge node.

Building the DRD

When the process is complete you will have a complete DRD, identifying the decisions required, the areas of knowledge involved in the decisions, and the areas of data required by the decisions.

Stage 4: Describe all the nodes in detail

Revisit all the nodes in the DRD and discuss them in detail with the client, one by one. For each decision node, agree on a more detailed description which explains how its required knowledge and data are used in reaching the decision. For each knowledge and data node, investigate the information required, and record:

The source of the information (systems, documents, or personnel)
An estimate of its size and complexity (e.g. number of rules or data items)
The maintenance requirements (who will be maintaining it, and how often)
Any other important background (e.g. the accuracy and completeness of the information source, any possible modifications within the timescale of the project).

Note that at this stage the objective is not to collect actual knowledge (e.g. particular business rules or pages of equations), but just to describe the required areas of knowledge and identify the sources for subsequent discovery. However, it is likely that the client will offer example rules, and if so these should be recorded. Similarly, the objective for the data nodes is to identify areas of data, not a full object model.

Stage 5: Define the rule service boundaries

Having defined the decision structure and supporting information, decide which areas are to be implemented as part of a decision service and which are to remain as external systems. Do not at this stage try to decide how many decision services there should be and how decisions should be allocated between them, simply identify which nodes are to be implemented and which are not. This will provide you with the “scope boundary” as shown in the previous posting.

Some useful rules of thumb are:

The top level decision nodes will be implemented in decision services (this was our starting assumption).
Most of the sub-decisions will be implemented in decision services, but services may call out to external decision-making processes e.g. web services or human authorities.
Most knowledge nodes will be implemented in the decision services (as rulesets or functions), but some very simple rules can be implemented as queries on a database.
Most data nodes will be information sources outside the decision services, but some may be implemented for convenience within the services if no other system requires access to them.

Boundary analysis involves provisional architectural design decisions, so the boundaries may be subject to change later in the design process. By recording the results of this analysis clearly in the project scope, any such requirements can be made the subject of a change request and properly costed.

The DRD

2009-12-07T10:36:00.011Z

People are much better at extracting information from pictures than from words, which is why diagrams are used in every professional sphere. IT is especially blessed with diagrams, UML alone providing 13 different types. Unfortunately, I have found none of these to be much use for defining decisioning requirements. Use case diagrams are intended for use in requirements definition, but treat the system as a black box rather than exposing the structure of its decisioning . ERDs can be used for capturing knowledge structure (as Barb von Halle and Larry Goldberg have elegantly shown in their Decision Model) but are more useful at the design stage. The subject of this posting is the Decision Requirements Diagram (DRD), which I use as a tool for capturing the scope and structure of the required decisioning at the very outset of a rules project, before any rules are discovered. This diagram, with its associated documentation, is central to the DRA method.

Definition

A DRD is a network diagram (technically speaking, a directed acyclic graph) which shows the information required for one or more decisions. It can be thought of as a decomposition of some decisioning into a set of related decisions and areas of supporting information. Below is a simple example of a DRD for a decision on how to deal with an application for a secured loan. This example is unrealistically simple for most real applications, but shows all the principal features of a DRD.

An example DRD

It contains three types of nodes: decisions, knowledge and data. These are linked by arrows which indicate requirements: an arrow from A to B indicates that A is required for B. So, for example, the decision What is the risk? requires three pieces of information: the result of the decision What is the loan to value ratio?, business knowledge expressed as scorecards, and bureau data. By convention the nodes are arranged so that the arrows point upwards. Note that the diagram is not necessarily a tree: a single piece of information (e.g. the loan to value ratio or the requested loan data) may be required by multiple decisions.

Components

The DRD contains only decision nodes, knowledge nodes, data nodes and arrows.

Decision nodes represent decisions, possibly to be taken by a rule service, but not necessarily: they might alternatively be made by a human decision-maker or by some other system component. Each decision uses a set of data to generate a set of data. The logic used to make the decision is described in one or more knowledge nodes. Decision nodes are described in increasing detail as the project progresses, but the initial colloquial description will include:

Name: a short noun phrase used as label for the decision, e.g. Application Eligibility
Question & Answer: a natural language question characterizing the decision, e.g. Is the application eligible?, with a defined set of answers, e.g. {ACCEPT, REFER, DECLINE}
Description: a definition of the decision-making logic or process, e.g. Applicant details and bureau data are checked against eligibility rules to confirm that the application is eligible in principle for approval.

Knowledge nodes represent areas of business knowledge required for the decisions. This knowledge may currently exist as human expertise, printed documents etc. In a decision-making system such knowledge may be represented formally as (for example):

Rules: business policies which must be “discovered” or "harvested"
Scorecards: predictive models which may be generated using analytics
Equations or algorithms: precise definitions of numerical calculations.

Note that it is possible to identify the areas of knowledge required for a project without identifying any specific rules or defining detailed calculations, and it is usually possible to estimate their size and complexity (e.g. numbers of rules or scorecard characteristics).

Data Nodes represent areas of data required by the decisions, which might be:

Specific data relating to the case being processed
Reference data held externally (e.g. on databases) or internally (e.g. in decision tables).

Again, at this stage we are interested in identifying areas of data, not all the specific data items, but we might be able to say roughly how many items were involved.

Arrows represent the fact that a piece of information is used by a decision. Requirements are not conditional; the arrow must be present if the piece of information is ever required to make the decision.

Uses

The main uses of the DRD will be described in detail in subsequent postings, but here is a taster.

The definitions of the individual nodes are directly useful in themselves:

Decision nodes provide a clear definition of the functional requirement
Knowledge nodes identify all the areas of knowledge discovery required for the project
Data nodes identify all the data to be made available and modelled.

The arrows between the nodes have important implications for the design, including:

Data flow: if the source of some information is external to the system component in which the decision is to be implemented, a data interface is required
Ordering of tasks: if decision A requires the result of decision B, B must be evaluated before A.

Drawing a boundary around a subset of nodes allows a very clear definition of what is inside and what is outside the boundary, and the lines crossing the boundary indicate the interfaces necessary. This allows:

Project scoping: by drawing a boundary around all the nodes to be implemented in the project
Division of functionality: by drawing boundaries between a number of rule services and/or other system components
Resource allocation: by dividing nodes between teams or individuals
Iterative development: by partitioning the functionality of the rule service between a number of increments.

Here is an example of how the DRD may be used to define scope of supply. This example shows a fairly common scenario: all the decision and knowledge nodes are inside the boundary (i.e. rule services must implement all the defined decisioning) and all the data nodes are outside (i.e. all the defined data must be provided by the client infrastructure to the rule services).

Scope boundary on the DRD

And here is an example of using DRD to define increments for iterative development. Here the decisions and knowledge nodes are divided into three increments, each providing a distinct functional benefit. Decision Requirements Analysis has allowed this division to be planned so that the three increments are “loosely coupled”: i.e. connected by few arrows.

Increments on the DRD

The DRD is produced using a simple, structured workshop technique called DRAW.

Introduction and Principles

2009-11-28T18:21:00.011Z

Welcome to my first posting on the DRA blog. I hope you find it interesting and useful. I am planning to publish these ideas soon in a book, but first I wanted to share them with you - colleagues, friends and anyone with a common interest - and collect your feedback. Please feel free to comment, criticize or argue, and to contribute your own ideas.

I have been building rule-based systems now for over twenty-five years, and in my experience the most difficult problems with rules projects are rarely technical; they are to do with management and communication. For example:

How can you discuss the required decisioning at a high level with the client?
How can you define the scope clearly at the outset of the project, before any rules have been collected?
How can you implement the project in stages without the need for extensive rework?
How can you avoid nasty surprises half-way through (e.g. the need to integrate with an extra source of data)
How can you divide the development tasks between multiple teams or locations and be sure the components will integrate properly?
How do you know when you've finished?

Decision Requirements Analysis (DRA) is the approach I have developed as a response to these problems.
It has been adopted by FICO as a standard part of our FIRUP methodology, and is now being applied by some of our clients, so I'm hoping there is a large enough user base to make these discussions interesting. DRA is a formal method comprising:

The Decision Requirements Diagram (DRD): a new type of diagram showing the structure of the required decisioning as a network of decisions and sub-decisions with their supporting areas of business knowledge and data
A structured workshop technique (DRAW) allowing a methodical top-down analysis of a decision into the structure recorded in the DRD and supporting documents
Best practice guidelines on the use of DRA in project planning, rules discovery, functional design and system development.

My plan is to introduce these components one at a time, in separate postings, to allow discussion of each before moving on. This first posting is just to set the scene and declare some initial tenets.

The underlying principles of DRA are simple.

Deliver the requirement, and nothing but the requirement.

The success of any development project depends on being able to contain the scope and deliver the agreed requirement. The basic principles of sound project management are well understood. Unfortunately, rules projects are notorious for scope creep, often caused by vague requirements.

We must not allow rules projects to be treated as an exception, just because they are difficult. Where the business logic to be implemented is very complex it is even more important that the functional requirement is clearly stated and agreed by the client. This is not incompatible with iterative development, as I will show. Misunderstandings over scope at the outset of a project can be catastrophic for both supplier and client.

Always work top-down, not bottom-up.

There is a tendency to think that business rules can be randomly “harvested” from an organisation, and can then be assembled into useful repositories. There are many problems with this approach, chiefly:

An organisation may have millions of business rules, and only a small fraction of them will ever need to be represented in a rule service
A single logical fact may need to be expressed as several different rules for use in different decision-making contexts.

Besides, just collecting and modelling existing business rules is anthropology, not Decision Management. Our goal is to change decision-making in the organisation, and the only viable approach is top-down: define the desired business decision, then design and develop the rule service to implement it.

Rule services make decisions.

A rule service is fundamentally a decision-making component. So, although it can be specified in various ways (e.g. as an algorithm or an input-output mapping), the best way to define its functionality is purely in terms of the decisions it makes. Each decision can be defined as a means of providing an answer to a question. So if you can clearly define the questions, the answers, and the means, you have completely defined the functionality of the rule service.

Decisions require information.

You can discover the requirements of a decision by asking what information is required to make the decision. Information is of three kinds:

Business knowledge (in all its forms: rules, calculations, analytic models etc)
Data describing the case to be decided on
The results of other decisions.

The last point is the key: this allows decisions to be decomposed into a network which can be drawn in a Decision Requirements Diagram (DRD).