Writing Natural Language Rule Statements — a Systematic Approach Part 18: Operative and Definitional Rules

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 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:
RS221. Each flight booking request for a return journey must specify the departure date.
  1. 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:
RS222. A flight booking request for a one-way journey must not specify a return date.
  1. 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:

RS223. Each flight booking request may specify a return date only if that flight booking request is for a return journey.

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

Rule Type Rule Statement Type Article(s)
Data rule
  • Data cardinality rule
    • Mandatory data rule
      • Mandatory data item rule

Obligation statement

Part 2, Part 7, Part 13

      • Mandatory option selection rule

Obligation statement

Part 2, Part 7, Part 13

      • Mandatory group rule

Obligation statement

Part 3, Part 7, Part 13

    • Prohibited data rule

Prohibition statement

Part 3, Part 7, Part 13

    • Maximum cardinality rule

Prohibition statement

Part 3, Part 7, Part 13

    • Multiple data rule

Obligation statement

Part 3, Part 7, Part 13

    • Dependent cardinality rule

Obligation statement

Part 3, Part 7, Part 13

  • Data content rule
    • Range rule

Obligation statement

Part 4, Part 7, Part 13

    • Value set rule

Obligation statement

Part 5, Part 7, Part 13

    • Uniqueness constraint

Obligation statement

Part 6, Part 7, Part 13

    • (In)equality rule

Obligation statement

Part 7, Part 8, Part 13

    • Data consistency rule

Obligation statement

Part 8, Part 13

    • Temporal data constraint

Obligation statement,
Prohibition statement

Part 9

    • Data item format rule

Obligation statement

Part 11, Part 13

    • Spatial data constraint

Obligation statement

Part 12

  • Data update rule
    • Data update prohibition rule

Prohibition statement

Part 12

    • Non-transferable relationship rule

Prohibition statement

Part 12

    • State transition constraint

Restricted permission
statement

Part 12

    • Monotonic transition constraint

Prohibition statement

Part 12

Activity rule
  • Activity restriction rule
    • Activity time limit rule

Obligation statement,
Restricted permission
statement

Part 14, Part 15, Part 16

    • Activity exclusion period rule

Prohibition statement

Part 14, Part 15, Part 16

    • Activity pre-condition rule

Restricted permission
statement

Part 14, Part 15, Part 16

    • Activity prohibition rule

Prohibition statement

Part 14, Part 15, Part 16

    • Activity conflict rule

Prohibition statement

Part 14, Part 15, Part 16

    • Information retention rule

Prohibition statement

Part 14, Part 15, Part 16

  • Activity obligation rule

Obligation statement

Part 14, Part 16

  • Process decision rule

Obligation statement

Part 14, Part 16

  • Object status rule

Obligation statement

Part 16

Party rule
  • Party restriction rule

Restricted permission
statement

Part 17

  • Role separation rule

Prohibition statement

Part 17

  • Role binding rule

Obligation statement

Part 17

  • Information access rule

Restricted permission
statement

Part 17

  • Responsibility rule

Obligation statement

Part 17

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.
  1. 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.

  2. 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".

  1. 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.

  2. 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:
RS224. It is necessary that each person has a birth date.[10]
RS225. Each person always has a birth date.
RS226. Each person has by definition exactly one birth date.
  1. 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:
RS227. It is impossible that the same person be born in more than one country.
RS228. The same person is never born in more than one country.
RS229. Each person is by definition born in no more than one country.
  1. 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.,
RS230. It is possible that a journey is a return journey only if the journey involves a return flight.
RS231. A journey can be a return journey only if the journey involves a return flight.
RS232. A return journey involves by definition at least one return flight.

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

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

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

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

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

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

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

# # #

Standard citation for this article:


citations icon
Graham Witt , "Writing Natural Language Rule Statements — a Systematic Approach Part 18: Operative and Definitional Rules" Business Rules Journal Vol. 15, No. 1, (Jan. 2014)
URL: http://www.brcommunity.com/a2014/b740.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.