Writing Natural Language Rule Statements — a Systematic Approach Part 16: More Activity 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 rule,[4] as well as activity rules,[5] in particular activity restriction rules.[6]  Each specific type of rule statement has a common formulation which we have discussed in both a relatively informal way and (except for activity restriction rules) by way of rule statement patterns.

In this article, we will be looking at the remaining types of activity rule:

  1. activity obligation rules, which require a process or other activity to occur either within some defined time period or when particular conditions apply

  2. process decision rules, which determine what action a business process or system component is to take in specific situations.

Activity obligation rules

These can place obligations on

  1. the organisation and its systems (as in RS193 – RS196).

  2. some other party, such as a customer or supplier (as in RS197 – RS199).
RS193. Each application
must be processed
within 1 business day of receipt of that application.
RS194. Acknowledgment of a service request
    that is made before 2pm
must occur
before 5pm on the day on which that service request is made.
RS195. A replenishment order
must be raised for a part
no later than 24 hours
after the quantity on hand of that part falls below
    the reorder point for that part.
RS196. Monthly processing of the transactions for a calendar month
must be performed
during the first business day after that calendar month.
RS197. Each payment
must be made
on or before the due date for that payment.
RS198. Each laptop computer
must be removed from any bag
before security screening.[7]
RS199. Each passenger
must wear his or her seatbelt
at all times while the seatbelt sign is illuminated.

Note that

  1. rule statements RS193 – RS197 each require that the process in question occurs within some defined time period.

  2. rule statement RS198 requires that the activity occur before some other activity can occur.

  3. rule statement RS199 requires that the activity occur when some particular condition applies.

  4. rule statement RS195 requires not only that the process occur when some particular condition applies but also that it occur within some defined time period.

Note also that there is a difference between

  1. an activity time limit rule (which does not require that the activity occur but restricts it if it does) and

  2. an activity obligation rule (which requires that the activity occur).

These rules have very similar statements; however, while activity time limit rule statements include may and only, activity obligation rules include must.  Compare rule statements RS200 and RS201.  While check-in is obligatory, online check-in is optional.[8]

RS200.

Check-in for a flight
must occur
    earlier than 30 minutes before the departure time of that flight.[9]

RS201. Online check-in for a flight
may occur
    only earlier than 4 hours before the departure time of that flight.

Since this difference in modal verbs (may and must) is often the only feature distinguishing these rule statements, they are often confused.  Indeed, in Part 14 I wrongly categorised rule statement RS173 (reproduced here) as an activity time limit rule; it is in fact an activity obligation rule.

RS173. Acknowledgment of an order
must occur
    during the 24 hours after the receipt of that order.

Object status rules

A type of rule that is very similar to an activity obligation rule (in that its rule statement has the same syntax) is an object status rule; this refers to the required status of an object (as in RS202) rather than the process by which that status is achieved (as in RS203).  As can be seen in these two rule statements, the same participle (in this case locked) can signify either the process or the resulting status.

RS202. Each door of the train
must be locked
while that train is in motion.
RS203. Each door of the train
must be locked
before that train moves.

While we're looking at doors of vehicles, two interesting rules relate to aircraft doors.  "Arming" of aircraft doors after pushback (reversal from the gate) but before take-off ensures that, if a door is opened after a crash or emergency landing, an escape slide automatically inflates.  On landing, of course, all doors must be disarmed.  I'll have more to say about these rules in a subsequent article.

RS204. Each door of the aircraft
must be armed
after pushback and
before take-off.
RS205. Each door of the aircraft
must be disarmed
after landing
before any door is opened.

Note the different styling of 'before' (in line with SBVR conventions):

  1. as a preposition (rendered as 'before') before a term (e.g., take-off) or literal (e.g., 5pm)

  2. as a conjunction (rendered as 'before') before a complete clause

Defining the activity governed by an activity obligation rule

