Last time, I described the second step in an eight-step approach for crafting a business rule.  Once you have extracted the business rule from the source and determined whether the business rule already exists, the next step is to determine whether the business rule computes or derives something.  This helps you to know how to structure the rule.

Computation Rules

Determining whether a business rule computes something is fairly straightforward — just look for the following:

• arithmetic operators like '+', '-', '*', and '/'
  
  
• keywords like 'total', 'subtotal', 'net', 'count', etc.
  
  
• anything that produces a number

Computation rules follow the structure^[1] "x must be computed as y" with "x" being the result and "y" being the mathematical formula.

Some examples:

• The total order amount must be computed as the sum of the order item amounts.
  
  
• The total tax amount must be computed as the total order amount times the current tax rate.

As you can see, the concept of 'total order amount' is used in the second rule rather than repeating the computation.  This allows you to change the rule in only one place and have that change in logic propagate to all the rules that use that term.

Computations should be captured as business rules to ensure that the computation is done consistently wherever it is used (on a screen, in a report, etc.).

Derivation Rules

Determining whether a business rule needs to derive something is a bit trickier.  I've found that Business Analysts often struggle with the concept of derivation.  So let's go back to basics and determine what it means to derive something.

An online search on the verb 'derive' results in the following definitions:

• To gather or arrive at (as a conclusion) by reasoning and observation:  a : to obtain inductively : INFER  b : DEDUCE (Merriam-Webster Unabridged Dictionary)
  
  
• To base a concept on a logical extension or modification of another concept  (Oxford Dictionaries Online)

A derivation rule allows you to specify conditions that occur in the business and use a term as a sort of shorthand to indicate those conditions have been met.  For example, you can infer that a person is a woman if you know that the person is female and over the age of 21.  Anyone who meets the specified conditions can be referred to as a woman.  So you are essentially defining the concept of a 'woman' through the use of a business rule.  'Woman' is a new derived concept.

When a derivation rule is evaluated, the result is always either 'true' or 'false'.  Either the conditions are met, or they aren't.  For example:

• A driver must be considered a high-risk driver^[2] if the driver has had more than two accidents in the last three years.
  
  
• A driver's license must be considered a valid driver's license if the expiry date of the driver's license is not past.
  
  
• A person must be considered a senior citizen if the person is over the age of 65.

Note that the name for a derived concept may be an entirely new term (e.g., 'senior citizen') or an extension or modification of an existing term (e.g., 'high-risk' modifies the term 'driver').

The power of the term for a derived concept lies in the ability to use that term in multiple business rules.  Rather than re-specifying the criteria (which is often more complicated than in the examples above) in each rule, you simply use the new term.  For example, rather than saying "the driver has had more than two accidents in the last three years" as a condition in multiple rules, you simply say "the driver is a high-risk driver."

Then if you need to change the derivation rule (e.g., change the number of accidents to three), it needs to be changed in only one place.  The change in logic then propagates automatically to all the business rules that use the term without having to change each of those rules.

Determining up-front whether you have a derivation rule will help you to structure your business rules to take advantage of your new term.

Final Thoughts

One of the questions I'm often asked is whether or not you need to add the terms for computed and derived concepts to the concept model (see references below for more information on concept models/fact models).  They definitely don't need to be added to the diagram, but you may choose to add them to the glossary if they are common terms used in the business.  However, make sure you don't embed the business rule in the definition.

Now that you have determined which of the rules in the source material compute or derive something, you are ready to actually start crafting the business rules!  I'll describe the next step — starting with the subject — in next month's article.

References

Article on Using Consistent Vocabulary:

Gladys S.W. Lam, "Top 10 Mistakes Business Analysts Make When Capturing Rules — Mistake #2:  Not Focusing on Terminology," Business Rules Journal, Vol. 11, No. 12 (Dec. 2010), URL:  http://www.BRCommunity.com/a2010/b568.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

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 http://www.rulespeak.com

Notes:

[1]  The convention of using "must be computed as" for a computation rule is part of the RuleSpeak© technique for writing business rules.  It provides a consistent method of expressing these rules, which helps to easily identify and understand them.  

[2]  The convention of using "must be considered" for a derivation rule is part of the RuleSpeak© technique for writing business rules.  It provides a consistent method of expressing these rules, which helps to easily identify and understand them.  Also, you do not necessarily have to repeat the base term — you can say "A driver must be considered high-risk if…."  

# # #