A FORMAL METHOD FOR DEFINING THE REQUIREMENTS FOR DECISIONING SYSTEMS, ESPECIALLY THOSE IMPLEMENTED USING BUSINESS RULES ENGINES (BRE).
The DRD
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
Source: dramethod
