About this series of articles

While my first series of articles on writing natural language rule statements^[1] explored a wide variety of issues in a rather organic and hence random manner, this series takes a more holistic and systematic approach and draws on insights gained while writing my recently-published book on the same topic.^[2]  Rule statements recommended in these articles are intended to comply with the Object Management Group's Semantics of Business Vocabulary and Business Rules (SBVR) version 1.0.^[3]

The story so far

In earlier articles in this series (see the "Language Archives" sidebar) we have looked at standardised rule statements for various types of operative rules^[4] (data rules,^[5] activity rules,^[6] and party rules^[7]) and definitional rules.^[8]  Each specific type of rule statement has a common formulation which we have discussed in both a relatively informal way and by way of rule statement patterns.  We also looked at the syntactic components that may be found in rule statements of all types, namely prepositional phrases,^[9] qualifying clauses,^[10] terms,^[11] and determiners,^[12] verbs,^[13] and conditional clauses.^[14]

In the previous article^[15] we looked at some rule statement quality criteria.  In this article we will look at some more criteria.

Ambiguity

Every rule statement should be unambiguous.  The following are just a few of the possible sources of ambiguity:

1. A rule statement should not include any personal pronouns (e.g., it, her) unless there is only one term before the pronoun, and the pronoun refers to that term, as in RS21.  If more than one term precedes the pronoun, it is not always clear which term the pronoun refers to. For example, in RS319, while it is obvious that it does not refer to Flight Booking Request or Australia, it could refer to either Origin City or Destination City.  RS320 resolves this ambiguity.

2. Similarly, where the same term is used more than once in the same rule statement to signify different instances of the same concept, any subsequent uses of that term must be qualified to indicate which instance is signified.  For example, the third use of Party in rule statement RS321 is ambiguous:  while this can be clarified (in this case at least) by preceding the third use of Party by second (as in RS322), a more general solution would be to create specific business terms for at least one of the two Parties involved and use those terms instead (as in RS323).

3. A rule statement that includes both and and or in a qualifying or conditional clause may be ambiguous.  For example, in RS324 it is not clear whether an applicant holding an Australian passport must also hold an Australian state driving license.  Note however that either or both may be used to remove ambiguity; the following formulations are not ambiguous:
1. term (and term …) and either term or term (as in RS325)
2. term (or term …) or both term and term (as in RS326).

An alternative approach is to use bullets to separate clauses:

4. Similarly, a qualifying clause that includes both that and and (or that and or) may be ambiguous.  For example, "a Car that belongs to a Person that lives in Sydney and that is white" does not make clear whether it is the car or the person that is white.  Note that, if this type of formulation is required, it can be made unambiguous by reordering the formulation so that and or or precedes that, as in "a car that is white and that belongs to a person that lives in Sydney".
   
   
5. Unless a term used in a rule statement genuinely refers to all members of the set signified by the term, as in "one of the Australian States", that term must be qualified by a qualifying clause that identifies which member(s) of the set the rule statement refers to.  RS329 contravenes this guideline, whereas RS330 complies.

6. So as to make clear the constraints on each member of the set signified by the subject term, every rule statement should include the singular rather than the plural form of the that term, e.g., RS332 is correct whereas RS331 is incorrect.

7. A range predicate that includes both at least and less than (or fewer than) may be ambiguous.  Consider the predicate "at least 2 fewer than the Number of Passengers":  does three fewer than the number of passengers agree with that predicate or not?  If this predicate is intended to mean "(at least 2) fewer than the Number of Passengers", that quantity does agree with the predicate, but if it means "at least (2 fewer than the Number Of Passengers)", it does not.  However, despite their use in mathematical formulae, parentheses are not used in this way in natural language.  See Part 5 in this series for advice on how to reframe rule statements to avoid this issue.^[16]

Self-contradiction

Every operative rule statement has a scope, namely the set of potential transactions, data items, activities, or parties governed by the stated rule.  For example, the scope of RS333 is all flight booking requests, whereas the scope of RS334 is only those flight booking requests that are for return journeys (not those for one-way or multi-stop journeys).

RS334 illustrates that, if the subject term of a rule statement is qualified by a qualifying clause, the scope of that rule statement is reduced, i.e., the rule statement applies to fewer instances of the concept signified by the subject term.  Such a clause must not contradict the definition of the term being qualified, since then the scope of the rule statement would be reduced to the empty set, meaning that the stated rule would never govern anything.  Consider the following examples:

1. "An Infant Passenger whose Age is more than 2 years at the Time of Travel …":  here the qualifying clause contradicts the definition of the term Infant Passenger in RS335:

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 listed in RS336:

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 every flight has just one origin port, as defined in RS337.

4. "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 RS338.  Note that, by contrast with the example above that contradicted RS337, 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.

5. "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 (passenger names are not supplied until the flight booking confirmation stage so no flight booking request specifies passenger names).

