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 a variety of data cardinality rule statements,^[4] as well as the following data content rule statements:^[5]  range rule statements,^[6] value set rule statements,^[7] uniqueness constraint statements,^[8] (in)equality rule statements,^[9] data consistency rule statements,^[10] and temporal data constraint statements.^[11] Each 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.

While temporal data constraints constrain temporal data items (dates or times), the time dimension can affect other data rules, so we need to discuss the implications before moving on.

Errata

In parts 7 and 8 of this series, an error crept into the rule statement patterns for equality and inequality rule statements.  The pattern for equality rule statements alone in part 7 should have been:

Similarly the combined pattern for equality and inequality rule statements in part 8 should have been:

The effect of the time dimension on data rules

When authoring a rule statement it may be necessary to take the time dimension into account.  For example:

1. If a constrained data item is time-variant (it can vary over time) it may be necessary to establish which of its values are subject to the constraint.  In particular, there are many rules that refer to a person's age:  a product (such as insurance) may be limited to persons under some maximum age, whereas public transport tickets are often cheaper for young persons or seniors.  If the product is being purchased in advance, which is relevant:  the age of the person at the time of purchase or their age at the time covered by the insurance or ticket?
   
   
2. A rule may vary over time, e.g., the upper limit imposed by a range rule may change.
   
   
3. Different rules may apply to a transaction (such as a loan application) or arrangement (such as an account) at different stages in the lifecycle of that transaction or arrangement.
   
   
4. If the cardinality of a relationship is "exactly one" or "at most one", does that relationship allow only one for all time (e.g., an order line cannot be transferred from one order to another) or one at a time (e.g., an order line can be updated to refer to a different product but can only refer to one product at a time)?

Time-variant and non-time-variant data items

Most of the rules that we have encountered so far in this series govern data specified in transactions, such as Travel Insurance Applications, Flight Booking Requests, Flight Booking Confirmations, Policy Type Creation Forms, Reward Flight Bookings, or Real Property Transfer Instruments.  Typically such transactions are initiated on user interfaces or web forms, but may be transferred from system to system by way of electronic messages.  Some may even start life on paper forms, but even these will be captured by a system via user interfaces or web forms.  A common feature of transactions is that, although a user may modify the content prior to final submission, the transaction is essentially invariant once submitted.  If update after submission is permitted, this can only be achieved by storing the transaction as persistent data that is then retrieved for update. Note, however, that a transaction can include a reference to a time-variant data item such as a person's age.

Other rules in this series govern persistent data, such as records of Parties Covered, Land Titles, Insurance Products, Insurance Product Versions, or Insurance Product Base Premium Versions.  Most persistent data can vary over time as a result of update.

Finally, a few of the rules in this series have specified required conditions in the physical world, such as comparisons between Landing Distances Required of Aircraft and Lengths of Runways on which those aircraft might land.  Such properties of physical objects may also vary over time:  aircraft may be upgraded, and runways may be extended.

Rules governing time-variant data items:  ages and birth dates

A person's age is obviously time-variant, which is why it may be better for an organisation that is interested in a customer's or employee's age to capture that person's birth date rather than their age at some point.  For example, an insurance company may limit travel insurance cover to passengers below some maximum age; if it does, it must be clear about when that maximum age applies.  Will the policy cover a passenger who is below the maximum age on the day that insurance is taken out but who reaches the maximum age during the period of travel?

Compare rule statement RS99 with two other rule statements (in a previous article^[12]) that were intended to state the same business rule:

Note that RS56 is a less prescriptive form of RS99 in that it lacks the qualifying clause that states the requirement that each passenger still be less than 80 years old on the final day of travel.  By contrast, RS63 (which governs the non-time-variant data item Birth Date) does not have to include any qualification.  Interestingly, most travel insurance websites request passenger ages (rather than birth dates); however, since none that I have so far encountered includes any qualification as to whether you should enter passenger ages at the time of application or at the time of travel, a 79-year-old passenger can be covered even though they turn 80 before travelling.

This suggests that, rather than simply requesting passenger ages, such websites should explicitly request the ages of all passengers as at the return date.^[13]  This in turn suggests an alternative rule statement formulation:

Time-variant rules

Rules themselves may also change over time.  Consider rule statement RS67 (reproduced from a previous article):  what if the company decides to change the set of regions (for example, add Middle East or split Europe into Western Europe and Eastern Europe)?

Of course, we could simply change the rule, either immediately (if appropriate) or on the day on which the change is to come into effect.  An alternative is to make the rule parametric, i.e., rather than stating the regions as literals (as in rule statement RS67), use a suitably-qualified term (as in rule statement RS69 — also reproduced from a previous article).