As with activity restriction rule statements (discussed in the previous article in this series), each activity obligation rule statement needs to define the activity that is governed by the rule, by way of one of the following:

  1. the term signifying the object of the activity followed by a verb in the passive voice,[10] e.g.,

    1. Each application must be processed

    2. A replenishment order must be raised for a part

    3. Each payment must be made

    4. Each laptop computer must be removed from any bag

    5. Each door of a train must be locked

  2. a verbal noun,[11] usually followed by a phrase signifying the object of the activity, e.g.,

    1. Acknowledgment of a service request that is made before 2pm must occur

    2. Monthly processing of the transactions for a calendar month must be performed

    3. Check-in for a flight must occur

  3. (less commonly) the obliged party (such as customer) followed by a customer-perspective verb in the active voice,[12] e.g.,

    1. Each passenger must wear his or her seatbelt

Note that the term signifying the object of the activity may be followed by

  1. a prepositional phrase, such as of a train, for a calendar month.

  2. a qualifying clause, such as that is made before 2pm.

The term signifying the obliged party might also be followed by either of these (e.g., in economy class, that has a balance less than $1000).

The verb may also be followed by a prepositional phrase, such as for a part, from any bag.

Describing the circumstances in which the governed activity is obligatory

These circumstances may be described by any of the following:

  1. a temporal phrase, introduced by one or more temporal prepositions (and optionally preceded by at all times), e.g.,

    1. during the first business day after that calendar month

    2. before security screening

    3. before 5pm on the day on which that service request is made

    4. on or before the due date for that payment

    5. at all times while the seatbelt sign is illuminated

  2. a temporal phrase preceded by an expression signifying an interval, e.g.,

    1. earlier than 30 minutes
      before the departure time of that flight

    2. during the 24 hours
      after the receipt of that order

    3. within 1 business day
      of receipt of that application

  3. a clause (consisting of a subject, verb, and optional object) preceded by a temporal conjunction, e.g.,

    1. while that train is in motion

    2. before that train moves

  4. a temporal conjunction and clause preceded by an expression signifying an interval, e.g.,

    1. no later than 24 hours
      after the quantity on hand of that part falls below the reorder point for that part

  5. as a combination of two or more of any the above:

    1. simply concatenated, as in:
      after landing
      before any door is opened

    2. joined by and or or, as in:
      after pushback and
      before take-off

Process decision rules

A process decision rule determines what action a business process (as in RS206) or system component (as in RS207) is to take in a specific situation:

RS206. The processing of each order
must apply the preferred customer discount to the price of each item in that order
if the customer who raised that order is a preferred customer.
RS207. Each ticket barrier
must retain each ticket
    that is expired.

If a process decision rule governs a business process, the rule statement defines that process by any of the means that are available in other activity rule statements.  Rule statement RS206 uses the verbal noun processing.  If the rule governs a system component, the subject of the rule statement is the term signifying that component (ticket barrier in RS207).

The action to be taken is defined using a verb (apply, retain) followed by a term or terms signifying the object(s) of that verb (preferred customer discount, price in RS206, ticket in RS207).  Each such term may be followed by a qualifying clause (of each item in that order, that is expired).

A process decision rule often includes a conditional clause introduced by a conditional conjunction (if, unless).  Rule statement RS207 has the conditional clause the customer who raised that order is a preferred customer.  In fact, any rule statement can include a conditional clause.

Rule statement patterns for activity rules

In the following patterns, as previously discussed,

  1. <activity term> signifies

    1. the object of the activity,

    2. the activity itself by way of a verbal noun, or

    3. the party obliged to perform the activity or restricted in when they can perform the activity.

  2. <activity verb> is

    1. either undergo or the passive form of the verb signifying the activity, if <activity term> signifies the object of the activity,

    2. occur or be performed, if <activity term> is a verbal noun,

    3. the active form of the verb signifying the activity, if <activity term> signifies the obliged or restricted party.

  3. <time period definition> is any of the possibilities discussed under the heading "Describing the circumstances in which the governed activity is obligatory" above.
