Writing Natural Language Rule Statements — a Systematic Approach Part 14: Activity Rules — an Overview

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] which fall into three broad categories:

  1. data cardinality rules:  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), e.g., RS16
RS16. Each Travel Insurance Application must specify exactly one Departure Date.
  1. data content rules:  rules that place restrictions 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), e.g., RS61
RS61. The Return Date specified in each Travel Insurance Application must be later than the Departure Date specified in that Travel Insurance Application.
  1. data update rules:  rules that either prohibit update of a data item or place restrictions on the new value of a data item in terms of its existing value, e.g., RS131
RS131. The Status of a Loan Application
    may be updated to Approved
    only if the Status that is currently recorded for that Loan Application
        is Under Review.

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.

For the next few articles, we will be looking at rules that govern business processes and other activities.

What is a business process?

A business process (commonly referred to as just "a process") is an activity (or set of activities) that is managed by an organisation to produce some outcome of value to that organisation, its customers, its suppliers, and/or its partners.

A process may be performed by a system without human intervention, e.g., account housekeeping performed at the end of each financial period, or the automatic reordering of any stores item that falls below a reorder point.  Alternatively, a process may be performed by a human being without any automated system support, e.g., the delivery of goods by a driver from a supplier's warehouse to a customer's premises, a storeman's counting of stores items during stocktaking.  Many processes involve a collaboration between one or more human beings and one or more automated devices or systems, e.g.,

  1. withdrawal of money from a bank account using an ATM (Automatic Teller Machine — aka Cashpoint, Automatic Banking Machine) or over the counter

  2. paying a bill by credit card over the phone or using an Internet facility provided by your bank

  3. booking a flight on the Internet, over the phone, or over the counter.

The majority of these interactions require that one of the human beings involved uses a form displayed on a computer monitor (an on-screen form), but this is not essential.  For example:

  1. automated phone transactions can be performed by the customer using only the telephone keypad or his or her voice

  2. a security keypad only unlocks a normally-locked door if the correct combination is keyed in

  3. access control may alternatively be managed using a 'swipe card' reader

  4. on entering or leaving a train station in Sydney (Australia), passengers are required to insert a ticket into a slot beside a normally-closed barrier.

Each of the last three examples is governed by go/no-go rules:  the door or barrier is only opened if the information provided complies with the rules governing the access control device.

The last example also includes a decision rule.  If no further journeys can be made on the ticket (a single ticket can only be used for one journey, and a return ticket for two), the ticket is retained within the barrier, but in all other cases (for example, a weekly ticket can be used for unlimited journeys within a week) the ticket is returned to the passenger.

Characteristics of a process

All the examples above illustrate further characteristics of processes:

  1. All processes are recurrent, in that they may occur more than once and generally occur many times.  Each occurrence of a process should have a well-defined start point and a well-defined end point, i.e., it is possible for the participants to determine when each occurrence of a process has started and when it has finished.  For example, each withdrawal of money from an ATM starts with the insertion of a bank card into the ATM and ends with the removal of the card, the money, and the docket recording the process (if any).

  2. A process may contain sub-processes.  For example, the Book Flight Online process provided by an airline typically consists of the following steps:

    1. Search Available Seats:  the facility lists relevant flights that have available seats

    2. Select Flights and Fares:  the person using the facility selects the flight or flights and (where more than one fare class is available on a flight) the preferred fare class for each flight

    3. Review:  the facility lists the selected flights and fares for confirmation

    4. Identify Passengers:  the person using the facility lists the names and other information about each passenger flying

    5. Select Payment Option:  the person using the facility enters details of the credit card or other means of payment

    6. Confirm:  the person using the facility confirms the payment.

  3. A process may be performed in different ways.  For example, an airline may provide various means of booking a flight, such as online (via the airline's website or a travel agent's website), over the phone (direct to the airline), or via a travel agent (over the counter or over the phone).

  4. Each occurrence of a process is triggered by a certain type of event.  This may be:

    1. the arrival of a particular type of information, e.g.,

      1. a call to an automated telephone service

      2. a combination keyed into a security keypad

      3. a card presented to a 'swipe card' reader

      4. a ticket inserted into a slot at a train station barrier

      5. a bank card inserted into an ATM.

    2. a clock or calendar event, whereby a particular time of day and/or date eventuates, e.g., close of business each day, the end of the financial month or year, or some deadline such as 48 hours after making a booking.

