Writing Natural Language Rule Statements — a Systematic Approach Part 14: Activity Rules — an Overview
About this series of articles
While my first series of articles on writing natural language rule statements 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. 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.
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, which fall into three broad categories:
- 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.|
- 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.|
- 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.,
- withdrawal of money from a bank account using an ATM (Automatic Teller Machine — aka Cashpoint, Automatic Banking Machine) or over the counter
- paying a bill by credit card over the phone or using an Internet facility provided by your bank
- 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:
- automated phone transactions can be performed by the customer using only the telephone keypad or his or her voice
- a security keypad only unlocks a normally-locked door if the correct combination is keyed in
- access control may alternatively be managed using a 'swipe card' reader
- 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:
- 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).
- A process may contain sub-processes. For example, the Book Flight Online process provided by an airline typically consists of the following steps:
- Search Available Seats: the facility lists relevant flights that have available seats
- 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
- Review: the facility lists the selected flights and fares for confirmation
- Identify Passengers: the person using the facility lists the names and other information about each passenger flying
- Select Payment Option: the person using the facility enters details of the credit card or other means of payment
- Confirm: the person using the facility confirms the payment.
- 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).
- Each occurrence of a process is triggered by a certain type of event. This may be:
- the arrival of a particular type of information, e.g.,
- a call to an automated telephone service
- a combination keyed into a security keypad
- a card presented to a 'swipe card' reader
- a ticket inserted into a slot at a train station barrier
- a bank card inserted into an ATM.
- 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:
- A given process may only be permitted to occur if certain preconditions are met. These may be any or all of the following:
- the completion of some other process, e.g., a passenger is only permitted to board an aircraft after that passenger has undergone security screening
- 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
- 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
- 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
- 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.
- 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.
- 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:
- those that restrict the situations in which the process can occur, that is, prohibit that process in certain situations
- those that place an obligation on the process to occur in specific situations
- 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:
- 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
- those that prohibit a process or other activity during a particular time period, e.g., the cabin crew must not serve meals or refreshments:
- after pushback from the gate until the seatbelt signs have been switched off
- during descent and landing, or
- during turbulence
- 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:
- has checked in for that flight
- has undergone security screening, and
- 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:
- has undergone departure control
- 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.,
- 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
- 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
- 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
- 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.,
- 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
- 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:
- 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
only during the 24 hours before the departure time of that flight.
|RS173.||Acknowledgment of an order
during the 24 hours after the receipt of that order.
- 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.
|RS175.||An electronic device
must not be operated on an aircraft
at any time after pushback of that aircraft
until a cabin crew member advises that
electronic devices may be operated safely.
- 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.,
may board a flight
only after that passenger checks in for that flight.
- 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.,
must not operate any vehicle
if that driver is intoxicated.
- An activity conflict rule restricts the simultaneous occurrence of multiple processes or other activities, e.g.,
must not be renamed
while any file within that folder is open for editing.
- An information retention rule defines the minimum period for which a particular type of information is retained, e.g.,
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.
 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
 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.
# # #