P37.  <activity time limit rule statement> ::=
{Each | The | A |} <activity term> {<qualifying clause> |}
may <activity verb> {<noun phrase> {<prepositional phrase> |}|}
only <time period definition>
{{if | unless} <conditional clause> |}.
P38.  <activity exclusion period rule statement> ::=
{The | A |} <activity term> {<qualifying clause> |} 
must not <activity verb> {<noun phrase> {<prepositional phrase> |}|}
<time period definition>
{{if | unless} <conditional clause> |}.
P39.  <activity pre-condition rule statement> ::=
{Each | The | A |} <activity term> <qualifying clause> |}
may <activity verb> {<noun phrase> {<prepositional phrase> |}|}
only {if | after} <conditional clause>
.
P40. 

<activity prohibition rule statement> ::=
{The | A |} <activity term> {<qualifying clause> |}
must not <activity verb> {<noun phrase> {<prepositional phrase> |}|}
{if | unless} <conditional clause>
.

P41.  <activity conflict rule statement> ::=
{The | A |} <activity term> {<qualifying clause> |}
must not <activity verb> {<noun phrase> {<prepositional phrase> |}|}
while <conditional clause>
.
P42.  <information retention rule statement> ::=
{The | A |} <activity term> {<qualifying clause> |}
must not be deleted
<time period definition>
{{if | unless} <conditional clause> |}.
P43.  {<activity obligation rule statement> | <object status rule statement>} ::=
{Each | The | A |} <activity term> {<qualifying clause> |}
must <activity verb> {<noun phrase> {<prepositional phrase> |}|}
{<time period definition> |}
{{if | unless} <conditional clause> |}.
P44.  <process decision rule statement> ::=
{Each | The | A |} {<activity term> | <system component term>}
{<qualifying clause> |}
must <activity verb> {<noun phrase> {<prepositional phrase> |}|}
{{if | unless} <conditional clause> |}.

Note that these patterns (and the others that have been described in previous articles in this series) involve various syntactic components that are yet to be defined in detail:

  1. <qualifying clause>, e.g.,

    1. for a flight, of an order, of the train, of the aircraft, of each order

    2. of a service request that is made before 2pm

    3. of the transactions for a calendar month

  2. <noun phrase>, e.g.,

    1. a part, any bag, his or her seatbelt, the preferred customer discount

    2. each ticket that is expired

  3. <prepositional phrase>, e.g., to the price of each item in that order

  4. <conditional clause>, e.g., the customer who raised that order is a preferred customer

All of these syntactic components will be defined in a future article in this series.

To be continued...
The next article in this series will look at party rules.[13]

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 restricts the situations in which the activity can occur, i.e. prohibit that activity in certain situations.  return to article

[7]  Note that this rule statement is an alternative way of expressing the same rule as RS189 and RS190 in Part 15.  return to article

[8]  Of course, it could be argued that check-in is optional, in that if one fails to check in, one doesn't fly!  However, any operative rule can be violated, often with the result that the process is aborted.  return to article

[9]  Note that this rule statement is an alternative way of expressing the same rule as RS185 in Part 15.  return to article

[10]  The use of a verb phrase such that the subject of that verb phrase is the person or thing on which the action is performed (the patient or target), as in "a boarding pass is presented by the passenger".  return to article

[11]  A noun formed from or otherwise corresponding to a verb phrase.   return to article

[12]  The use of a verb phrase such that the subject of that verb phrase is the person or thing performing the action signified by that verb phrase (i.e., the actor or agent), as in "the passenger presents a boarding pass".  return to article

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

*/ ?>

standard citation for this article:
Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 16:  Activity Rules — More Activity Rules," Business Rules Journal, Vol.  14, No.  10 (Oct. 2013), URL:  http://www.BRCommunity.com/a2013/b725.html  
*/ ?>

Standard citation for this article:


citations icon
Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach Part 16: More Activity Rules" Business Rules Journal, Vol. 14, No. 10, (Oct. 2013)
URL: http://www.brcommunity.com/a2013/b725.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
The BRSolutions Professional Training Suite

BRSolutions Professional Training Suite

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.