How rules govern processes

Figure 1.  How rules govern processes.

Rules govern processes in various ways, as illustrated in Figure 1:

  1. A given process may only be permitted to occur if certain preconditions are met.  These may be any or all of the following:

    1. the completion of some other process, e.g., a passenger is only permitted to board an aircraft after that passenger has undergone security screening

    2. the completion of another occurrence of the same process, e.g., the airline employee checking boarding passengers will not start checking the documentation of a passenger until he or she has completed checking the documentation of the previous passenger

    3. the presence of all necessary information, e.g., a passenger is only permitted to board an aircraft if he or she presents a boarding pass and — in the case of an international flight — a passport

    4. the completeness and correctness of all information provided, e.g., the boarding pass presented by a passenger when boarding an aircraft must include the correct flight number and date, and the passport presented by that passenger must include a likeness of the passenger and an expiry date at least 6 months in the future, while, if both are presented, the names on both must be the same

    5. environmental conditions, such as a particular time period, place, or geographical area, e.g., a barrier at a train station needs to know whether it is in the geographical area covered by the ticket as well as the date and time.

  2. A process may make decisions at certain points during the set of actions that take place, e.g., whether to retain a ticket presented at a train station barrier.

  3. A process may perform one or more calculations, e.g., the premium to be paid for comprehensive insurance on a motor vehicle, based on the value of the vehicle, the location where it is garaged, and the driving and claims history of the nominated driver.

What rules govern processes?

The rules that govern processes can be categorised as follows:

  1. those that restrict the situations in which the process can occur, that is, prohibit that process in certain situations

  2. those that place an obligation on the process to occur in specific situations

  3. those that determine what action the process is to take in specific situations.

Of course, the capture and update of data are processes.  Data cardinality rules and data content rules prohibit the acceptance of data if it is incomplete or incorrect or if it includes spurious data.  Similarly, data update rules restrict the situations in which data can be updated.  There are however many other processes in addition to capturing and updating data.

Organisations also generally need to place restrictions on (or prohibit) activities other than processes, such as illegal or unsafe activities.  For example, rules may be required to restrict when and where an activity may occur, e.g., an airline passenger must not operate any electronic device after pushback from the gate until the seatbelt signs have been switched off, nor during descent and landing.  Other rules may be required to completely prohibit an activity, e.g., an employee must not engage in insider trading.

These are often overlooked by business rules projects, since they are rarely amenable to automation.  If the purpose of a business rules project is to catalogue only those rules that can be automated, such omission is justified, but if the project purpose is to catalogue all rules that govern an organisation or some functional area thereof, these rules should either be included or explicitly stated as being out of scope.

For this reason I call these rules activity rules rather than process rules.

Types of activity rule

Rules that restrict the situations in which a process or other activity can occur (activity restriction rules) include:

  1. those that limit a process or other activity to a particular time period, e.g., online check-in for a flight can only take place in the time period from 24 hours before the scheduled departure time of that flight until 30 minutes before departure of a domestic flight or 90 minutes before departure of an international flight

  2. those that prohibit a process or other activity during a particular time period, e.g., the cabin crew must not serve meals or refreshments:

    1. after pushback from the gate until the seatbelt signs have been switched off

    2. during descent and landing, or

    3. during turbulence

  3. those that prohibit a process from occurring unless some event or other process has previously occurred or some pre-requisite condition exists, e.g., a passenger may board a flight only if the aircraft is ready for boarding and that passenger:

    1. has checked in for that flight

    2. has undergone security screening, and

    3. presents a boarding pass that specifies the number and departure date of that flight;

in addition, a passenger may board an international flight only if that passenger:

    1. has undergone departure control

    2. presents a passport that specifies that passenger's name, bears a likeness of that passenger, and expires at least 6 months after the departure date of that flight.

