Business rules at their best are clear, concise, readable statements in everyday business English, but we all know that writing them that way requires quite a lot of experience and training.  Many tips and tricks exist to guide the business rule author in this arduous task.

One such tip that often recurs in some form or other^[1] [2] is that a good business rule should have the right subject or focus.  Graham Witt contrasts:^[3]

Each bag that weighs more than 20kg must be labelled with a 'heavy bag' label.	1.1
A 'heavy bag' label must be affixed to a bag that weighs more than 20kg.	1.2

He argues that only 1.1 is correct because 1.2 has the wrong focus or subject.  The subject is heavy bags and not heavy bag stickers:  you need a rule that tells you what to do when you have a heavy bag (1.1), not a rule that tells you what to do when you have a 'heavy bag' sticker (1.2).

This seems a convincing point, but should you worry about subject focus with each sentence you write?  Or, to put it more positively, could it be a leading light?  The answer is:  not really, and not most of the time.  There are even a few pitfalls if you concentrate on subject focus too much.  Let's put some examples to the test.

A good start is the example just given.  Looking at it more closely, people are not actually very likely to say 1.2.  Its use of two indefinite articles ("a") makes the sentence sound vague.  People who are used to striving for maximum clarity in administrative language are much more likely to say:

A 'heavy bag' label must be affixed to each bag that weighs more than 20kg.

1.2.1

The word each pulls this rule almost completely into the 1.1 camp; it causes the focus to shift from the labels to the bags.  While 1.1 is still no doubt better, 1.2.1 manages to state the same rule as 1.1, unequivocally and in correct English.  This is a first indication that subject focus involves more than just wondering "which bit to put on the left."

Before leaving this interesting example, let's briefly point out that rules about stickers are not as strange as they sound.  A motivation for rule 1.2.2 could be that stickers are actually expensive or in short supply:

A 'heavy bag' label may only be affixed to a bag that weighs more than 20kg.

1.2.2

1.2.2 is a completely different rule from 1.1.  You may need one, or the other, or both.

Here is a familiar "startdate – enddate" constraint:

The return date specified in a flight booking request must be later than the departure date specified in that flight booking request.	2.1
The departure date specified in a flight booking request must be earlier than the return date specified in that flight booking request.	2.2

In this example, the business rule is about the relationship between two dates.  Compliance with the rule does NOT depend on which of the two dates has focus.  To be sure, focus is not unimportant.  Compared with formats such as decision tables and decision trees, a peculiarity of natural-language text format is that it forces a writer always to choose one term that is mentioned first, simply because text runs from left to right.  Which of the two dates should have focus depends on circumstantial factors.  For example, in an online form:

• 2.1 is better as an error message in an online form at the moment when the user finishes typing the return date and that date is found to violate the rule.
  
  
• 2.2 is the better error message if the user has just decided (for some reason) to change the departure date, and that date is found to violate the rule.

2.1 is probably the more natural choice in many settings, since the departure date is more likely to be available for comparison with the return date than the other way around.  Be that as it may, 2.1 and 2.2 have the same meaning even though subject focus is different.

A similar but more intriguing example is:

A passenger may board a flight only after that passenger checks in for that flight.	3.1
A passenger must check in for a flight before that passenger boards that flight.	3.2

The rules don't say it, but we all know that, in airports, the opportunity to check in will always be given before the opportunity to board.  Therefore it will always be at the boarding gate and not at the check-in desk that this rule is tested.  3.1 has the advantage of taking the perspective of this test moment.  3.2 has exactly the same meaning and is completely acceptable, but because of this advantage we might as well choose 3.1.

And yet, as soon as the situation becomes less obvious, the idea that the focus of a rule should be dictated by the focus of a person testing the rule has serious drawbacks.  Consider these two entirely different styles of expressing rules that govern admittance of passengers on flights at the gate:

Style 4.1:

A passenger may board an international flight only if that passenger presents:     • a boarding pass that specifies that flight, and:     • a passport that         — bears likeness to that passenger         — specifies an expiry date that is later than 6 months after the departure time of that flight.	4.1.1
A passenger may board a domestic flight only if that passenger presents a boarding pass that specifies that flight.	4.1.2

Style 4.2:

A passenger may board a flight only if that passenger presents a boarding pass that specifies that flight.	4.2.1
A passenger may board an international flight only if that passenger presents a passport that is valid for that flight.	4.2.2
Boarding a flight is a type of operation that requires authentication.	4.2.3
A passport must be considered valid for an operation that requires authentication if:     • that passport specifies an expiry date that is later than 6 months after the date of that operation, and:     • either that passport bears likeness to its bearer, or the operation does not permit visual identification.	4.2.4

