Task: Transform Rules
Transform the rule to avoid ambiguity and make them more atomic
Disciplines: Rule Analysis

The goal of the this task is to transform the rule in an artifact the business user can understand, and rule writer can understand, implement, test and maintain.

RolesPrimary Performer: Additional Performers:
    • None
      Main Description

      Rule Analyst has to study the rule discovered and try to transform it so that the implementation and the management of the rule will be more easy. This includes transforming the rule in atomic element using a syntax without ambiguity, remove redundant rules, conflicting rules, and finally try to redefine the scope of the rule by searching by non-handled cases. 

      At this stage rule analyst can build some rule template which are built from rules that have the same set of conditions with some little variations: adding new value in test condition, or new condition.

      Refine Rule as Atomic

      A rule is atomic if it cannot be further decomposed without losing meaning. Atomicity is desired for understandability, ease of maintenance

      • Make sure each rule has one result
      • When expressed an inference rule or an action enabler, do not allow ANDs on the right hand side; break the rule
        • IF A THEN do(B) AND do(C)   can be rewritten as two rules IF A THEN do(B) and IF A THEN do(C)
      • When expressing an inference rule or an action enabler, do not allow ORs on the left hand side; break the rule
        • IF A OR B THEN do(C) can be rewritten as two rules IF A THEN do(C) and IF B THEN do(C)
      • When expressing constraints and guidelines, do not allow for ANDs
        • A driver must be 25 years old or older AND must have good credit rating
        • A driver must be 25 years old or older; a driver must have good credit rating
      • Make sure that each rule contains only necessary conditions; don't over-constrain the rule applicability
      Remove redundant rules

      This step is important to avoid developing complex rule sets. Redundant rules are

      • Duplicated rules
      • Duplicated through some transformations (renaming, inversion of conditions, etc.)
      • Redundancies among rules that create a common data value or a common truth value, or initiate a common action

           This step is made simpler if we make the rules atomic, for otherwise, we will be lost in the equivalence of complex logical formulas (e.g. If NOT (A AND B) is equivalent to  IF (NOT A) OR (NOT B)). There are for sure more subtle forms of redundancy: IF A AND B THEN C is equivalent to IF (NOT C) THEN (NOT A) OR (NOT B). Some time changing the order of conditions can help to highlight same rules:  IF A AND B THEN C is the same as IF B AND A THEN C

      Remove inconsistency rules

      Overlapping rules are partially redundant because they are not semantically equivalent but they point to problems: One rule may say IF A AND B THEN C, the other says IF A THEN C. The question is, is B really needed to infer C? One of the two rules should be eliminated.

      It is also possible to get semantically equivalent conditions, contradictory conclusions: two rules like IF A THEN B; and IF A THEN NOT(B) are leading us to have two conflicting rules, probably coming from two different sources. Typically, this is symptomatic of the fact that we are missing some necessary conditions in either rule (or both, e.g.: IF A AND C THEN B; IF A AND D THEN NOT(B))

      Another standard case is around the same conclusions derived from contradictory conditions: rules like IF A THEN B;  and IF NOT (A) THEN B: Logically, this means that the conclusions should always be true. This is symptomatic of the fact that the condition is really not relevant to the conclusion

      Ensure completeness among rules

      We are often considering three kinds of completeness:

      • Make sure that all the possibilities are covered for a given rule pattern. If you have a rule that says "loans for value greater than 250,000 $ should be approved by the branch manager", it does not tell us who must/can approve loans of value less than 250,000 $
      • Make sure that all derived data in the object model has corresponding computation or inference rules. This involves computed attributes, qualifications (e.g. customer status, account type, etc.)
      • Make sure that integrity and cardinality constraints are somehow represented. Either in the object model or in rules
      Analyze rule volatility
      This a good timing to ask the business user how often the rule will change once we did the rule transformation.
      Understand rule dependencies, rule sharing

      A rule R1 depends on a rule R2 if the enforcement of R2 results into a situation where R1 is relevant (or needs to be enforced). A simple common example, is a rule R2 which is creating new data, or is modifying existing data that is tested by R1.

      Understanding dependencies help determine the likely "execution" sequence of rules. The execution sequence is useful for rule analysis to detect undesirable dependencies to plan rule testing. For the implementation the execution sequence is useful to understand how the results will look like: some rule engine tools will determine that sequence automatically, and on the fly (chaining). If we implement business rules in a procedural fashion, we need to understand the execution sequence to enforce it

      Some of the undesirable dependencies include circular dependencies leading to infinite loops. Others will cause us to re-evaluate rule jurisdiction

      When the work is done the last step is to look at how rule can be shared between process flow. Rule sharing is an important step of the analysis. It can be done once we have progressed in the rule set implementation. Rule re-factoring activity can help on implementing some rule sharing pattern.

      Key Considerations
      This activity will also be done during the implementation of the rule set, but it is started during the analysis, so we are detailing it in this context.
      More Information