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 previous articles in this series (see the "Language Archives" sidebar) we have looked at standardised rule statements for various types of data rules^[4], activity rules,^[5] and party rules.^[6]  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 this article, I want to introduce a quite different type of rule, the definitional rule,^[7] but before that I would like to summarise the rules we have looked at so far.

Operative rules:  an overview

Each rule discussed in previous articles in this series has stated what must or must not happen in particular circumstances.  Each of those rules could be contravened:  someone filling out a request, application, order, etc. may omit the required information or supply information that is irrelevant or inappropriate; someone may perform an activity when inappropriate, or fail to perform a required activity; an unauthorised or unqualified person may perform an activity.  Such rules are referred to as operative, prescriptive, or normative rules.^[8]

The SBVR and RuleSpeak™ (which is described in an Annex to the SBVR) each propose three ways of stating an operative rule:

1. An obligation statement states an obligation — for example, an item of information must be present or have a valid value, a process must occur in a particular manner, or a person must perform a particular action.  For these I use (as does RuleSpeak) the word 'must' without an immediately following 'not', for example:

2. A prohibition statement states a prohibition, such as one that prohibits the presence of, or an invalid value of, an item of information, or the occurrence of, or a particular behaviour by, a process.  For these I use (again as does RuleSpeak) the words 'must not', for example:

3. A restricted permission statement allows a situation to exist only if a particular condition applies, for example:
   
   
1. An item of information may be present or absent, or may have particular values, only if a particular condition applies.
   
   
2. A process may occur or fail to occur, or may behave in a particular manner, only if a particular condition applies.

For these I use (again as does RuleSpeak) the word 'may' followed eventually by the word 'only' immediately before the clause expressing the condition, for example:

In this series we have looked at the following types of operative rule:

Definitions

The rule statement examples earlier in this article use between them a number of terms:  flight booking request, return journey, one-way journey, departure date, return date:  what do these terms mean?  In fact an organisation's rule book should not just consist of rule statements but should also include definitions of all terms used in rule statements.

Many organisations maintain business glossaries, the intention of which is to record all business terms along with meaningful unambiguous definitions.  However, those good intentions are in many cases not fulfilled:  some terms may be missing, while definitions are unfortunately often of poor quality.  The most common fault is the tautological attribute definition:  for example, defining the Start Date attribute of a Leave Application entity as "The Start Date of the Leave Application."

The definition of a business term may be:

1. intensional, in which the objects covered by the business term are defined as members of a more general class with one or more distinguishing characteristics, e.g., minor: a person whose age is less than the age of majority
   
   
2. extensional, in which the objects covered by the business term are listed, e.g., minor: a boy or a girl.

Definitions should meet the following quality criteria:

1. Rather than making up a definition, it should be sourced from:
   
   
   1. any specialised dictionary for the industry in which the organisation operates,
      
      
   2. any relevant legislation,
      
      
   3. any procedural documentation produced by the organisation,
      
      
   4. any existing business glossary,
      
      
   5. a general dictionary of the English language.
      
      
2. Each definition should be unambiguous.
   
   
3. No definition should be misleading, in the sense that any reader might infer either:
   
   
   1. inclusion of inappropriate instances in the set signified by the term (the definition is too general), or
      
      
   2. inappropriate exclusion of some instances from that set (the definition is too specific).

For example, if the term employee is used by a business to signify only its own current and former employees (rather than those of other businesses):

• the definition "a person who works for another party in return for financial compensation" is too general since it covers employees of other businesses.
  
  
• the definition "a person who currently works for ABC Enterprises P/L" is too specific since it excludes former employees.

4. Each definition must use natural language syntax, so that "A <term> is a <definition>" forms a true grammatical sentence.  For example, "a party who lends money under the terms of a mortgage" is appropriate as a definition of mortgagee since "A mortgagee is a party who lends money under the terms of a mortgage" is a true grammatical sentence.
   
   
5. Unless the term signifies a single instance, e.g., National Transportation Safety Board, there must be at least one indefinite article ('a' or 'an') in the definition.  The definite article ('the') may be only used in definitions:
   
   
   1. if the term signifies a single instance, or
      
      
   2. if there is also at least one indefinite article elsewhere in the definition.

Note that the initial article in a definition should only be 'the' if there is known to be only one instance of the object signified by the term in each instance of the described context.  Thus "the 6-character string that identifies a flight booking" is appropriate as a definition of booking reference number since there is only one booking reference number associated with each flight booking, but "the party who is lent money under the terms of a mortgage" is inappropriate as a definition of mortgagor since there may be more than one such party to a mortgage:  'a' should replace the initial 'the' in the definition so that it reads "a party who is lent money under the terms of a mortgage".

6. One dilemma that frequently arises in defining a set of business terms within an organisation is that many terms are given meanings that are more specific than the meanings of those terms in common usage.  If such a term is then used in the definition of another term (e.g., 'mortgage' in the definition of mortgagor above), is the specific meaning or the common usage meaning to be used in that definition?  One way to indicate whether the term is being used with its specific or common meaning is to use a different font, style, or some other marking.
   
   
7. Finally, no term signifying a real-world object should be defined in terms of any data item or information resource representing that real-world object.  For example, the term customer should not be defined as "a party recorded in the customer database" but instead be defined in terms of the events and/or relationships that characterise a customer in the real world.  However, it is quite appropriate to define the term customer database as "the database in which details of customers are recorded".

