Writing Natural Language Rule Statements — a Systematic Approach Part 31: Even 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] determiners,[12] verbs,[13] and conditional clauses.[14]

In the previous two articles[15]we looked at some rule statement quality criteria.  In this final article in this series we will look at the remaining criteria, and summarise all criteria.

Redundant qualifying and conditional clauses

Occasionally I encounter the inclusion by over-cautious authors of redundant qualifying clauses in rule statements.  A redundant qualifying clause is one that has no effect, in that every member of the set signified by the qualified term meets the criterion expressed in the qualifying clause; thus no members of that set are excluded from the coverage of the rule statement by virtue of the qualifying clause.  Here are some examples:

  1. "An Infant Passenger whose Age is less than 2 years at the Time of Travel ":  since the qualifying clause repeats the definition of the term Infant Passenger provided in RS335, it is true for every infant passenger.
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 a One-Way Journey, a Return Journey, or a Multi-Stop Journey ":  since the qualifying clause lists all the categories of Journey as defined in RS336, it is true for every journey.
RS336. A Journey is by definition
a One-Way Journey, a Return Journey, or a Multi-Stop Journey.
  1. "A Flight that has an Origin Port ":  since the qualifying clause repeats the fact that, by definition, every flight has a single origin port, as stated in RS337, it is true for every flight.
RS337. Each Flight has by definition
exactly one Origin Port.
  1. "A Flight Booking Request that does not specify a Passenger Name ":  this qualifying clause is irrelevant because the fact type "Flight Booking Request specifies Passenger Name" does not exist, i.e., no flight booking requests specify passenger names.

Conditional clauses which do not limit the scope of their rule statements are similarly redundant, including the following examples:

  1. the Age of that Infant Passenger is less than 2 years at the Time of Travel

  2. that Journey is a One-Way Journey, a Return Journey, or a Multi-Stop Journey

  3. that Flight has an Origin Port

  4. that Flight Booking Request does not specify a Passenger Name

A conditional clause that repeats the qualifying clause, as in "A Flight Booking Request that specifies a Return Journey must … if that Flight Booking Request specifies a Return Journey", is also redundant.

Duplicate rule statements

If two rule statements are semantically equivalent (duplicate each other), one of them should be deleted.  Here are some examples:

  1. If a rule statement includes a conditional clause introduced by unless, it can be rephrased by changing unless to if and negating the first verb phrase in the conditional clause, e.g., "unless the Flight is domestic" can be rephrased as "if the Flight is not domestic".  More insidiously "unless the Flight is domestic" and "if the Flight is international" mean the same thing since is domestic and is international are mutually-exclusive and jointly-exhaustive characteristics.  Two rule statements that are identical except for such a rephrasing are equivalent.

  2. Comparison operators can be expressed in alternative ways, as in the next two examples, which are equivalent.
RS339. The Order Quantity specified in each Line of an Order
must be no less than 1.
RS340. The Order Quantity specified in each Line of an Order
must be at least 1.
  1. Comparison operators can also be expressed in an equivalent reversed form, as in the next two examples, which are equivalent.
RS341. A Flight Booking Confirmation
must not specify the Code of a Special Offer
if the Departure Date
      specified in that Flight Booking Confirmation
      is later than the Expiry Date of that Special Offer.
RS342. A Flight Booking Confirmation
must not specify the Code of a Special Offer
if the Expiry Date of that Special Offer
      is earlier than the Departure Date
      specified in that Flight Booking Confirmation.
  1. A rule statement can refer to either "an International Flight" or "a Flight that is international", with no change of meaning.  Two rule statements that are identical except for such a rephrasing are equivalent.

Overlapping rule statements

Any two rule statements may overlap, in that one implies the other.  Should this occur, one of those statements should be deleted. Here are some examples:

  1. Two rule statements overlap if they impose the same condition on a term and the term representing its subset.  For example, RS343 and RS344 would overlap since an Online Flight Booking Request is a type of Flight Booking Request; thus RS343 implies RS344.  Again, only one should be retained; here, however, unlike with equivalent rule statements, the choice of statement to be retained has semantic implications.  RS343 is the correct one here, since the rule applies to all flight booking requests, whether online or not.  If however the rule only applied to online flight booking requests, RS343 would be the one to delete.
RS343. Each Flight Booking Request
must specify exactly one Origin City.
RS344. Each Online Flight Booking Request
must specify exactly one Origin City.
  1. Two rule statements overlap if they are identical except for the presence or absence of a qualifying clause.  For example, RS346 implies RS345.  In this case the rule statement to delete is RS346 (since no return date is required for a one-way journey).
RS345. Each Flight Booking Request for a Return Journey
must specify exactly one Return Date.
RS346. Each Flight Booking Request
must specify exactly one Return Date.
  1. Two rule statements overlap if they are identical except for semantically different qualifying clauses.  For example, RS347 implies RS348.  Only one of these rule statements can be correct.
RS347. Each Bag that weighs more than 20kg
must be labelled with a 'Heavy Bag' Label.
RS348. Each Bag that weighs more than 30kg
must be labelled with a 'Heavy Bag' Label.
  1. Two rule statements overlap if they are identical except for the presence or absence of a conditional clause.  For example, RS350 implies RS349.  Again, only one of these rule statements can be correct.
