Navigation
  • The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
    The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling

Entries in Requirements (1)

Thursday
Mar182010

Business Rules Requirements in the Real World

In a recent blog post on the requirement network group, Chris Kosba posed a question concerning the role of 'business rules' in requirements gathering activities. Again, this raises a common misconception about requirements and business rules.

I agree that it is necessary to know when your requirement is supporting a business decision through rules. To approach this issue, we need to meet the eternal question: what problem are we trying to solve? As messy as the requirements page in Wikipedia is, the meaning is pretty concise -a requirement is a singular documented need of what a particular product or service should be or perform.

If our requirement is that we should support the business rules, as defined by the business operations, (i.e. credit risk rating) then it is usually useless to document these business rules in requirements elicitation. The business rules are the data that drive the system. Documenting these rules would be equivalent to defining an employee database then defining the instances of employees in the tables. We know our employee table needs columns of first name, last name and middle initial. This is a requirement. Is it a requirement that the table organize the records "John A. Smith, Bob H. Jones, and Sally L. Quill"?

If your system requires that business rules be supported by BRMS then, business rules should be visually expressed as truth tables or logic trees. The truth table is a two-dimensional indication of conditions and conclusions. In Visual Rules, we call the logic tree a rule flow. In the real world, we often run into application requirements that are stored in spread sheets with logic that flows from worksheet to worksheet. Often, there are many tabs with dozens, if not hundreds, of lines of logic. We especially see this in score cards for probability of default (PD) models. These spread sheets can be converted into a visual model with the Visual Rules approach.

If the requirements documents show too many business rules, or business rules that should be in a BRMS, then they will become unnecessarily complicated.