Explanation

Business rules are kinds of requirements on how the business, including its business tools, must operate. They can be laws and regulations imposed on the business but also express the chosen business architecture and style. There are two ways of capturing business rules:

• Model-based-Business rules are captured as stereotyped constraints in UML models. The rule can be declared using natural language or a more formal notation, such as Object Constraint Language (OCL). The advantage of this technique is that business rules are captured and displayed at the source where they apply. The main disadvantage is that business rules are scattered throughout the model, and it is therefore difficult to view related business rules. The Report: Business Rules Survey provides an overview of all business rules in the model. 
• Document-based-Business rules are captured in a separate document. The document contains business rules, but these are not the business rules used in the model-based approach. A document-based approach is useful when large numbers of business rules apply (such as for financial products). A disadvantage is that business rules are captured in a different artifact than the source where they apply.

Capturing Business Rules

Business rules can be captured in both document and model form. If you want to obtain an overview of business rules in models, you can generate a Report: Business Rules Survey.

A Business Rules Document is especially useful for business rules that have long descriptions, such as legislation. The disadvantage of document-based business rules is that it may still be necessary to trace the business rule to all parts of the model where it applies (if more than one). This can be overcome by opting for model-based business rules that can be captured directly in the models where they apply. However, this has the disadvantage of being "hidden away in the model," and it is more difficult to obtain an overview of all business rules that have some common characteristic (such as belonging to a particular category).

Levels of Formalism

Business rules need to be rigorously and formally expressed so that they can form a basis for automation. An alternative would be to use the Object Constraint Language (OCL) as specified in the Unified Modeling Language (UML) [RUM98].  Always consider who will be reading the business rules. Focusing on the reader helps ensure that the manner in which you capture the business rules (documents or models), your selected style, and level of formalism match the target audience. Business rules that cannot be understood by those who must read them are a waste of time on any project.

Example: 

You may want to express a limit to the size of a team to less than ten members. With the OCL, you can state this business rule as an invariant:

context Team inv:

    self.numberOfMembers <= 10

However, you must consider that this formal type of language may be difficult to interpret for many of your stakeholders, so a more natural language style might be preferable. You can define a set of reserved expressions that you use to define the rules. Those expressions could be the same as those defined in [ODL98]: 

• IF
• ONLY IF
• WHEN
• THEN
• ELSE
• IT MUST ALWAYS HOLD THAT
• IS CORRECTLY COMPLETED

Example: 

In this less formal language, the example above reads:

IT MUST ALWAYS HOLD THAT the number of team members is less or equal to 10. 

Categories of Business Rules

Rules can be classified in many ways, although it is common is to divide them between constraint rules and derivation rules. [ODL98] Both categories can be further subdivided in the following manner: 

• Constraint rules specify policies or conditions that restrict object structure and behavior. Constraint rules may always apply, or they may apply only under certain conditions. Constraints that always apply are referred to as invariants.

• Stimulus and response rules constrain behavior by specifying when and if conditions must be true in order for behavior to be triggered. 
• Operation constraint rules specify those conditions that must hold true before and after an operation to ensure that the operation performs correctly. 
• Structure constraint rules specify policies or conditions about classes, objects, and their relationships that should not be violated. 

• Derivation rules specify policies or conditions for inferring or computing facts from other facts. 

• Inference rules specify that if certain facts are true, a conclusion can be inferred. 
• Computation rules derive their results by way of processing algorithms, a more sophisticated variant of inference rules. 

This classification of business rules is practical when explaining what business rules are, how to find them, and how to work with them. However, there is no need to think of them as fixed groupings to which you always need refer. Therefore, our template for the business rules artifact does not show this classification-in your project most likely there will be other groupings (by domain, by user, or by product group) that are much more valuable to show. For more information about classifying and applying business rules, see [ROS97].

How Business Rules Are Reflected in the Models

A business rule affects how your models look. It can also affect how you sequence tasks in your activity diagram, and it may even affect what associations you have between your business entities. Some rules are not easy to straightforwardly translate to the way a diagram looks-they may need to reside in the descriptions of the model elements. 

Business rules in a UML diagram should be linked to the model element they affect. 

It is also useful to track business rules in the Requirements Attributes for traceability and reporting purposes.

Stimulus and Response Rules

This kind of business rule affects the workflow of a business use case and can be traced to the business use case to which it applies. You might either show a conditional path or an alternative path through the workflow. If the actions involved are less significant, it can be sufficient to let the evaluation of the business rule be enclosed in an activity state. 

In the Business Analysis Model, a rule of this kind could, for example, affect how you describe the lifecycle a business entity, or it could be part of the description of an operation on a business worker. Examining the identified business events is a very useful source for defining these kinds of business rules. Usually a business event is identified because somebody or something is interested in the occurrence of the event. Ask the question, "What conditions or behavior applies once the event occurs?"

Example: 

In an order management organization, you might find the following rule: 

WHEN an Order is canceled

IF Order is not shipped

THEN close Order. 

This business rule is reflected by showing two alternative paths in a workflow and specifically using a decision and guard condition on outgoing transitions. 

The business rule in this case translates to an alternative path through the workflow.

Operation Constraint Rules

This type of business rule often translates to preconditions and post-conditions of a workflow, or to a conditional or alternative path in a workflow. It can also be a performance goal or some other non-behavioral rule that should be traced to the business use cases to which it applies. 

Example: 

In an order management organization, you might find the following rule: 

Ship Order to Customer

ONLY IF Customer has a shipping address. 

The business rule translates to an alternative path in the workflow.

Example: 

Here is another operation constraint rule: 

IT MUST ALWAYS HOLD THAT

All customer inquiries must be responded to within 24 hours of their receipt

This business rule would translate to a performance goal of a business use case. See the section on performance goal in  Guideline: Business Use Case. 

Structure Constraint Rules

This type of business rule affects relations between instances of business entities. They are expressed by the existence of an association between two business entities, sometimes as a multiplicity on the association.  

Example: 

In an order management organization, you might find the following rule: 

IT MUST ALWAYS HOLD THAT

an Order refers to at least 1 Product. 

This business rule translates to an association with the multiplicity of 1..*. 

Inference Rules

Inference rules often seem similar to stimulus and response, as well as to operation constraint or structure constraint types of rules. The difference is that there are a few steps that need to be thought through to arrive at the conclusion. The rule implies a method that needs to be reflected in an activity state of the workflow and eventually in an operation on a business worker or business entity. 

Example: 

You might set up the following rule to determine a customer's status:

A Customer is a Good Customer IF AND ONLY IF

the unpaid invoices sent to this Customer are less than 30 days old. 

This business rule corresponds to an alternative path through the workflow, and the method prescribed will be part of the Evaluate Customer task.

Computation Rules

Computation rules are similar to inference rules. The difference is that the method is more formal and looks like an algorithm. As with inference rules, this method needs to be traced to an task in the workflow and, eventually, to an operation on a business worker or a business entity. 

Example: 

A computation rule can specify value computation: 

The net price of a Product IS COMPUTED AS FOLLOWS

product price * (1+tax percentage/100).

Evaluating the net price could be part of the task Ship Order as you produce the bill sent with the order. In the Business Analysis Model, this rule translates to associations and operations. 

The rule needs to be reflected as a method in the operation Calculate Net Price but also implies a need for relationships between classes in the model.