RS349. Each Flight Booking Confirmation
must specify exactly one Date of Birth for each Passenger
if that Flight Booking Confirmation specifies an Insurance Option.
RS350. Each Flight Booking Confirmation
must specify exactly one Date of Birth for each Passenger.
  1. Two rule statements overlap if they are identical except for semantically different conditional clauses.  For example, RS351 implies RS352.  Again, only one of these rule statements can be correct.
RS351. Each Flight Booking Confirmation
must specify exactly one Set of Passport Details for each Passenger
if any Flight specified in that Flight Booking Confirmation is international.
RS352. Each Flight Booking Confirmation
must specify exactly one Set of Passport Details for each Passenger
if all Flights specified in that Flight Booking Confirmation are international.
  1. A restricted permission statement, such as RS353, may imply a prohibition statement, such as RS354.  In this situation the implied statement (in this case RS354) is redundant.
RS353. Each Flight Booking Request
may specify a Return Date
only if that Flight Booking Request is not for a One-Way Journey.
RS354. A Flight Booking Request for a One-Way Journey
must not specify a Return Date.

Contradictory rule statements

If two rule statements contradict each other (i.e., they cannot both be true), one should be deleted.  Here are some examples:

  1. Two cardinality rule statements contradict each other if they are identical except for cardinality, e.g.,
RS355. Each Flight Booking Request
must specify exactly one Travel Class.
RS356. Each Flight Booking Request
must specify at least one Travel Class.
  1. Two data content rules of the same type contradict each other if they are identical except for their predicates and those predicates contradict each other, e.g.,
RS357. The Travel Class specified in each Flight Booking Request
must be First Class, Business Class, Premium Economy Class, or Economy Class.
RS358. The Travel Class specified in each Flight Booking Request
must be First Class, Business Class, or Economy Class.

Using multiple complementary rule statements to state a single rule

Consider the following rule statements:

RS359. Each Flight Booking Request for a Return Journey
must specify exactly one Travel Class.
RS360. Each Flight Booking Request for a One-Way Journey
must specify exactly one Travel Class.
RS361. Each Flight Booking Request for a Multi-Stop Journey
must specify exactly one Travel Class.

It should be obvious that all flight booking requests, irrespective of the type of journey specified, need to specify a travel class.  These three rule statements, therefore, should be replaced by RS355 above.

Making the wrong term the subject of the rule statement

Consider RS362, which appears to be an alternative way of stating RS355.  However it is stated, the intended rule is one which tests each Flight Booking Request to establish whether a Travel Class is present.  It is not intended to test each Travel Class to establish whether it is specified in a Flight Booking Request!  The subject of the rule statement should therefore be Flight Booking Request (as in RS355) rather than Travel Class (as in RS362).

RS362. †Exactly one Travel Class must be specified in each Flight Booking Request.

Rule statement quality criteria summary

As we have seen in this and the previous article, all natural language rule statements should comply with the following criteria:

  1. Each word or phrase in the rule statement must be correctly spelt in the language used by the organisation, e.g., US or Australian English.

  2. The rule statement must form a syntactically-correct sentence.

  3. Each term in the rule statement must be a term in the fact model used by the organisation; in particular, each term in the rule statement must be a preferred term rather than any synonym of a preferred term.

  4. The rule statement must be based on fact types in the fact model used by the organisation (see the previous article).  If the rule statement complies with this criterion and criterion 3 it will automatically comply with criterion 1 (provided that the terms, verb phrases, and prepositions in the fact model are correctly spelt).

  5. The rule statement must not include personal pronouns (such as 'you'[16])  or adverbs of time or place (such as 'here' or 'now').

  6. The subject of the rule statement must signify the object that is to be tested by the rule (see Making the wrong term the subject of the rule statement above).

  7. The rule statement must not be ambiguous (see Ambiguity in the previous article).

  8. The rule statement must not be self-contradictory (see Self-contradiction in the previous article).

  9. The rule statement should not include any redundant qualifying or conditional clauses (see Redundant qualifying and conditional clauses above).

  10. The rule statement must not duplicate any other rule statement (see Duplicate rule statements above).

  11. The rule statement must not overlap (imply or be implied by) any other rule statement (see Overlapping rule statements above).

  12. The rule statement must not contradict any other rule statement (see Contradictory rule statements above).

  13. The rule statement should not be one of a set of complementary rule statements which between them express a single rule (see Using multiple complementary rule statements to state a single rule above).

In addition, if you are using the constrained natural language described in these articles, each rule statement must comply with the following criteria:

  1. The rule statement must include one of the following:
    1. by definition
    2. must or
    3. may followed by only at some point in the statement.

  2. The rule statement must conform to the rule statement pattern appropriate to the type of rule.  This will ensure that criterion 14 is met.

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

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

[16]  The pronoun 'it' may be used in mandatory option selection rule statements (described in Part 3 in this series), and may be used with care anywhere in a rule statement where only one term precedes the location where the pronoun is to be used.  return to article

# # #

*/ ?>

Standard citation for this article:


citations icon
Graham Witt , "Writing Natural Language Rule Statements — a Systematic Approach Part 31: Even More Rule Statement Quality Criteria" Business Rules Journal Vol. 16, No. 3, (Mar. 2015)
URL: http://www.brcommunity.com/a2015/b804.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
 Ronald G. Ross
 Silvie  Spreeuwenberg

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.