Writing Natural Language Rule Statements — a Systematic Approach Part 29: Some 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.

In previous articles[9] we looked at the syntactic components that may be found in rule statements of all types, namely prepositional phrases,[10] qualifying clauses,[11] terms,[12] and determiners,[13] verbs,[14] and conditional clauses.[15]  In this article we will look at some of the quality criteria that govern rule statements.

Fundamental criteria

Any natural language rule statement must meet a number of criteria, including (but not limited to) the following:

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

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

Given the flexibility of any natural language, this gives plenty of scope for expressing the same rule in many different ways, some better than others (and some quite inappropriate).  We therefore need additional quality criteria, which I shall discuss in this article and the next.

Constraining rule statement wording

Any organisation is governed by many rules.  If the various rules of a given type are expressed in different ways, the following are each much more difficult and error-prone:

  • establishing whether any two rule statements duplicate each other or (worse) conflict with each other

  • translating (automatically or manually) natural language rule statements into statements in the appropriate programming language, database constraint language, and/or rule engine input language.

For example, each of the following statements is an alternative wording of the same rule:

RS172. †The Departure Date must be specified in a Travel Insurance Application.[16]
RS173. †It is obligatory that the Departure Date be specified in a Travel Insurance Application.
RS174. †It is obligatory that a Travel Insurance Application specify the Departure Date.
RS175. †A Travel Insurance Application is obliged to specify the Departure Date.
RS176. †A Travel Insurance Application must specify the Departure Date.
RS177. †Each Travel Insurance Application must specify the Departure Date.
RS178. †A Travel Insurance Application must specify exactly one Departure Date.
RS16. Each Travel Insurance Application must specify exactly one Departure Date.

The constrained natural language described in these articles prescribes a particular pattern for statements of rules governing mandatory data items, namely the pattern exemplified by RS16.  The reasons for choosing this particular pattern are set out in the first article in this series.[17]

If alternative terms or verbs are allowed, we can still express this one rule differently, e.g.,

RS316. Each Application for Travel Insurance must specify exactly one Departure Date.
RS317. Each Travel Insurance Application must specify exactly one Date of Departure.
RS318. Each Travel Insurance Application must state exactly one Departure Date.

To make detection of duplicate or conflicting rule statements (and translation of rule statements) easier, each rule should only be expressed in one way.  To ensure this:

  1. There should be a single pattern for each type of rule, as documented in earlier articles in this series.

  2. Preferred terms (e.g., Travel Insurance Application, Departure Date) and verbs (e.g., specify) must be agreed on and documented, as well as the prepositions (e.g., for) used with some verbs.

  3. Each rule statement must use only those preferred terms, verbs, and prepositions.

Constraining rule statement vocabulary

The best way to document agreed terms, verbs, and prepositions is by way of a fact model, which is a collection of:

  1. agreed preferred terms, each with an agreed definition

  2. fact types specifying the agreed verbs (and prepositions if required) to be used with terms in rule statements.

For example, if the terms and verb used in RS16 are agreed as the preferred words, fact type FT1 documents this.

FT1.  Travel Insurance Application specifies Departure Date

FT1 is a binary fact type since it connects two terms.  Some binary fact types have a reverse form; the reverse form of FT1 is Departure Date is specified in Travel Insurance Application.  In its reverse form the same fact type clearly supports RS61.

RS61. The Return Date specified in each Travel Insurance Application must be later than the Departure Date specified in that Travel Insurance Application.

Some more fact types are required to support RS61; FT2 is analogous to FT1.

FT2.  Travel Insurance Application specifies Return Date

It might be tempting to also include fact type FT3.

FT3.  Return Date is later than Departure Date

This is a legitimate approach, but there is an alternative, which I shall discuss shortly.  Let us first look at another rule statement.

RS58. The Departure Date specified in each Travel Insurance Application must be later than the Date on which that Travel Insurance Application is made.

This rule statement is supported by FT1, FT4, and FT5 (for which there is no reverse form).

FT4.  Departure Date is later than Date
FT5.  Travel Insurance Application is made on Date

Alternatively, FT3 and FT4 can be recognised as being specific instances of a more general fact type, FT6.  FT6 can replace FT3 and FT4 if FT7 and FT8 are also included.

FT6.  Date is later than Date
FT7.  Return Date is a category of Date
FT8.  Departure Date is a category of Date

Another way of looking at these fact types is that FT3 can be derived from FT6 by substituting:

  1. Return Date in place of the first Date in FT6 (allowed because of FT7) and

  2. Departure Date in place of the second Date in FT6 (allowed because of FT8).

Similarly, FT4 can be derived from FT6 by substituting Departure Date in place of the first Date in FT6.

Here are some more rule statements and the fact types that support them.

RS15. Each Travel Insurance Application must specify exactly one Birth Date for each Passenger.
FT9.  Travel Insurance Application specifies Birth Date for Passenger
    (this is a ternary fact type)
RS25. Each Travel Insurance Application that is for international travel must specify at least one Region.
FT10.  Travel Insurance Application is for international travel
    (this is a unary fact type)
