Rules that give you too much freedom

Rules that give you too much freedom

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 for a and a must be calculated as .

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 I want so that .

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

Have you changed your mind about rules? Let me know by sharing this post.

This article was originally published by BRCommunity (link).