What is this series of articles about?

This is the sixteenth article in a series in which I describe a practical method of developing unambiguous natural language rule statements.  I've developed this method for a large Australian government agency that has selected the Business Rules Approach and the Object Management Group's Semantics of Business Vocabulary and Business Rules (SBVR)^[1] as representative of best rules practice.

The story so far

We've been looking at some of the rules governing an online "Book Flights" facility provided by an airline.  So far, we've created a set of rule statements, the fact types on which the rules are based, and some rule statement templates and sub-templates for generating rule statements.

We've also been developing a taxonomy of rules as well as a rule statement development method based on selection of the appropriate template and sub-template(s) for each type of rule.  The taxonomy, templates, and sub-templates are listed in the [sidebar] along with all valid rule statements and supporting fact types. This month, as well as including the templates and sub-templates added last month, and updating the table that indicates the appropriate (sub-)templates, I've brought the rule taxonomy up-to-date and also added some fact types that a keen-eyed reader noticed were needed to support our set of rule statements but that I had overlooked.

The font and colour conventions used in these articles reflect those in the SBVR.^[2]

Rule statement quality checking continued

In earlier articles^{[3]  [4]} we looked at quality checking of rule statements.  There are some additional quality criteria, not discussed in those articles, relating to qualifying clauses.  You may recall that a qualifying clause can be used to limit the scope of the rule statement.  For example, RS8 (reproduced below) refers to all flight booking requests whereas RS9 (also reproduced below) refers only to those flight booking requests that are for return journeys.

RS9 refers only to flight booking requests for return journeys because of the qualifying clause {that is|} for a return journey, which has limited the scope of the rule statement to a subset of the set of all flight booking requests.  We've seen that we can use all manner of different qualifying clauses in our rule statements, but we need to ensure that we don't use a qualifying clause in a rule statement that limits the scope of that rule statement to a null set.  For the sake of discussion, I've named these extreme qualifying clauses.

Extreme qualifying clauses

Consider the following examples:

1. An infant passenger who is more than 2 years of age at the time of travel …
   Here the qualifying clause contradicts the definition of the term infant passenger provided in RS81 (reproduced below).

2. A journey that is not a one-way journey, a return journey or a multi-stop journey …
   Here the qualifying clause exhausts the categories of journey.  An important point to note here is that the existence of the fact types FT3, FT5, and FT112 (reproduced below) is not sufficient to establish that these are the only categories of journey.  It is therefore a good idea to add definitional rule statement RS116, which makes clear that they are the only categories.  Note that RS116 can be generated using template RT25.

3. A flight that has no origin port …
   A flight that has more than one origin port …
   In each case here the qualifying clause contradicts the fact that, by definition, every flight has a single origin port (as well as a destination port — "what goes up must come down").  Again it is important to note that the existence of fact type FT111 (reproduced below) is not sufficient to establish that every flight has an origin port.  By contrast we know that despite FT4 (also reproduced below) not every flight booking request specifies a return date (for example if it is for a one-way journey).  We therefore need the additional definitional rule statement RS117 to specify that every flight has an origin port — along with many more in the same vein, such as RS118.  How many can you find?

4. A flight booking request that specifies a passenger name …
   Here the qualifying clause is invalid because the fact type flight booking request specifies passenger name does not exist.  But what if we had simply created without thinking all the fact types that appear to support each rule statement we had created?  If that were the case, we would have created the fact type flight booking request specifies passenger name as soon as we thought we needed a rule statement with the qualifying clause that specifies a passenger name after the term flight booking request.  As a result we would be unable to apply this type of "sanity check" (does the necessary fact type exist?) on rule statements.  Fact types are far more useful if created by thoughtful analysis of the organisation's business through such questions as:
   
   
   1. What are the products and services available?  What are the characteristics of those products and services and how are they related to each other?  For example, airline serves city, flight is operated by airline, flight has origin city, flight has departure time, fare class is available on flight, port has minimum domestic transit time.
      
      
   2. What processes and events occur and who and/or what is involved?  For example, passenger is booked on flight, passenger checks in for flight, passenger presents boarding pass.
      
      
   3. What information is created or used in each process?  For example, flight booking request specifies departure date, flight booking confirmation specifies passenger name, airline can access postal code information from postal authority.
      
      
