Decision requirements models allow business analyst, architects and decision designers to describe the decision-making they need. When these models are combined with business-friendly decision tables, non-technical domain experts can represent critical “know-how” accurately and precisely resulting in faster time to value and fewer errors. Add in the ability to navigate an existing implementation graphically, and these same users can find out when a change is required and where to make it. The combination of decision requirements models and executable decision models enables business analysts to test and validate their models – and the decision making they need in their systems – even before they will be integrated into an IT infrastructure.
Decision Requirements Models
Before introducing Decision Requirements Models it is worth considering existing techniques and their limitations with respect to capturing decision requirements. The most common ways to express decision requirements are use cases, business rules catalogs or lists, process models and requirements lists. While each of these can contribute to the understanding of a project, each of them has serious limitations when it comes to specifying the requirements for decision making logic in a system.
In many Use Cases key steps are actually decisions – validate user input, determine if the transaction is fraudulent etc. These decisions are identified and put in context by use cases but, critically, they are not modeled by them. This means that a set of use cases might identify the need for many decisions but it will not define how those decisions are to be made.
Simply listing and documenting all the business rules in a system or business area before a strong decision model has been developed can result in what can best be described as a "big bucket of rules." Documenting business rules without a strong decision model is focusing on the details before the overview and is akin to listing all the tasks in a process before defining the process as a whole.
Like use cases, many process models identify decisions as tasks that are not then modeled. When decisions are modeled using process artifacts, enormously complex processes are the result. If business rules are added directly to such a model then "peanut butter rules" result with the rules smeared thinly throughout the process.
-
Requirements Lists
These often identify that the system must make certain decisions but HOW those decisions should be made is not easy to capture as a requirement.
Experience with projects developing decisioning components is that effective decision requirements are critical. Effective decision requirements have four key characteristics:
Good decision requirements clearly specify the information involved, showing what information is needed and where it comes from.
It is important to know where to find the specifics of how the decision is made. The requirements must specify the policies, regulations, sources of expertise and best practices that define the “how.”
Good decision requirements specify precisely how the decision will be made, breaking down the decision into a detailed representation without bringing in too many technical details.
The applications that implement the decision, the processes that consume it and the events that trigger it should all be documented and the roles different organizations play in the decision making should be clear.
A simple Decision Requirements Model, one conforming to the notation defined in the forthcoming Decision Model and Notation standard, is shown on the following diagram:
This diagram describes a decision that should determine a customer greeting based on the current time and personal information (think about an IVR system).
The rectangles represent decisions– both the top level decision (“Determine Customer Greeting”) that might appear in a business process or use case and the sub-decisions (“Define Greeting”, “Define Current Hour”, and “Define Salutation”) into which it can be broken down.
The ovals (“Customer”) represent information, business objects that are required by the decision.
The documents (“Greeting Guidelines” and “Salutation Rules”) represent sources of knowledge, such as policies, regulation, expertise or analytic insight.
The links on the diagram represent either information requirements (the solid arrow) or authority requirements (the dashed link). Information requirements show what information must be available to make a decision. For instance, the relevant customer greeting requires that we know both the greeting and the salutation. The knowledge sources show what sources will be used to find the specific business rules to define the element of decision-making to which they are linked.
The ability to break down a decision into its components is what allows a simple graphical representation to show precisely how a decision is to be made. It also allows an automation boundary to be drawn, encompassing the relevant elements of the decision model. Such a model can also become a map for your decision implementation that will remain stable while implementation details may be changed.
Implementing Decisions with Business Rules
Objects on decision requirement diagrams can easily be linked to business rules implementation environments The business logic of each decision within the model can be defined in terms of the business rules that implement it. For instance, the business rules for the above sub-decision “Define Salutation” can be implemented by business rules represented in the following decision table:
In this example we have linked a Decision Requirements Diagram to a decision table created in Excel. In this way it is possible to move from requirements to execution with the decision logic for a decision in the model represented using Decision Tables in a spreadsheet format. The information objects in the Decision Model can likewise be linked to data dictionary definitions or a glossary as well as to data tables that represent test cases.
Each implementation artifact can also be linked back to the model element that drove its requirements, allowing full traceability from the implementation environment. When a knowledge source changes it is easy to see which decisions it acts as an authority for and then to link to the relevant decision tables to make changes. Business rules are managed in coherent, logic groups and only one version of the rules is required, maximizing agility.
Using decision requirements models and decision tables in combination allows the specification of executable decision requirements and allows the graphical requirements model to act as a map of the implementation. As a result, business people can develop a decision requirement model and then execute those requirements. Once they feel comfortable with their models they can turn them over to software developers for the integration into a particular IT infrastructure.
Authors: James Taylor & Dr. Jacob Feldman
James Taylor is CEO of Decision Management Solutions. Decision Management Solutions is a submitter for the Decision Model and Notation standard and offers Decisions First Modeler, a social, collaborative platform for building decision models as well as training and consulting in decision modeling.
Dr Jacob Feldman is CTO of OpenRules, Inc., a company that created and maintains a popular open source BDMS commonly known as “OpenRules”, http://openrules.com