This raises an interesting issue.  Imagine that on 1 May 2013 the company decides that the set of regions is to be changed on 30 June 2013, and on 2 May 2013 an application for travel insurance is received for a journey to take place after 30 June 2013.  Must the regions specified in that travel insurance application belong to the set in force on 2 May 2013 (as specified in RS101) or the set in force after 30 June 2013 (as specified in RS102)?

Rule variance across the lifecycle of a governed transaction or arrangement

Different rules may apply to a transaction (such as a loan application) or arrangement (such as an account) at different stages in the lifecycle of that transaction or arrangement.

For example, the balance of an account may be required to be greater than some minimum value at all times during the life of that account.  If a rule applies at all times, the phrase 'at all times' in the rule statement makes this explicit, e.g.,

While 'always' is a more succinct alternative to 'at all times', I advise against it as it is used with a specific, different meaning in RuleSpeak^®.^[14]

If the constraint applies only at a particular time point or during a particular time period, that time point or period should be identified in the rule statement, e.g.,

Some data entry facilities provide users with the ability to save incomplete transactions for eventual completion and submission:  this also requires different rules for the "save incomplete transaction" and "submit complete transaction" processes.  For example, most employee time recording systems allow an employee to save a partial record of a week's work (while awaiting a project code, for example) but require the record to be complete when it is finally submitted.  What we have here is actually two different processes, each subject to different rules.  For example, a submitted timesheet is subject to rule statements RS105 and RS106, but an incomplete saved timesheet is not.

These are actually process rules rather than data rules, to be discussed in a later article in this series.

The enforcement level concept provides for an alternative approach to this situation.  Rules can be specified that apply to all transactions (in this case, timesheets), but these rules are strictly enforced only when a timesheet is submitted, and less rigorously enforced (e.g., with a warning message) if a timesheet is only being saved.

The impact on rule statement patterns

To allow for temporal qualifying clauses to be included in range rule statements (as in RS99, RS103, and RS104) and value set rule statements (as in RS101 and RS102), the rule statement patterns for these types of rule statement need to be enhanced:

Equality and inequality rules may also occasionally require such qualifications, so we similarly enhance their rule statement pattern:

Other data content rule statements (for uniqueness constraints, data consistency rules, or temporal data constraints) are unlikely to require qualification in this way.

Data updatability

In the foregoing discussion I have referred to time-variant and non-time-variant data items.  Rules may be required to govern whether or not particular data items are allowed to vary over time.  For example, there is a difference between relationships that allow only one for all time (e.g., an order line cannot be transferred from one order to another) and those that allow only one at a time (e.g., an order line can be updated to refer to a different product but can only refer to one product at a time).  We shall discuss these in a subsequent article.

To be continued...
The next article in this series will discuss data format 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  

[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]  Statements of rules that require the presence or absence of a data item and/or place a restriction on the maximum or minimum number of occurrences of a data item.  

[5]  A statement of a rule that places a restriction on the values contained in a data item or set of data items (rather than whether or not they must be present and how many there may or must be).  

[6]  A statement of a rule that requires that the content of a data item be a value within a particular range.  

[7]  A statement of a rule that requires that the content of a data item be (or not be) one of a particular set of values (either a fixed set or a set that may change over time), or that the content of a combination of data items match or not match a corresponding combination in a set of records.  

[8]  A statement of any of the following:

1. an integrity constraint by which a DBMS ensures that a particular column (or combination of columns) in a table has different values in every row,
   
   
2. in ORM (Object Role Modelling), a constraint in which each instance of a particular object type may participate in no more than one instance of a particular fact type,
   
   
3. a rule that requires that the content of a data item (or combination of data items) be different to that of the corresponding data item(s) in the same or other records or transactions.  

[9]  A statement of a rule that requires that the content of a data item be the same (or different to) as that of some other data item (or some specific value).  

[10]  A statement of a rule that requires the content of multiple data items to be consistent with each other, other than as provided for by a value set rule, range rule, or equality rule.  

[11]  A statement of a rule that constrains one or more temporal data items (dates or times).  

[12]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach: Part 4 — Some Data Content Rules," Business Rules Journal, Vol. 13, No. 10 (October 2012), URL: http://www.BRCommunity.com/a2012/b674.html  

[13]  The wording "as at" is used rather than "on" or "at" to make clear that it qualifies "ages of all passengers" rather than "request".  The alternative wordings "request the ages of all passengers at the return date" or "request the ages of all passengers on the return date" could be interpreted as meaning that the request is made on the return date.  The wording "as on" would be an acceptable alternative.  

[14]  Ronald Ross & Gladys Lam, RuleSpeak Sentence Templates — Developing Rule Statements Using Sentence Patterns.  (2001).  

# # #