Guidelines: Business Rules
Topics
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.
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).
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.
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].
A business rule affects how your models look. It can also affect how you sequence
activities 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 Guidelines:
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
activity.
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 activity 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 activity 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.
|
This content developed or partially developed by Empulsys BV.
|
|