While a complete business glossary, in the sense of a set of (term, definition) pairs, is a valuable resource, there is a case for having rule statements and the definitions of the terms used in rule statements in a single consistent resource.  This can be simply achieved through definitional rule statements, many of which can take the form "A <term> is by definition <definition>."  Note that this syntax differs from those proposed in the SBVR, for reasons that I discuss later in this article.

Definitional rules:  an overview

There are, in fact, many uses for definitional rules, which I shall discuss in more detail in the next article.  In contrast to operative rules, definitional rules (also known as structural or descriptive rules) define constructs created or used by the organisation (or the industry within which it operates), or define properties of such constructs.  These include:

1. terms chosen to signify specific concepts of interest (such as 'loan application', 'probationary employee', 'high value customer', 'close of business', or 'financial year')
   
   
2. categorisation schemes, based on physical properties (such as 'gender') or abstract properties (such as 'credit rating' or 'marital status'), each with a set of categories
   
   
3. measurement units to be used with quantities of particular types, e.g., miles (or kilometres) for distance, pH for acidity or alkalinity, along with:
   
   
1. conversion factors between different units (e.g., 1 mile is approximately 1.6 kilometres)
   
   
2. valid value ranges of measurements (e.g., the pH measure of acidity or alkalinity ranges from 0 to 14 inclusive^[9])
   
   
4. standard calculations:  for example, the standard means of calculating a business's 'total year-to-date sales' may be the total value (nett of all included taxes and delivery charges) of all orders raised since January 1st in the current year
   
   
5. standard formats for representing information, e.g., whether, say, Christmas day 2013 is to be represented as '25/12/2013' (as in the UK or Australia), '12/25/2013' (as in the US), or '25 December 2013' (to avoid any confusion)
   
   
6. complex concepts (with internal structure), such as:
   
   
1. a 'flight', which by definition has one origin port, one destination port, one departure time, and one arrival time
   
   
2. a 'return journey', which by definition has one or more passengers traveling on one or more outgoing and one or more return flights (the same passengers on each flight) in which:
   
   
1. the origin port of the first or only return flight is the same as the destination port of the last or only outgoing flight, and
   
   
2. the origin port of the first or only outgoing flight is the same as the destination port of the last or only return flight.

Definitional rule statement syntax

SBVR Structured English and RuleSpeak each propose three types of definitional rule statements:

1. A necessity statement states something that is necessarily the case, e.g., that a person have a birth date.  The formulation in SBVR Structured English starts with the clause 'it is necessary that', whereas in RuleSpeak each necessity statement includes the word 'always', for example:

2. An impossibility statement states that something is impossible, e.g., that a person be born in more than one country.  The formulation in SBVR Structured English starts with the clause 'it is impossible that', whereas in RuleSpeak each impossibility statement includes the word 'never', for example:

3. A restricted possibility statement expresses a situation that is possible only if a particular condition applies.  The formulation in SBVR Structured English starts with the clause 'it is possible that', whereas in RuleSpeak each restricted possibility statement includes 'can' followed eventually by the word 'only' immediately before the clause expressing the condition, e.g.,

I prefer not to use the SBVR Structured English or RuleSpeak formulations, for the following reasons:

1. The difference between 'necessary' and 'obligatory' (the alternative word used in SBVR Structured English operative rule statements) is rather too subtle for common use:  I have frequently encountered even well-educated business people use 'necessary' when they mean 'obligatory', e.g., "It is necessary for applications for leave to be submitted on the appropriate form."
   
   
2. The use of 'always' or 'never' in a rule statement suggests that the rule stated is time-independent rather than time-dependent.  For example, the 'always' in rule statement RS225 suggests that there may be attributes of a person that they have only for a certain period of time (as indeed there are, e.g., marriage date, retirement date).

For these reasons, I do not recommend these formulations for practical business use, and have opted for the phrase 'by definition' to distinguish definitional rule statements from operative rule statements.  Note that, by doing so, I fail to distinguish between necessity statements, impossibility statements, and restricted possibility statements.  This is a conscious decision as I have found that distinction to have little practical benefit, unlike the distinction between the 3 major classes of operative rule statement.

To be continued...
The next article in this series will review the various types of definitional rule statements and corresponding patterns.

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 constrains the data included in a transaction (a form or message) or a persistent data set (e.g., a database record).  

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

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

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

[8]  A rule that states what must or must not happen in particular circumstances, and which can therefore be contravened.  

[9]  Note that, while acidity/alkalinity is indeed a physical phenomenon, the use of pH to measure it is a construct of the scientific community.  

[10]  Any rule statement that is marked with an initial dagger is, for one or more reasons, not recommended; in this case a preferred alternative will also be shown.  

# # #