3 Steps to Define Requirements for Business Rules and Decisions
Feb 3, 2020
Imagine you are asked to define business requirements and constraints for a set of business rules as part of the design of a solution. What approach would you use?
I had to ask this question myself when I was involved in projects where designs for new (IT) solutions where made. The definition of the business rules of the solution were part of the design phase. Because most traditional requirements engineering approaches focus on defining requirements for IT systems, I found that using these kinds of approaches for defining business rules requirements is not suitable.
In this blog I present a practical 3 step approach that can be used to define business requirements for business rules and decisions. It focuses on 3 aspects that you need to define as a requirement for a business rule: How, where and what.
This first step is to gather the relevant knowledge sources that can help specify how the decision is made and how the business rule should work. For example: policies, regulation, sources of expertise and best practices on which the business rule is based. As part of the requirements, it is not necessary yet to describe the behavior of the business rule in complete detail. Only refer here to the relevant knowledge sources and add a high level description if you like. Important constraints from law and regulations should be made clear here as well.
The second step is to define where the business rule applies. This question should be answered from a business perspective. Therefore, the best way to determine this requirement is to indicate as part of which business process (step) the business rule needs to be described. Business processes define the order of activities that are executed to produce a result to the customer. A business rule can often be assigned to a single activity or set of activities. Reference material like existing business process models from the organization, high level business function models, or business process reference models from the industry can all serve as a starting point. The level of detail used to answer the ‘Where’ question depends on the availability of this material. If possible, use the organization’s existing business process models. If nothing is available you can still describe in words using business terminology where the business rule applies. However, this is far less accurate.
The final step is about data. A business rule is based on a combined set of information or data elements. For example, the business rule for whether an insurance claim is accepted, depends on the amount claimed and the payment behavior of the customer. Part of the set of requirements of a business rule, is to define the essential data elements that are necessary as input to the business rule. Without these data elements available, it is not possible to execute the business rule. Existing data dictionaries or data models can be used as starting point. In addition it can help to describe where the data should come from (e.g. which system, which department, which external party, etc.)
If you describe these three aspects together, this forms a complete set of requirements for the business rule. A business rule designer can use this information as input to make a detailed design of the business rule.
Furthermore, the set of requirements can serve as input for the execution of rules in a business rules engine. In that case a next step is needed to define technical requirements that arise from constraints of the chosen implementation platform. Do you have more ideas about requirements for business rules? Feel free to share your comments below.