FT11.  Travel Insurance Application specifies Region
RS43. Each Travel Insurance Application must specify a Return Date or a Travel Duration but not both.
FT12.  Travel Insurance Application specifies Travel Duration
    (as well as FT2)
RS55. The number of Passenger Names specified in each Flight Booking Confirmation
must be equal to the Number of Passengers
     specified in the Flight Booking Request
     that gives rise to that Flight Booking Confirmation.
FT13.  Flight Booking Confirmation specifies Passenger Name
    (reverse form Passenger Name is specified in Flight Booking Confirmation)
FT14.  Flight Booking Request specifies Number of Passengers
    (reverse form Number of Passengers is specified in Flight Booking Request)
FT15.  Flight Booking Request gives rise to Flight Booking Confirmation
RS57. The Value specified for each High Value Item (if any) in each Travel Insurance Application must be more than $500.
FT16.  Travel Insurance Application specifies Value for High Value Item
    (reverse form Value is specified for High Value Item in Travel Insurance Application)
FT17.  Monetary Amount is more than Monetary Amount
FT18.  Value is a category of Monetary Amount
RS73. The Salutation specified for each Passenger in each Travel Insurance Application must be one of the Name Titles listed in AS4590-2006.
FT19.  Travel Insurance Application specifies Salutation for Passenger
    (reverse form Salutation is specified for Passenger in Travel Insurance Application)
FT20.  Salutation is Name Title
FT21.  Standard lists Name Title
    (reverse form Name Title is listed in Standard)
FT22.  AS4590-2006 is an instance of Standard
RS80. Each Region (if any)
     specified in each Travel Insurance Application
must be different to any other Region
     specified in that Travel Insurance Application.
FT23.  Travel Insurance Application specifies Region
    (reverse form Region is specified in Travel Insurance Application)
FT24.  Region is different to Region
RS85. The Passenger Name specified on each Boarding Pass presented by a Passenger must be the same as the Name specified on the Passport presented by that Passenger.
FT25.  Passenger Name is specified on Boarding Pass
FT26.  Boarding Pass is presented by Passenger
FT27.  Passenger Name is the same as Name
FT28.  Name is specified on Passport
FT29.  Passport is presented by Passenger
RS94. The Effective Time Period
     specified in each Insurance Product Version
must not overlap the Effective Time Period
     specified in any other Insurance Product Version
     for the same Insurance Product.
FT30.  Effective Time Period is specified in Insurance Product Version
FT31.  Effective Time Period overlaps Effective Time Period
FT32.  Insurance Product Version is for Insurance Product
RS101. Each Region (if any) specified in each Travel Insurance Application
must be one of the Regions recognised by Australian Travel Insurance P/L
     as at the Date on which that Travel Insurance Application is made.
FT33.  Region is Region
    (a specific instance of the general fact type Object is Object)
FT34.  Region is recognised by Organisation as at Date
    (as well as FT5, FT22)
FT35.  Australian Travel Insurance P/L is an instance of Organisation
RS178. A Folder
must not be renamed
while any File within that Folder is open for editing.
FT36.  Folder is renamed
FT37.  File is within Folder
FT38.  Folder is open for editing

In the previous article, we saw that some verbs state or question the truth of a proposition.  The verb specify can be used in this manner as in RS22.  In this situation the term Proposition is used as the object of the verb (as in FT39).  This term can then stand for other fact types, such as FT40 – FT42.

RS22. Each Flight Booking Request must specify whether it is for a one-way journey, for a return journey or for a multi-stop journey.
FT39.  Flight Booking Request specifies Proposition
FT40.  Flight Booking Request is for a one-way journey
FT41.  Flight Booking Request is for a return journey
FT42.  Flight Booking Request is for a multi-stop journey

To be continued...
In the remaining articles in this series I will look at the other 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]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 26:  Some Common Syntactic Components of Rule Statements," Business Rules Journal, Vol. 15, No. 9 (Sep. 2014), URL:  http://www.BRCommunity.com/a2014/b777.html,
Graham Witt, "Writing Natural Language Rule Statements —a Systematic Approach —Part 27:  Terms and Determiners," Business Rules Journal, Vol. 15, No. 11 (Nov. 2014), URL:  http://www.BRCommunity.com/a2014/b785.html, and
Graham Witt, "Writing Natural Language Rule Statements —a Systematic Approach —Part 28:  Verbs and Conditional Clauses," Business Rules Journal, Vol. 15, No. 12 (Dec. 2014), URL:  http://www.BRCommunity.com/a2014/b790.html  return to article

[10]  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

[11]  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

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

[13]  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

[14]  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

[15]  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

[16]  Each rule statement example that does not comply with the constrained natural language described in this series of articles is marked with an initial dagger.  return to article

[17]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 1:  Basic Principles," Business Rules Journal, Vol. 13, No. 7 (July 2012), URL:  http://www.BRCommunity.com/a2012/b660.html  return to article

# # #

Standard citation for this article:


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

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.