Rules that place an obligation on a process or other activity to occur in specific situations (activity obligation rules) ideally require that activity to occur within a maximum time after a particular event (such as the completion of some other process), e.g.,

  1. a service level agreement may dictate that certain events must be responded to within a particular time period, for example, each incoming paper form must be processed within 1 business day of receipt of that form

  2. a reorder process must be performed before midnight on any day that the stock level of a spare part or consumable drops below the reorder point for that item

  3. weekly or monthly processing must be performed during the business day following the completion of the relevant week or month, respectively, whereas quarterly or end of financial year processing must be performed during the 5 business days following the completion of the relevant quarter or financial year, respectively

  4. a customer may be required to respond to an offer before a certain date to qualify for a particular product or discount.

Less satisfactory are those that merely require an activity to occur as soon as practical after a particular event:  the possibility of such rules cannot be entirely ruled out.

Process decision rules determine what action a process is to take in specific situations, e.g.,

  1. the process by which a passenger's ticket is validated as that passenger exits a train station may be programmed to capture a ticket on which no more journeys can be made, but return any other ticket

  2. the process by which motor vehicle insurance policy applications are handled may increase the premium (or reject the application) if provided with information about the vehicle, driver, or garaging location that increases the risk of a claim.

Types of activity restriction rule

Activity restriction rules are of various types:

  1. An activity time limit rule restricts a process or other activity to within a particular time period, e.g.,
RS172. Online check-in for a flight
may occur
    only during the 24 hours before the departure time of that flight.
RS173. Acknowledgment of an order
must occur
    during the 24 hours after the receipt of that order.
  1. An activity exclusion period rule prohibits a process or other activity during a particular time period, e.g.,
RS174. Online check-in for a flight
must not occur
    earlier than 24 hours before the departure time of that flight.[5]
RS175. An electronic device
must not be operated on an aircraft
at any time after pushback[6] of that aircraft
until a cabin crew member advises that
    electronic devices may be operated safely.
  1. An activity pre-condition rule prohibits a process or other activity unless some other activity or event has previously occurred or some pre-requisite condition exists, e.g.,
RS176. A passenger
may board a flight
only after that passenger checks in for that flight.
  1. An activity prohibition rule prohibits a process or other activity if some event or other process has previously occurred or some dangerous or illegal condition exists, e.g.,
RS177. A driver
must not operate any vehicle
if that driver is intoxicated.
  1. An activity conflict rule restricts the simultaneous occurrence of multiple processes or other activities, e.g.,
RS178. A folder
must not be renamed
while any file within that folder is open for editing.
  1. An information retention rule defines the minimum period for which a particular type of information is retained,[7] e.g.,
RS179. Information
    that is relevant to Australian income tax payment in a financial year
must not be deleted
    during the 7 years after the end of that financial year.

Examples of other activity rules

An activity obligation rule requires a process or other activity to occur either within a maximum time after a particular event (such as the completion of some other process) or when particular conditions apply, e.g.,

RS180. Each electronic device that is being used on an aircraft
must be switched off
no later than 1 minute after the start of the descent of that aircraft.

A process decision rule determines what action a process or device is to take in specific situations, e.g.,

RS181. Each ticket barrier
must retain each ticket that is not valid for any more journeys.

To be continued...
The next article in this series will discuss activity rules in more detail.

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]  Note that this rule statement is an alternative way of expressing the same rule as RS172.  return to article

[6]  'Pushback' is the reversal of an aircraft from the gate before taxying and takeoff.  return to article

[7]  It may not be obvious that this is an activity restriction rule, but it is a prohibition of any process that results in the deletion or destruction of the information in question.  return to article

# # #

Standard citation for this article:


citations icon
Graham Witt , "Writing Natural Language Rule Statements — a Systematic Approach Part 14: Activity Rules — an Overview" Business Rules Journal Vol. 14, No. 8, (Aug. 2013)
URL: http://www.brcommunity.com/a2013/b715.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.