Business rule examples
Here are some examples of business rules. They have things in common, but they are also very different:
| Business rule examples |
|---|
| A driver must be 23 years of age. |
| Upon entering an aircraft, a passenger must show a valid ID showing a picture that bears his or her resemblance. |
| An incoming passenger must pass ID control before they she is allowed to pass customs. |
| A customer whose yearly order total exceeds $ 10,000 must be assigned a personal financial coach. |
A business rule is short, concise
A business rule is almost always a single sentence with a capital letter at the beginning and a full stop at the end. This makes rules relatively short and easy-to-digest.
We say that a business rule is atomic. The idea is that it only makes a single point. You don't have to follow a line of reasoning or keep in mind a structure of arguments.
A business rule is in natural language
A business rule does not contain technical codes or material that outsiders don’t know without training. Rules use normal, everyday English or Dutch. “Natural language” means a language naturally spoken by millions of people, but it also means “informal, simple, clear” as opposed to jargon that is hard to follow.
A business rule contains ‘must’ or another modal element
All the examples at the top of this article contain the word must. They tell you something must be done, or must be the case. It’s an intention or wish, not necessarily a fact in reality. People must do something, but they don't always do it.
Must transmits the idea of a necessity or obligation. We say it is a modal element. Modal means: “not factual”. Another modal element is may, which transmits the idea of possibility or permission. You can also say it is necessary that…, it is permitted that… .
A business rule is self-sufficient
A business rule tells the reader something that is so easy to interpret that you do not typically need more information. This is an ideal to strive for, rather than a reality. In reality you need more: good definitions of the terms used in the rules, and good consistency between a rule and neighbouring other rules.
You don’t need to say when the rule is needed
A rule concentrates on what must happen: the desired business conduct or behaviour. It can only do that by not addressing secondary aspects. The question of when the rule is needed (or tested) is such a secondary concern. Sometimes it is economical not to need to go into this detail. In a car rental company, “A driver must have a valid driving license” is probably needed when the client registers as the future driver of a rental car, but it could also apply at the time when the person actually gets in the car. If the difference is important, the rule must state it.
You don’t need to say what happens to people who violate the rule
A rule is not a fact: there can be all sorts of reasons why people in the business violate (do not comply with) the rule. Rules must be enforced. There are levels of enforcement. Is the rule enforced as a mild suggestion? Or can people lose their job over it? Level of enforcement is a separate thing. It's not the rule itself.
You don’t need to say if software is needed to enforce the rule
In a USoft setting, business rules serve software development projects. But a business rule is not a software rule. It does not typically go into the detail of whether or not software must be built to support people in following the rule. A rule can be helpful or essential to software development teams even if they do not directly implement it in code. It’s also not a black-and-white matter: there are rules that software can implement to the full 100%, but very often, software contributes to enforcing a rule.