Business Rule

A business rule is a rule that defines or constrains some aspect of the business. For example, "Only customers older than 18 can buy products placed in the category Adults" constrains business because it stops adolescents from buying some products.

Business rules apply to people, processes, corporate behavior, and computing systems in an organization, and are put in place to help the organization achieve its goals
source: Wikipedia

Analysts come across many types of rules during their work, and they are not all the same. It is why we emphasize the business rules. For example, the statement "Only users with the role Manager shall be able to see the screen" is certainly a rule, but it is directly related to the specific information system, not to the business in general. On the other hand, business rules are not tied to any system, so they must be valid even if the whole company would have been operated using only pen and paper. For example, the rule "If the account balance reaches 0, customer cannot use the service anymore" must be true if the company uses complex information systems, but also if it stores all data in binders.

Business Rules Types

The business rules can be divided into the following groups:

Facts

Facts are statements which describe some aspect of the business, such as relationships between important business terms. The facts are always true and are usually documented in a data dictionary or in a domain model.

• Every product belongs to 1 or many product categories

Constraints

A constraint is a statement that restricts the actions that might be performed within the business

• Only customers older than 18 can buy products placed in the category Adults

Action Enablers

Action enablers trigger an action if the specific conditions are true - "If the account balance reaches 0, the customer is notified by email".

Derivations

Derivations are very similar to action enablers. They are also written in the form of the if-then statement yet, the then clause does not trigger action, but defines a new knowledge instead.

• If the order is not paid within 30 calendar days after purchase, it is considered canceled

Computations

Each business includes rules specifying how to calculate business data. It could be a simple formula but also a complex algorithm. Simple rules could be easily captured in plain language, but computations or complex decisions are better described using decision tables or diagrams.

1/ Textual Rules

   Discounts:
   - If it is United Airlines and Paypal or Visa is used, customer gets 2% discount
   - If it is United Airlines and Mastercard is used, customer gets 1.9% discount
   - If it is Amaerican Airlines and Paypal is used and at least 3 tickets are selected, customer gets 1% discount
   - If it is Amaerican Airlines and Paypal is used and no luggage is selected, customer gets 1% discount 
   - If it is Amaerican Airlines and the departure date is 24/12, all tickets customer gets negative bonus -2% discount  

2/ Decision Table

3/ Activity Diagram

Terms

Some people consider business terms a specific type of business rule. It is ok, but in Effective Analysis, we store terms as separate artifacts, which is elaborated more in its own chapter.

Business Rules and Requirements

Even though business rules often look very similar to software requirements, so it is therefore sometimes not easy to distinguish between them, business rules are not requirements.
Business rules may generate software requirements if the goal is to implement the rule in the software system, but it is the only connection between them as the business rules are never part of any system. The business layer containing the business rules must be separated from the software layer because otherwise, each system specification would have to duplicate the same rules over and over again as the business rules must be implemented in all systems which use them.

"If the account balance reaches 0, the account holder receives an email notification"

• It is a business rule because it is not associated with any particular system
• Corresponding requirement: "System shall send an email notification to the account holder if the account balance reaches 0"

Discount is calculated according to the following algorithm: ...

• It is a business rule because it is not associated with any particular system
• Corresponding requirement: "System shall calculate the discount (see the algorithm here) and shall display it to the customer before the order is submitted"

Order Management System: "Only employees with the BRN role are allowed to delete an order"

• This is a software requirement. If there were no Order Management System this statement would not be valid.

Documenting Business Rules

Business rules are valuable enterprise asset which is shared among multiple departments and is implemented in various systems. They are used on a daily basis, and, surprisingly, it is not very common practice at companies to document business rules properly. As the company-wide asset, business rules should be stored in a central repository and only be referenced from where it is needed. The central management eliminates duplicate rules, enables storing all rules in one place, and referencing the rules is easy:

But instead, rules are usually stored in guidebooks, internal methodologies, and some are even not documented at all, so they are only in people's heads. This requires analysts to find the right documents or people, which is frustrating and time-consuming. It also often leads to the situation wherein the end the rules are spread across multiple project specifications, duplicated or even worse, implemented inconsistently in different systems.

Internal Vs. External Development

If you work on projects, which are developed internally, you have access to the central business rules repository, which you can use and must modify when the project introduces new rules. But not all systems are developed internally as each enterprise has some systems delivered externally. External analysts working for the software vendor usually don't know the whole enterprise, they focus on learning the part of the business that is important for the particular project, including the knowledge of business rules. During the project, the external team learns the existing business rules and reuse them but might also create new ones. The team very often crates their own business rules repository for the needs of the project. After the project ends, the software vendor should provide the customer with the set of new or modified business rules so that they could be incorporated into the central register. In practice, though, this does not happen, and the vendor continues building and maintaining its own register for the upcoming project phases or system maintenance. This is an issue as it introduces the risk of duplications.

It is even worse if the vendor has two teams, both working on systems for the same client, and they both create their own version of the same business rules. If it is not possible to just reference the rules at the customer's side, at least don't duplicate them on your side and instead collaborate and share the rules between the projects for the same client.

Good Practices

1. Business rules should be stored in the central repository to avoid duplications and to streamline the management of the rules
2. In the central repositor, rules should be captured as unique objects which are easily referenceable, searchable or sortable
3. Don't store the rules in a flat structure. Organize them by business domain or by any other suitable criterion.
4. Business rules should never be directly included in artifacts such as use cases, screens, etc. Instead, they should always be referenced from the central repository.
   • 
5. Use atomic business rules. An atomic business rule cannot be further decomposed into other rules. If you're a man, then you get a blue sticker is an atomic rule. If you're a man, then you get a blue sticker, and if you're a woman, then you get a red sticker is not atomic because it can be decomposed to two rules, one for men, one for women. Non-atomic rules are less readable and hard to manage.
6. Document only pure business rules, not information systems constraints
7. Business rules are not exclusively textual statements. There is a variety of business rules forms.