I have encountered rule authoring teams that build the fact model by adding all fact types required to support each rule statement.  Such an approach would (for example) create the fact type "Flight Booking Request specifies Passenger Name" as soon as a rule statement containing "A Flight Booking Request that specifies a Passenger Name …" is encountered, rather than use the absence of that fact type to question the validity of that rule statement.

A more appropriate approach to building a fact model is through 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:

FT43.	Airline serves City
FT44.	Flight is operated by Airline
FT45.	Flight has Origin City
FT46.	Flight has Departure Time
FT47.	Fare class is available on Flight
FT48.	Port has Minimum Domestic Transit Time

2. What processes and events occur and who and/or what is involved?  For example:

FT49.	Passenger is booked on Flight
FT50.	Passenger checks in for Flight
FT51.	Passenger presents Boarding Pass

3. What information is created or used in each process?  For example:

FT52.	Flight Booking Request specifies Departure Date
FT53.	Flight Booking Confirmation specifies Passenger Name

The scope of a rule statement can alternatively be reduced by adding a conditional clause.  Again such a clause must not contradict the definition of the term being qualified.  The following conditional clauses are therefore inappropriate for the same reasons as discussed above:

1. the Age of that Infant Passenger is more than 2 years 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 no Origin City,
   that Flight Booking Request specifies more than one Origin City
   
   
5. that Flight Booking Request specifies a Passenger Name

If a rule statement includes both a qualifying clause and a conditional clause, the conditional and qualifying clauses must not contradict each other.  For example, in "A flight booking request that specifies a return journey must … if that flight booking request does not specify a return journey", the combination of clauses limits the scope of the rule statement to the empty set, so the stated rule would never govern anything.  Of course, a rule statement author is unlikely to include such obviously contradictory clauses but anything's possible!

The inclusion of a self-contradictory qualifying or conditional clause, such as "that is less than 1 year and more than 2 years", "that is a one-way journey and a return journey", "that flight has no origin port and has more than one origin port", or "that flight booking request specifies a passenger name and does not specify a passenger name" is even less likely but equally invalid.

To be continued...
In the final article in this series, I will look at the remaining quality criteria that govern rule statements.

References

[1]  The first of which is:  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 1)," Business Rules Journal, Vol. 10, No. 2 (Feb. 2009), URL:  http://www.BRCommunity.com/a2009/b461.html  

[2]  Graham Witt, Writing Effective Business Rules, Morgan Kaufmann (2012).  

[3]  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/
     The font and colour conventions used in these rule statements 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, these conventions are not used for rule statements that exhibit one or more non-recommended characteristics.  

[4]  A rule that states what must or must not happen in particular circumstances, and which can therefore be contravened, by contrast with a definitional rule.  

[5]  A rule that constrains the data included in a transaction (a form or message) or a persistent data set (e.g., a database record).  

[6]  A rule that constrains the operation of one or more business processes or other activities.  

[7]  A rule that makes a distinction between different parties or the roles they play.  

[8]  A rule that defines a construct created or used by an organisation (or the industry within which it operates), or defines a property of such a construct, and which cannot therefore be contravened, by contrast with an operative rule.  

[9]  A phrase formed from:
    • a preposition, such as for, from, in, of, on, to, or (in the case of a temporal constraint) after, before, during, earlier than, later than
    • an optional determiner, such as a, an, any, each, that, the
    • a term, such as passenger, credit card.  

[10]  A clause used after a term in two ways:
    1. following the subject term of a rule statement, to restrict the scope of that rule statement to a subset of the set of objects signified by that term, rather than the set of all objects signified by that term (e.g., 'for a return journey' in "Each flight booking request for a return journey must specify exactly one return date.")
    2. following any other term in a rule statement, to make a constraint more specific than if the qualifying clause were absent (e.g., 'that is current' in "Each passenger must present a passport that is current.").  

[11]  A noun used to refer to any concept that is of interest to the organisation.  

[12]  A word or phrase used before a noun to provide some information as to which instance (or instances) of the noun's concept are being referred to, such as the, my, this.  

[13]  A word that:
    1. inflects, in that the form after a singular noun, 'he', 'she', or 'it' (e.g., is and specifies) is different to the form after a plural noun or 'they' (are and specify respectively)
    2. has a form (the infinitive) that can follow a modal auxiliary (in particular must and may).  

[14]  A clause in a rule statement generally following if or unless, and consisting of either a single subject and predicate or two or more subject-predicate pairs separated by and or or.  

[15]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach —Part 29 — Some Rule Statement Quality Criteria," Business Rules Journal, Vol. 16, No. 1 (Jan. 2015), URL:  http://www.BRCommunity.com/a2015/b794.html  

[16]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 5: Value Set Rules," Business Rules Journal, Vol. 13, No. 11 (November 2012), URL:  http://www.BRCommunity.com/a2012/b677.html  

# # #