According to the IIBA, a business rule is a specific, actionable, testable directive that is under the control of an organization and supports a business policy. Business rules should be documented independently of how they will be enforced.
“Operative Rules” are intended to guide the actions of people. They are typically found in an organization’s Standard Operating Procedures Manual. For example “an order cannot be placed if the billing address provided by the customer does not match the address on file with the credit card provider”. It is always possible that associates will not always follow an Operative Rule. When you are doing a current system analysis, you may very well find documented rules that are handled differently in each location. By finding out the root cause of why a rule isn’t being followed, it could present a good opportunity to change the rule.
“Structural Rules” structure the knowledge of the organization and cannot be violated. For example “an order must have one and only one payment method”. This type of rule is usually enforced systemically. They can be uncovered during data analysis by constructing an Entity-Relationship diagram. The relationships between entities are the Business Structural Rules.
Other examples of Structural Rules:
- A Product can be purchased by zero, one or many Customers.
- A Sales Transaction contains one or more Products
- A Discount can be applied to zero, one or more Products.
- A Customer may Purchase zero, one or more Products.
The “zero” relationship is of special interest. It is useful for uncovering additional requirements. For example, in the example above “A Customer may purchase zero, one or more Products” you may ask “How can a Customer purchase zero products?”
The answer may be “A Customer might only apply for a Store Credit Card” or “A Customer may only wish to be added to an email list”. These answers would generate follow up questions regarding the scope of the project.