Writing Natural Language Rule Statements — a Systematic Approach Part 29: Some Rule Statement Quality Criteria
About this series of articles
While my first series of articles on writing natural language rule statements 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. 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.
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 (data rules, activity rules, and party rules) and definitional rules. 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 we looked at the syntactic components that may be found in rule statements of all types, namely prepositional phrases, qualifying clauses, terms, and determiners, verbs, and conditional clauses. In this article we will look at some of the quality criteria that govern rule statements.
Any natural language rule statement must meet a number of criteria, including (but not limited to) the following:
- 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.
- 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.|
|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.
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:
- There should be a single pattern for each type of rule, as documented in earlier articles in this series.
- 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.
- 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:
- agreed preferred terms, each with an agreed definition
- 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:
- Return Date in place of the first Date in FT6 (allowed because of FT7) and
- 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
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.
 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
 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.
 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.
 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
 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.
 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.").
 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).
 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
# # #
About our Contributor:
All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.