What is this series of articles about?

This is the twelfth 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.

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

I've just returned from giving a presentation on this technique at this year's Business Rules Forum in Las Vegas, and I received a variety of feedback.  Although a number of delegates expressed interest in applying this technique to their own business rules management environments, others suggested that templates are not appropriate in the formulation of business rule statements.

Quite apart from the fact that this technique is being successfully employed by a large Australian government agency, I believe the following argument supports the use of templates.

If we wish to state a particular rule, there is a considerable number of statements that we might utter or write in an attempt to express that rule.  Even if we limit ourselves only to statements that contain only meaningful, correctly-spelt words and that are syntactically correct, there are still many possibilities.  We can go further and state that only terms from the organisation's vocabulary are used and that the only sentence forms allowed are
    <subject phrase> must {not|} <predicate> {if <conditional clause>|}
or
    <subject phrase> may only <predicate> if <conditional clause>.

This still allows for many possibilities:

1. statements that do not express the intended rule but some other rule, through the use of terms or verb phrases other than those required to express the intended rule.
   
   
2. statements that do not express the intended rule but some other rule, by misplacing the true subject of the intended rule.  A good example of this is a rule statement that I encountered in a recent article by another author:  "A 'flammable' sticker must be displayed on a tank containing a combustible fuel."  What this rule statement actually mandates is what to do if you have a 'flammable' sticker rather than what to do if you have a tank containing a combustible fuel.  To put it another way, a 'flammable' sticker displayed on something other than a tank containing a combustible fuel, or not displayed on anything, violates this rule statement, whereas a tank containing a combustible fuel without a sticker doesn't violate this rule statement.  The correct formulation of a rule statement to reflect the intended rule is "A tank containing a combustible fuel must be labelled with a 'flammable' sticker."
   
   
3. statements that are ambiguous.
   
   
4. statements that express the intended rule in an unambiguous manner.

Clearly only rule statements in the last of these four categories are appropriate.  But there is likely to be more than one possible rule statement for any given rule even in the last category.  For example, there is a requirement that each flight booking confirmation specify at least one passenger name.  This requirement can be expressed using numerous formulations, some invalid, others valid, for example:

1. Each flight booking request must specify at least one passenger name. 
   (invalid:  inappropriate term)
   
   
2. Each flight booking confirmation must contain at least one passenger name.
   (invalid:  inappropriate verb phrase)
   
   
3. There must be at least one passenger name in each flight booking confirmation. 
   (invalid:  misplaced rule subject)
   
   
4. A flight booking confirmation must specify at least one passenger name. 
   (valid:  intended rule, unambiguous)
   
   
5. Each flight booking confirmation must specify either one passenger name or more than one passenger name. 
   (valid:  intended rule, unambiguous)
   
   
6. Each flight booking confirmation must specify one or more passenger names. 
   (valid:  intended rule, unambiguous)
   
   
7. Each flight booking confirmation must specify at least one passenger name. 
   (valid:  intended rule, unambiguous)

Within the organisation there may be a preference for one of the valid formulations over the others, or one formulation may find less favour, e.g., 5 may be seen as too wordy or 4 not as rigorous as the others.  At the same time there may be two formulations that seem equally appropriate, e.g., 6 and 7.  In just the same way as Australia has opted for driving on the left (despite there being nothing intrinsically better about driving on the left instead of the right), it is better for everyone in an organisation to agree to use one formulation rather than the other, although the stakes are admittedly rather higher on the roads!

Templates provide a means of documenting the agreed rule statement formulation for each type of rule.

New qualifying and conditional clause formulations

In the previous article^[3] we introduced the following additional clause formulations:

1. {that is|} of the {{first|last} or only|second or any subsequent|previous|next} <term>
   
   
2. {that is|} other than the {first|last}
   
   
3. that specifies <cardinality> <term>
   
   
4. <preposition> {which|whom} {<article>|each|that|those} <term> <verb phrase>, e.g.,
   at which those flights connect, on which a seat is available
   
   
5. <preposition> {which|whom} {<article>|each|that} <term> <chained condition>, e.g.,
   for whom the date of birth is specified in that flight booking confirmation

for qualifying clauses and:

6. no <term> <verb phrase>

for conditional clauses.

We saw that formulations 1 and 3 require additional determiners between <verb phrase> and <term> in a <simple condition>.

Formulation 2 requires other than the {first|last} as an alternative <final condition>.

Formulation 4 is an alternative form of <simple qualifying clause> whereas formulation 5 is an alternative form of <chained qualifying clause>.

Finally, formulation 6 requires no as an alternative determiner before <term> in a <condition subject>.

The relevant sub-templates are:

The enhanced sub-templates are respectively:

Note that ST50 does not include a complete list of possible determiners; we shall look at others in subsequent articles.

Process rules

In the previous article, we also introduced a number of rules governing the minimum time intervals required to make transits between flights.  Similarly, there is a requirement to check in for the first or only flight in each direction in sufficient time.  These requirements could be expressed in rule statements RS96 to RS99.

These rules are very similar to the rules we've previously looked at governing minimum time intervals, yet there's a fundamental difference.  All rules so far discussed in these articles have governed the provision of information (with one exception, RS37 — see the [sidebar]).  Many of those rules have been based on what is an acceptable or unacceptable process, such as all of those dealing with minimum time intervals, and RS75 which governs travel by infants.  They can all, however, be classified as information rules since the overall process flow requires that the intended travel process be defined (by way of information) before it actually occurs.

However, a passenger (or their travel arranger) does not have to specify in advance when the passenger is going to check in, so the rule statements above govern the process itself rather than information about the process.  For this reason, I'm defining these as process rules rather than information rules.  In particular, these rules define the latest time at which a process (check-in) can occur in terms of another process (the departure of a flight), so these are inter-process interval rules.

Before developing a template for rule statements expressing this type of rule, let us consider some alternative situations we may wish to cover:

1. The subject process in each of RS96 to RS99 is expressed as an intransitive verb phrase, but could just as easily be a transitive verb phrase with a term (possibly followed by a qualifying clause) as the object of that verb phrase, e.g.,
   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.
   
   
2. There may be a maximum interval between the processes — typically one cannot check in to a domestic flight more than 2 hours before departure or an international flight more than 3 hours before departure.
   
   
3. Some rules govern how soon a process must occur, start, or be completed after (rather than before) some other process, e.g., a travel arranger must confirm the payment made for a flight booking within a certain interval (say 10 minutes) after the flight booking confirmation form is first displayed.
   
   
4. Sometimes the obligation to perform or complete a process (or prohibition of a process) doesn't lie with a particular class or role of party — in this case, the subject of the rule statement should be the process rather than the obligated part, e.g.,
   Online check-in for a flight must not occur earlier than 24 hours before the departure time of that flight.

Considerations 2 and 3 are neatly covered by an existing sub-template, ST17:

Thus, ignoring (for the moment) consideration 4, we can formulate the following template for inter-process interval rules:

To be continued...
In subsequent articles we will look further at process rules as well as looking at restricted permission rules, rules governing the parties or roles that are allowed to perform a process or use information, and rule statement quality assessment, including identification of redundant and conflicting rule statements.

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 11)," Business Rules Journal, Vol. 10, No. 12 (Dec. 2009), URL:  http://www.BRCommunity.com/a2009/b514.html  

# # #