A business rule defines or
constrains one aspect of your business that is intended
to assert business structure or influence the behavior
of your business. Business rules often focus on access
control issues, for example, professors are allowed to
input and modify the marks of the students taking the
seminars they instruct, but not the marks of students in
other seminars. Business rules may also pertain to
business calculations, for example, how to convert a
percentage mark (for example, 91 percent) that a student
receives in a seminar into a letter grade (for example,
A-). Some business rules focus on the policies of your
organization, perhaps the university policy is to expel
for one year anyone who fails more than two courses in
the same semester.
Figure 1. Some sample
business rules (summary form).
- BR123 Tenured professors may administer student
- BR124 Teaching assistants who have been granted
authority by a tenured professor may administer
- BR177 Table to convert between numeric grades and
- BR245 All master's degree programs must include
the development of a thesis.
Figure 1 summarizes several
examples of business rules. Notice how each business
rule has a unique identifier, my convention is to use
the format of BR#, but you are free to set your own
numbering approach. The unique identifier enables you to
refer easily to business rules in other development
artifacts, such as
class models and
In some situations you'll discover
that business rules can be described very simply,
perhaps with a single sentence. In other situations
this isn't the case.
presents one way to fully document BR123. There are
several sections in this figure:
- Name. The name should give you a good idea
about the topic of the business rule.
- Description. The description defines the
rule exactly. Although I used text to describe this
rule it is quite common to see diagrams such as
flow charts or
UML activity diagrams used to describe an
algorithm. Other options include business rule
languages such as
Object Constraint Language (OCL), the
ILOG rules language, or
Rules Markup Language (BRML). As Agile Modeling
Apply the Right Artifact(s) for your situation.
- Example (optional). An example of the rule
is presented to help clarify it
- Source (optional). The source of the rule
is indicated so it may be verified (it is quite common
that the source of a rule is a person, often one of
your project stakeholders, or a team of people).
- Related rules (optional). A list of
related business rules, if any, is provided to support
traceability between rules.
- Revision history (optional). An
indication of the date a change was made, the person
who made the change, and a description of the change.
Detailed business rule.
Tenured professors may
administer student grades
Only tenured professors are
granted the ability to initially input, modify, and
delete grades students receive in the seminars that
they and they only instruct. They may do so only
during the period a seminar is active.
Dr. Bruce, instructor of
"Biology 301 Advanced Uses of Gamma Radiation," may
administer the marks of all students enrolled in
that seminar, but not those enrolled in "Biology 302
Effects of Radiation on Arachnids," which is taught
by Dr. Peters.
University Policies and
Doc ID: U1701
Publication date: August 14,
BR12 Qualifying For Tenure
BR65 Active Period for Seminars
BR200 Modifying Final Student
is clearly a lot more wordy than most project teams
need. A more agile approach would be to simply write
the name of the business rule, the business rule number,
and the description on an index card and leave it at
that. Or you might want to get a little fancier and
type the business rule into a Wiki page (www.wiki.org)
or a word processor (feel free to use this
template). Remember to keep your models as
simple as possible.
Business rules are identified in
the normal course of requirements gathering and
analysis. While you are usage modeling, perhaps with use
cases or user stories, you will often identify business
rules. A rule of thumb is if something defines a
calculation or operating principle of your organization
then it is likely a good candidate to be documented as a
business rule. You want to separate business rules out
of your other requirements artifacts because they may be
referred to within those artifacts several times. For
example, BR129 was referenced by the
Enroll Student In Seminar use case and likely
would be referenced by your
class models and perhaps even your source code.
However, if you have only a handful of business rules or
use cases, you may choose to document them right in the
use cases. A rule of thumb: start out including them in
the use cases until it becomes obvious, or painful, to
do so. This may be because the sheer number of business
rules is dominating the use case or because the same
business rule is referenced in two or more use cases.
A good business rule is cohesive:
in other words, it describes one, and only one, concept.
By ensuring that business rules are cohesive, you make
them easier to define and increase the likelihood they
will be reused (every time one of your artifacts refers
to a business rule, even other business rules, it is
effectively being reused). Unfortunately, because
business rules should focus on one issue, you often must
identify a plethora of rules.
Ronald Ross (2003) describes several basic
principles of what he calls "the business rule
approach". He believes that rules should:
- Be written and made explicit.
- Be expressed in plain language.
- Exist independent of procedures and workflows
(e.g. multiple models).
- Build on facts, and facts should build on concepts
as represented by terms (e.g.
- Guide or influence behavior in desired ways.
- Be motivated by identifiable and important
- Be accessible to authorized parties (e.g.
- Be single sourced.
- Be specified directly by those people who have
relevant knowledge (e.g.
active stakeholder participation).
- Be managed.
Many business rules can actually
be thought of as
constraints, and in fact constraints can apply to
technical or business issues. In the UML business
rules are often described on diagrams using the
Constraint Language (OCL) (Warner
and Kleppe 1999) which can add to people's confusion
regarding the differences between the two concepts.
Don't worry about it, the important thing is to identify
and understand the requirement not categorize it.
This artifact description is
excerpted from Chapter 7 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.