A Practical Method of Developing Natural Language Rule Statements (Part 13)

Graham   Witt
Graham Witt Consultant / Author Read Author Bio || Read All Articles by Graham Witt
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]

From Check-in to Boarding

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.

RS100. Each passenger must board the flight for which that passenger has checked in no later than 15 minutes before the departure time of that flight.

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

RT30. Each <term 1> <qualifying clause>
must <verb phrase>
{<
determiner> <term 2> {<qualifying clause>|}|}
<time range predicate>
{{
if|unless} <conditional clause>|}.
ST17. <time range predicate> ::=
  {no|} {later|earlier} than
{<
literal>|
{<
literal> {after|before}|} the <term> {<qualifying clause>|}}

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

RS101. Online check-in for a flight must not occur earlier than 24 hours before the departure time of that flight.

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).

RS102. Online check-in for a flight may only occur during the 24 hours before the departure time of that flight.
RT31. {<determiner>|} <term 1> <qualifying clause 1>
{
must{ not|}|may only} <verb phrase>
{<
determiner> <term 2> {<qualifying clause 2>|}|}
<time range predicate>
{{
if|unless} <conditional clause>|}.
ST51. <time range predicate> ::=
  {{no|} {later|earlier} than <literal>|
{
no|} {later|earlier} than {<literal> {after|before}|}
        
the <term> {<qualifying clause>|}|
during the <literal> {after|before}
        
the <term> {<qualifying clause>|}}

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

FT83.  passenger boards flight
FT84.  passenger checks in for flight
FT37.  flight has departure time

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

FT85.  online check-in is for flight

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.

RS103. Each passenger must check in for a flight before that passenger boards that flight.
RS104. A passenger may only board a flight after that passenger checks in for that flight.

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.

RS105. A passenger may only board an international flight after that passenger undergoes departure control.
RS106. A passenger may only board a flight after that passenger undergoes security screening.
RS107. A passenger may only undergo departure control after that passenger undergoes check-in.
RS108. A passenger may not board a flight if that passenger enters landside after the last security screening of that passenger.

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.

RS109. A passenger may only board a flight if that passenger presents a boarding pass that specifies that flight and specifies the departure date of that flight.
RS110. A passenger may only board an international flight if that passenger presents a passport that specifies the name of that passenger and bears a likeness of that passenger and specifies an expiry date that is later than 6 months after the departure date of that flight.
RS111. A passenger may only pass through departure control if that passenger presents a boarding pass in which the departure date is no earlier than the date of departure control and is no later than 1 day after the date of departure control.
RS112. A passenger may only pass through departure control if that passenger presents a passport that specifies the name of that passenger and bears a likeness of that passenger and specifies an expiry date that is later than 6 months after the date of departure control.
RS113. A passenger may only pass through departure control if that passenger presents a boarding card that specifies the name of that passenger and specifies a departure date that is no earlier than the date of departure control and is no later than 1 day after the date of departure control.
RS114. A passenger may only pass through security screening for an international flight if that passenger presents a boarding pass that specifies a departure date that is no earlier than the date of security screening and is no later than 1 day after the date of security screening.
RS115. A passenger may only pass through security screening for an international flight if that passenger presents a passport that specifies the name of that passenger and bears a likeness of that passenger and specifies an expiry date that is later than 6 months after the date of security screening.

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.  return to article

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  return to article

[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.  return to article

[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  return to article

# # #

Standard citation for this article:


citations icon
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

About our Contributor:


Graham   Witt
Graham Witt Consultant / Author

Graham Witt has over 30 years of experience in assisting organisations to acquire relevant and effective IT solutions. NSW clients include the Department of Lands, Sydney Water, and WorkCover while Victorian clients include the Departments of Sustainability & Environment, Education & Early Childhood Development, and Human Services. Graham previously headed the information management and business rules practice in Ajilon's Sydney (Australia) office.

Graham has developed specialist expertise in business requirements, architectures, information management, user interface design, data modelling, relational database design, data quality, business rules, and the use of metadata repositories & CASE tools. He has also provided data modelling, database design, and business rules training to various clients including NAB, Telstra, British Columbia Government, and ASIC and in the form of public courses run by Simsion Bowles and Associates (Australia) and DebTech (USA).

He is the co-author, with Graeme Simsion, of the widely-used textbook "Data Modeling Essentials" and is the author of the newly published book, "Writing Effective Business Rules" (published by Elsevier). Graham has presented at conferences in Australia, the US, the UK, and France. Contact him at gwitt@pacific.net.au.

Read All Articles by Graham Witt

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.