The guiding principle behind 4.1 has visibly been to create a practical checklist for officers checking passengers at the gate at boarding time.  Focus is on the tasks at hand:  international flight boarding checks in one case, domestic flight boarding checks in the other.

Style 4.2 bears the mark of different concerns.  This style is trying to make rules as atomic and generic as possible.  Focus is on whatever is dictated by the rule logic itself, less on what is needed when the rule is implemented.  This is what makes the 4.2 rules more flexible when processes change or new processes are added:

• If for some reason, one of the checks is moved from the moment the passenger boards the aircraft to some earlier moment — e.g., when s/he passes gate entry or gains access to a bus — then in 4.2 only one rule needs changing, whereas in 4.1.1 the whole checklist needs to be reorganized.
  
  
• 4.2 defines passport validity for other operations than boarding an aircraft.  4.1 is solely concerned with the moment of letting passengers on a plane.

The fact remains that the 4.2 rules are more difficult to use for end users.  It is not immediately clear what are the checks that must be carried out at an international boarding gate.  Also, many people have difficulty getting used to the idea that 4.2.1 does NOT automatically imply that there are no further requirements for boarding than the one stated in 4.2.1 itself — the so-called "open world assumption" in business rules.  Writing good rules does not free you from also having to write good end user instructions, as a separate task.  At least (if this is any consolation…) the rules are the best possible help for completing that task!

4.1 and 4.2 are all about human action.  But the subject focus issues raised here apply just as well to actions intended to be executed by IT systems.  As a final example, imagine a business application that lets operators choose from a list of possible outgoing flights at the time when a booking is finalized.  5.1 is an attempt to express what that list of flights must look like:

An outgoing flight selected for a flight booking confirmation must offer at least as many available seats for that flight booking confirmation as the number of passengers specified in the flight booking request that gives rise to that flight booking confirmation.

5.1

(Assume that there is some other rule, not stated here, that explains exactly what qualifies a given seat as "available" for a given booking confirmation — in fact, there could be all kinds of further rules involved, depending on aircraft type, travel classes, fare classes, special seats located at emergency exits….)

5.1 is difficult to read.  It is 'tailored' to the situation of selecting outgoing flights at the moment of drawing up a booking confirmation.  The writer has chosen to focus on the conditions under which a business application may include a given flight in a list of flights to be selected from.  The main reason why this rule is difficult to use is that it is trying, without explicitly saying so, to accommodate people (or software developers) who have to figure out what flights they are allowed to choose from in a given situation.

Another drawback of 5.1 is that it assumes a pre-defined order in which data becomes available.  It is considered a given that the number of passengers for whom seats are requested is always determined prior to selecting an available flight.  Maybe with flight reservations it is not particularly easy to imagine otherwise — it is easier to imagine last-minute changes to the startdate and enddate of rental car periods as a reaction to limited car availability.  But that should not distract us from the fact that rules 'tailored' to a pre-defined process flow are simply not flexible enough.

A special further problem with 5.1 is that, as soon as a seat is selected for a booking, this will change availability for other bookings.  Because of the focus chosen, this logic has become very hard to express.  An approach along the lines of 5.2 is much better:

A seat may not be assigned to more than one flight booking confirmation.

5.2

This is true even though the focus of 5.2 (assignable seats) may not be the most helpful focus for application developers who need to produce, for each booking, a list of possible flights to be chosen from.

When you write business rules, you should concentrate on the logic to be expressed.  This will guide you to the most usable formulation.  Where does that leave subject focus as an additional guiding principle?

• As a business rule author, you do need to be aware of subject focus.  While subject focus does not change a rule's meaning, in straightforward cases (3.1), you might as well choose the focus that best helps people understand the rule.
  
  
• In more complex cases, requiring a specific subject focus can lead to rules that are too tied up with their implementation to be flexible and manageable.  That's true whether rules are implemented by human actions that require instructions (4.1, 4.2), or used to get supporting business software to behave as intended (5.1, 5.2).

[1]  See Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 5)," Business Rules Journal, Vol. 10, No. 6 (June 2009), URL:  http://www.BRCommunity.com/a2009/b485.html, as well as Parts 1, 9, 14, 18 of the same series of articles.  

[2]  Closely related are recommendations on subject use in business rule formulations in the RuleSpeak standard:  Ronald G. Ross, Basic RuleSpeak Guidelines, English ver. 2.3, Ch. 4.0, and Ronald G. Ross, RuleSpeak Sentence Forms, English ver. 2.3, Basic Concepts, p. 6 — both available for download (free) from www.rulespeak.com.  

[3]  In Part 5 of his series of articles, as referenced in note [1].  Most examples in this paper are taken from this series of articles.  Some are shortened or rephrased for the purposes of the present text.  

# # #