The role of decision requirements modeling in successful business rules projects - by James Taylor an IBM Champion
Daphne de Flavia 270003U0B0 email@example.com |
0 Comments | 1,238 Visits
Table of contents for IBM IMPACT 2013
Business rules get everywhere – we have business rules in our user interfaces, in data quality, in business processes and more. But when organizations adopt a business rules management system they are focused on improving decision-making. A business rules management system like WebSphere Operational Decision Management lets us automate, improve and manage decision-making in our business processes and systems.
To be successful with a BRMS, as with any technology, we need to be clear what we are going to do with it. We need requirements for our project which clearly specify what is needed and how that will add value to our business. If better decision making is our goal then our requirements specification process should ensure that we know which decisions we are trying to improve and have a good idea of the decision-making involved. Our requirements should include an understanding of what policies or regulations apply, what information is available, who makes the decision and who has a say in how the decision should be made and much more.
In my client work I find that too many projects do not do a good job of this. Without good decision requirements these projects are likely to flounder around and fail to have a positive business impact. Traditional requirements techniques like use cases or requirements lists tend to identify the need for decision-making but are not suitable for specifying how decisions should be made. Simply capturing business rules in a spreadsheet or list focuses on details before structure and often results in a “big bucket of rules.” To be successful we need a new way to capture our requirements – a decision requirements model.
A decision requirements model has five elements:
2. Information Requirements
3. Knowledge Requirements
4. Decision Structure
You can repeat this process, breaking down each piece of the decision-making into more granular decisions or questions until you understand it fully. This decision decomposition outlines how you want to make this decision, or how you want the people in your call center to make the decision, each time. It’s not code or business rules but it is precise. With this in hand you can look at the information and knowledge you identified and see if still seems complete given your new understanding (it won’t be) and you can see exactly where in the decision making each element comes into play.
5. Decision-making context
Here’s an example
In this example we are using the notation being adopted as part of the Decision Model and Notation standard, currently under development for the Object Management Group (both IBM and my company, Decision Management Solutions, are submitters on this standard). Decisions show as rectangles with the solid arrows showing information requirements – decisions at the arrow end require the information that comes from an external information source (oval) or decision at the blunt end. Knowledge Sources, such as policy documents or regulations, are shown as documents and the dashed line shows which decisions require which knowledge sources – known as authority requirements.
With a decision requirements model in hand your business rules can be identified and described not as a single list but in terms of the rules for each of these sub-decisions. This focuses rule capture and completeness checking on a much more well defined scope. You also already know what the possible actions for the rules can be (the answers allowed for the question you identified) and how these rules fit into the larger picture. You also know which organizations and external knowledge sources are likely to be relevant. The model also shows you who cares about the rules and will need to review them as well as who will be maintaining them over time (because you know which pat of the organization owns or makes each decision in it).
If you have questions about decision requirements modeling why not come by one of my sessions at IMPACT: