Writing Natural Language Rule Statements — a Systematic Approach Part 30: More Rule Statement Quality Criteria

Graham   Witt
Graham Witt Consultant / Author Read Author Bio || Read All Articles by Graham Witt
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.
RS21. Each Travel Insurance Application
must specify whether it is for international travel or for domestic travel.
RS319. †Each Flight Booking Request
    that specifies a Destination City that is outside Australia
    and an Origin City that is within Australia
must specify whether it is the City of Residence of each Passenger.
RS320. Each Flight Booking Request
    that specifies a Destination City that is outside Australia
    and an Origin City that is within Australia
must specify whether the Origin City is the City of Residence of each Passenger.
  1. 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).
RS321. †A Party
    who acts on behalf of another Party
must be cited by the Party
    in an Authorization to Transact.
RS322. A Party
    who acts on behalf of another Party
must be cited by the second Party
    in an Authorization to Transact.
RS323. An Agent
    who acts on behalf of a Client
must be cited by the Client
    in an Authorization to Transact.
  1. 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).
RS324. †An Applicant for Employment
must hold an Australian Passport
    or a Business Skills Visa
    and an Australian State Driving License.
RS325. An Applicant for Employment
must hold an Australian Passport
    or both a Business Skills Visa and an Australian State Driving License.
RS326. An Applicant for Employment
must hold an Australian State Driving License
    and either an Australian Passport or a Business Skills Visa.

An alternative approach is to use bullets to separate clauses:

RS327. An Applicant for Employment
must hold:
• an Australian Passport; or
• a Business Skills Visa and an Australian State Driving License.
(equivalent to RS325)
RS328. An Applicant for Employment
must hold:
• an Australian State Driving License; and
• an Australian Passport or a Business Skills Visa.
(equivalent to RS326)
  1. 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".

  2. 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.
RS329. †A Passenger
may pass through Departure Control
only if that Passenger presents a Passport.
RS330. A Passenger
may pass through Departure Control
only 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.
  1. 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.
RS331. Lodgement Cases
contain by definition
at least one Registry Instrument.
RS332. A Lodgement Case
contains by definition
at least one Registry Instrument.
  1. 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).

RS333. Each Flight Booking Request
must specify exactly one Departure Date.
RS334. Each Flight Booking Request that is for a Return Journey
must specify exactly one Return Date.

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:
RS335. An Infant Passenger is by definition
a Passenger whose Age is less than 2 years at the Time of Travel.
  1. "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:
RS336. A Journey is by definition
a One-Way Journey, a Return Journey or a Multi-Stop Journey.
  1. "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.
RS337. Each Flight has by definition
exactly one Origin Port.
  1. "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.
RS338. Each Flight Booking Request
must specify exactly one Origin City.
  1. "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
    1. 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
    1. 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  return to article

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# # #

Standard citation for this article:


citations icon
Graham Witt , "Writing Natural Language Rule Statements — a Systematic Approach Part 30: More Rule Statement Quality Criteria" Business Rules Journal Vol. 16, No. 2, (Feb. 2015)
URL: http://www.brcommunity.com/a2015/b800.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
Subscribe to the eBRJ Newsletter
In The Spotlight
 Silvie  Spreeuwenberg
 Ronald G. Ross

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.