What is this series of articles about?

This is the thirteenth 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.  This month, as well as including the templates added last month, I've updated both the taxonomy and the table which indicates the appropriate (sub-)templates.

The taxonomy, templates, and sub-templates are listed in the [sidebar]^** along with all valid rule statements and supporting fact types.  This month I've added a number of fact types supporting rule statements added in recent articles, and I've also removed fact types FT18 and FT19 which duplicated FT6 and FT7; thanks to reader Anouar Beji for pointing this out.

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

In the previous article^[3] we looked at some rules governing the process of checking in at the airport, and I mentioned in passing a couple of rules, one governing boarding a flight and one governing online check-in.  Let us look at the rule governing boarding first.

This rule statement can be generated using template RT30 and sub-template ST17, reproduced below.

By contrast, rule statement RS101 (governing online check-in) cannot be generated using template RT30.

This is for the following reasons:

1. This rule statement is expressed as a prohibition (must not) rather than an obligation (must).
   
   
2. In the same way as prohibited data rules start with {a|an} rather than each (as in mandatory data rules), this rule statement does not start with each.
   
   
3. References to a process (online check-in) rather than an obligated (or prohibited) party (passenger) often read better without any preceding determiner (such as a, an, the, or each).

Before we enhance RT30 to accommodate these variations (in the form of RT31), note that RS101 could be alternatively expressed as a restricted permission, as in RS102.  This formulation also requires an enhancement to ST17 (in the form of ST51).

You may recall that rule statements are based on fact types.  In particular, RS100 is based on the following fact types:

RS101 and RS102 are based on the following fact type in addition to FT36:

There are other rules governing boarding a flight.  Some identify the processes that each passenger must have already undergone — check-in, departure control (in the case of an international flight), and security screening — while others identify the documentation that must be presented by each passenger — a boarding pass and (in the case of an international flight) a passport.

The other processes are governed by similar rules:

1. Check-in requires that a booking on the relevant flight must have been made for each presenting passenger and that each passenger presents photo identification and (in the case of an international flight) a passport.
   
   
2. Departure control requires that each passenger has undergone check-in and that each passenger presents a boarding pass, a passport, and a departure card.
   
   
3. Security screening for domestic flights (in Australia, at least) has no documentation requirements nor any prerequisite processes (for example, one can pass through security screening to meet a passenger off an incoming flight), but security screening for international flights (which is restricted to passengers) requires each passenger to present a boarding pass and passport.

There are also rules governing each passenger's documentation:

1. The photograph in each passport must be a likeness of the passenger.
   
   
2. The name in each passport presented at check-in must match a name in the booking.  After check-in, the name in each passport presented must match the name on the same passenger's boarding pass.
   
   
3. The passport must also not only be current but be valid for a minimum ongoing period, typically 6 months.  This is verified at check-in, as the airline is liable for return of a passenger rejected by border control on entry to the destination country.  I've never tested whether this is verified again during departure control, security screening, or boarding.
   
   
4. At boarding, the flight specified on each boarding pass presented must be the flight departing from that gate.
   
   
5. At departure control, the date specified on each boarding pass and departure card must be the date of passing through departure control (or the following day, if the flight departs in the early hours of the morning).  At boarding, the date specified on each boarding pass must be the departure date of the flight.
   
   
6. The name specified on each departure card must match the name on the same passenger's passport and boarding pass.

Note also that a passenger can only board a flight if he/she has not only passed through security screening but stayed 'airside', i.e., not returned to 'landside' (that part of the airport outside the security screen).  On a trip to visit my family at the end of last year, I discovered, after passing through security at Sydney airport, that there were none of my bank's ATMs (Automatic Teller Machines) past that point, whereas there was an ATM just before security.  I therefore went back through security to withdraw cash, but then had to undergo security screening again.

How should these rules be expressed in rule statements?  Let us look first at the rules identifying the prerequisite processes for each process.  There are two ways in which each such rule can be expressed:

1. as an obligation (on the part of the passenger about to undergo the dependent process) to have undergone some other process previously;
   
   
2. as a restricted permission for the passenger to undergo the dependent process only if he/she has undergone the other process previously.

In the case of the boarding process, rule statements RS103 and RS104 each express the requirement that each boarding passenger has undergone check-in — RS103 as an obligation and RS104 as a restricted permission.

Rule statements RS105 – RS107 express the other prerequisite process rules previously identified, each as a restricted permission.  (You can, if you wish, try writing each of these rules as an obligation statement.)  Rule statement RS108, by contrast, is one way of stating that an additional security screening is required of any passenger who returns to 'landside' after a security screening.

Let us now look at the rules identifying the required documentation for each process.  Again, each such rule can be expressed as either an obligation or a restricted permission.

In the case of the boarding process, rule statement RS109 expresses the requirement that each boarding passenger presents a valid boarding pass, while RS110 expresses the requirement that each passenger boarding an international flight presents a valid passport.  Similarly, RS111 – RS113 cover the documentation requirements for departure control, while RS114 and RS115 cover the documentation requirements for security screening for international flights.

In the next article we will look at the additional template(s) from which these rule statements can be generated.

Rule Statement Quality Checking

In various discussions I've had with clients and with rule repository vendors, a recurring subject has been quality assurance of rule statements.

The quality of a rule statement can be checked against a number of criteria:

1. Each word or phrase in the rule statement must be correctly spelt in the language used by the organisation, e.g., Australian English.
   
   
2. Each noun phrase in the rule statement must be a term in the vocabulary or fact model used by the organisation.
   
   
3. Each term in each rule statement must be a preferred term rather than any synonym of a preferred term.
   
   
4. Some practitioners and tools proscribe the use of certain words in rule statements, e.g., personal pronouns (such as "you") or adverbs of time and place (such as "here" and "now") that would be ambiguous in rule statements.  However, if a rule statement is generated from a template (criterion 7) and based on fact types in the fact model (criterion 9), all words in a rule statement will of necessity be terms in the vocabulary, verb phrases in the fact model, or keywords in the template or sub-templates, none of which should include any proscribed words.
   
   
5. The rule statement must include a rule keyword, i.e., must or may … only.
   
   
6. The rule statement must form a syntactically-correct sentence.
   
   
7. The rule statement should conform to the rule statement template appropriate to the type of rule.  (I have worded this with "should" rather than "must" as there are practitioners who disagree with the use of templates; disagreement on this one criterion should not cause rejection of this entire list).
   
   
8. The rule statement must not be self-contradictory.
   
   
9. The rule statement must be based on fact types in the fact model.
   
   
10. The subject of the rule statement must be the thing that is to be tested by the rule.  See my discussion of "A 'flammable' sticker must be displayed on a tank containing a combustible fuel" in the previous article.
    
    
11. The rule statement must not be ambiguous.  There are various ways in which a rule statement may be ambiguous, some of which I've discussed already.  I'll revisit ambiguity in the next article.
    
    
12. The rule statement must not duplicate, overlap, or contradict any other rule statement.  There are various ways in which a rule statement may overlap or contradict another rule statement.  I'll discuss these in the next article.

To be continued...
In subsequent articles we will look at more templates for process rules, rules governing the parties or roles that are allowed to perform a process or use information, and identification of ambiguous, redundant, or conflicting rule statements.

Erratum

[**]  Sub-template ST50, introduced last time, contained an error.  The corrected version of ST50 appears in this month's sidebar.  

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 12)," Business Rules Journal, Vol. 11, No. 1 (Jan. 2010), URL:  http://www.BRCommunity.com/a2010/b518.html  

# # #