5. A flight booking request that specifies no origin city …
   A flight booking request that specifies more than one origin city …
   In each case here the qualifying clause contradicts rule statement RS12 (reproduced below).  Note that, by contrast with example 3 above, the rule statement contradicted is an operative rule statement, which can be violated, rather than a definitional rule statement, which cannot.  It is therefore possible for a flight booking request not to specify an origin city.  However it is unlikely that we would want to formulate a rule that applied only to such invalid flight booking requests.  Remember that we do not include in our rule statements any statement as to how the organisation or its employees or systems respond to rule violations.

Extreme conditional clauses

Conditional clauses that limit rule statements to the null set are similarly inappropriate.  Thus each of the following conditional clauses is inappropriate:

1. that infant passenger is more than 2 years of age at the time of travel
   
   
2. that journey is not a one-way journey, a return journey or a multi-stop journey
   
   
3. that flight has no origin port,
   that flight has more than one origin port
   
   
4. that flight booking request specifies a passenger name
   
   
5. that flight booking request specifies no origin city,
   that flight booking request specifies more than one origin city.

Self-contradictory qualifying and conditional clauses

The qualifying clauses we looked at above each contradicted in some way the definition of the term being qualified.  It is also possible for a qualifying clause to contradict itself as in the following examples, each of which is inappropriate in a rule statement since it would limit the scope of that statement to a null set:

1. that is less than 1 year of age and more than 2 years of age
   
   
2. that is a one-way journey and a return journey
   
   
3. that has no origin port and has more than one origin port
   
   
4. that specifies a passenger name and does not specify a passenger name.

Similarly, a conditional clause may be self-contradictory and therefore inappropriate in a rule statement, as in the following examples:

1. that passenger is less than 1 year of age and more than 2 years of age
   
   
2. that journey is a one-way journey and a return journey
   
   
3. that flight has no origin port and has more than one origin port
   
   
4. that flight booking request specifies a passenger name and does not specify a passenger name.

Structural cardinality rule statements

Rule statements RS117 and RS118 introduced above are cardinality rule statements but definitional (or structural) rather than operative, i.e., they cannot be violated.  A new template (RT36) is required for these rule statements:

Data format rules

An important class of rules that should not be overlooked is for those that require each instance of a data item to have a particular format.  For example, the requirements of rule statements RS34 and RS35, which require phone numbers to be included in a flight booking confirmation, would be met by entering single digits in the appropriate data field(s); however, these would not be valid phone numbers.

What constitutes a valid phone number?  In Australia, a full phone number (including the 2-digit country code and 1-digit area code) has 11 digits (although there are some 6-digit and 10-digit numbers assigned to call centres, which would therefore be inappropriate as contact numbers for a flight booking).  Most, if not all, US phone numbers also have 11 digits (including the 1-digit country code and 3-digit area code), but European phone numbers may have as few as 9 digits or as many as 12 digits.

Note that there are 6 different phone number data items in a flight booking confirmation.  You might be tempted to create the following rule statements RS119 – RS124, one for each of those phone numbers:

What if the rule governing what constitutes a valid phone number changes?  You have at least 6 rule statements to change.  An alternative approach is to express that rule only once (as in RS125) and refer to that definition in a rule statement for each data item.

Clearly we've only scratched the surface of data format rules; we shall look at more in the next article.

Corrections

In reviewing existing rule statements for this article I noticed that RS34 and RS35 as they stand (see [sidebar]) contradict each other.  This is because RS34 constrains flight booking confirmations for one-way journeys whereas RS35 constrains flight booking confirmations for return journeys.  Each rule statement therefore is missing the appropriate qualifying clause; the correct rule statements are as follows:

To be continued...
In the next article we will look at more data format rules, as well as redundant clauses in rule statements.  In subsequent articles we will look at rules governing the parties or roles that are allowed to perform a process or use information, as well as various other topics, such as the role of verb phrases and prepositions in rule statements, and the role of the time dimension in rules.

References

[1]  Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008).  Available at http://www.omg.org/spec/SBVR/1.0/PDF  

[2]  The font and colour conventions used in this and other well-formed rule statements and fact types in these articles reflect those in the SBVR, namely underlined teal for terms, italic blue for verb phrases, orange for keywords, and double-underlined green for names and other literals.   Note that, for clarity, less than well-formed rule statements will not use these conventions.  

[3]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 13)," Business Rules Journal, Vol. 11, No. 2 (Feb. 2010), URL:  http://www.BRCommunity.com/a2010/b522.html  

[4]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 14)," Business Rules Journal, Vol. 11, No. 4 (Apr. 2010), URL: http://www.BRCommunity.com/a2010/b532.html  

# # #