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.

BR124 Teaching assistants who have been granted
authority by a tenured professor may administer
student grades.

BR177 Table to convert between numeric grades and
letter grades.

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
use cases.

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.
Figure 2
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.

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.

Example:

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.

Source:

University Policies and
Procedures

Doc ID: U1701

Publication date: August 14,
2000

Related rules:

BR12 Qualifying For Tenure

BR65 Active Period for Seminars

BR200 Modifying Final Student
Grades

Figure 2
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.
glossaries).

Many business rules can actually
be thought of as
constraints, and in fact constraints can apply to
either
technical or business issues. In the UML business
rules are often described on diagrams using the
Object
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.

Translations

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott Ambler + Associates.

Recommended Reading

This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprisedescribes the Disciplined Agile Delivery (DAD) process decision framework.
The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation forscaling agile.
This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting.
Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process.
Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams.
Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.