Now that your business rules are all beautifully crafted, what do you do with them?  You want to examine them as a group to ensure that they are logically consistent.

When you're writing a set of business rules, it is important that they all work together.  If you are dealing with a large number of business rules, it is easy to lose track of what you've already written.  You can inadvertently introduce 'anomalies', or logical inconsistencies, into the business rules.

Some of the more common anomalies are:

• Conflict — two different outcomes for the same situation that are mutually exclusive

  Example:

• An order must be sent by premium service if it contains fragile items.
  
  
• An order must be picked up by the customer if it contains fragile items.

Obviously, you can't do both, so the conflict needs to be resolved.  This almost always requires input from the business.

• Overlap — overlapping ranges

  Example:

• An expense statement between $1,000 and $3,000 must be approved by a manager.
  
  
• An expense statement over $2,000 must be approved by a regional manager.

In this case, it is possible that an expense statement may require more than one signature; however, as there appears to be a problem, it should be brought to the attention of the business.

• Subsumption — one rule is covered by another, broader rule

  Example:

• An out-of-state order must have a promised date.
  
  
• An order must have a promised date.

The first rule can be eliminated as it is covered by the second rule.  The first rule is said to be "subsumed" into the second one.

• Redundancy — two rules express the same thing in different ways

  Example:

• An auditor must not audit any manager in the same city.
  
  
• A manager must not be audited by any auditor in the same city.

• Similarity — two or more business rules that potentially have identical effect but are inconsistent on specific qualifications

  Example:

• A programmer trainee must not maintain a system evaluated at more than $100k.
  
  
• A programmer must not be a trainee, if he maintains any system whose value is greater than $50k.

This kind of anomaly is often found by looking at all the rules that use a specific term (e.g., trainee).

Note that decision tables also need to be checked for these anomalies.

Manually Verifying the Rules

Unless you are lucky enough to have automated support for verification of business rules, the only way to determine if there are any anomalies at this point is to desk-check the rules.

It's a good idea to group the business rules into smaller sets that have a common theme, such as:

• all the rules defining a product or service,
  
  
• all the rules supporting a specific decision,
  
  
• all the rules using a specific business term.

Reviewing all the rules that use a particular term is a good way to verify the rules across products, business areas, or projects.  Of course, this assumes that you have consistently used the vocabulary in the concept model in all the business rules.

Another way to verify the rules is to use scenarios to ensure that you get the desired results.  These scenarios are really test cases, as they should include boundary conditions to test ranges, etc.

Once you have verified your set of rules, you want to check to make sure that you are not introducing anomalies into any existing business rules.  Having a central repository is very helpful in this, as it is much easier to search the existing rules.

Conclusion

So, you can see why I used the term 'crafting' in the title to this series.  There is a lot of hard work, deep thought, and skill involved in writing business rules.  It takes discipline and effort to write a good business rule, but there is an inherent sense of satisfaction in doing it well.

Using the 8 steps described in this series provides a consistent way to build your business rules and will, I hope, lead to a better quality result.

Now that you have crafted your set of rules and verified them, it's time for that reward.  Me, I'm off to have some chocolate (preferably dark!).

Acknowledgments:

Thanks to Ron Ross for reviewing the articles in this series to ensure that I adhered to the Proteus^® methodology.

Thanks to Gladys Lam for her continued support and encouragement.

General References:

Building Business Solutions:  Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, October 2011, 304 pp.  URL:  http://www.brsolutions.com/bbs

For more information on the RuleSpeak^® technique, visit www.RuleSpeak.com

Articles on Validation and/or Verification:

Rik Gerrits, "Verification of Business Rules Utilization," Business Rules Journal, Vol. 4, No. 12 (Dec. 2003), URL:  http://www.BRCommunity.com/a2003/b175.html

Ronald G. Ross, "Rule Quality — The Route to Trustworthy Business Logic," Business Rules Journal, Vol. 6, No. 9 (Sep. 2005), URL:  http://www.BRCommunity.com/a2005/b247.html

Dr. Silvie Spreeuwenberg, "Using Verification and Validation Techniques for High-quality Business Rules," Business Rules Journal, Vol. 4, No. 2, (February 2003), URL:  http://www.BRCommunity.com/a2003/b132.html

Articles on Concept Models:

Ronald G. Ross, "Concept Model vs. Fact Model vs. Conceptual Data Model — Just a Matter of Semantics?" Business Rules Journal, Vol. 13, No. 1 (Jan. 2012), URL:  http://www.BRCommunity.com/a2012/b632.html

Ronald G. Ross, "What Are Fact Models and Why Do You Need Them? (Part 1)," Business Rules Journal, Vol. 1, No. 5 (May 2000), URL:  http://www.BRCommunity.com/a2000/b008a.html

Ronald G. Ross, "What Are Fact Models and Why Do You Need Them? (Part 2)," Business Rules Journal, Vol. 1, No. 7 (July 2000), URL:  http://www.BRCommunity.com/a2000/b008b.html

# # #