When tasked with defining business requirements and constraints for business rules and decisions as part of designing a solution in Business Process Modeling, I often find myself asking: What is the best approach to ensure accuracy and relevance? Defining business rules during the design phase is essential in projects involving new IT solutions. However, many traditional requirements engineering methods focus primarily on IT system requirements, making them unsuitable for defining business rules requirements.
In this blog, I present a practical three-step approach for defining business requirements for business rules and decisions, with a focus on Business Process Modeling. This approach addresses three key aspects you need to consider when defining a business rule: How, Where, and What.
The first step is to gather relevant knowledge sources that help define the decision and how the business rule should operate. Sources such as policies, regulations, expert input, and best practices are key here. At this stage, it’s not necessary to describe the business rule in full detail. Instead, refer to the knowledge sources and provide a high-level overview. It’s also important to identify any legal or regulatory constraints that may apply to the rule.
The next step is determining where the business rule applies, which should be defined from a business perspective. The best way to identify this requirement is by referencing Business Process Modeling, where you map out the relevant business process or activity in which the business rule applies. Business processes define the sequence of tasks that lead to a result, and business rules typically align with specific steps or sets of activities. Existing business process models, whether from within the organization or industry reference models, can be used to pinpoint where the rule fits. If such models aren’t available, you can describe the location of the rule in business terms, though this approach is less precise.
By following this approach, you can ensure that business rules and decisions are well-defined, aligned with business processes, and adequately supported by relevant knowledge sources.
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 customer’s payment behavior. 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, executing the business rule is impossible. 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.)
In Business Process Modeling, describing these three aspects together creates a comprehensive set of requirements for the business rule. A business rule designer can then use this information as the foundation for creating a detailed design of the rule.
Additionally, this set of requirements can serve as input for executing rules within a business rules engine. In this case, a subsequent step is needed to define the technical requirements that arise from the constraints of the chosen implementation platform.
Product Manager at Bizzdesign
Rob specializes in Business Process Management and Enterprise Architecture. He has been with Bizzdesign for more than 18 years, and as a member of the Product Management team, he is working on translating strategic goals of the company towards required functionalities in our software platform. Responsible for the software platform’s overall architecture and guiding our development teams in terms of architecture design, scoping, prioritization and requirements definition.
