Freedom should be removed by rules.  In fact, a rule that does not remove freedom in some way is not a rule according to the SBVR standard.  That being said, you may be confused by the title of this column.  Well, given this restriction on what a rule is and what you expect from a rule statement, there are still many ways to express such a rule.

RuleSpeak and SBVR's Structured English impose some restrictions on our use of language (see the box below), but due to the flexible nature of natural language you still have a lot of freedom ... consequently, we rarely see the same rule written in exactly the same way by different people using natural language.

There is a tendency to ask for a more restricted rule language to improve:

• consistency in writing similar rules by different people,
• consistent interpretation (non-ambiguity),
• support for validation & verification,
• translation to software systems.

Expressing rules as decision tables or decision trees greatly reduces your freedom of form but also your expressiveness.  So, when I need the expressiveness of natural language, I introduce very specific rule patterns to restrict my freedom and gain rigor.

Examples:

• ... must be calculated as ....
• A ... for ... must be calculated as ....
• A <data element> for a <timeframe> and a <location> must be calculated as <formula>.

Each pattern is more specific, provides more guidance, and (consequently) less freedom.  The last pattern above is even specific to a particular domain.

Sentence patterns seem to be the fashion today.  They are not only popular for rules but also used in the descriptions of user stories in agile projects:  As a <role> I want <something> so that <benefit>.

Rules must decrease freedom and so must rule sentence patterns.  I am curious about the sentence patterns you use or recognize in your organization.  Please send me an e-mail with your examples at silvie@librt.com .

# # #