 |
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
grades.
- 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.
- 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
Business
Rules Markup Language (BRML). As Agile Modeling
suggests,
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.
Figure 2.
Detailed business rule.
|
Name: |
Tenured professors may
administer student grades |
|
Identifier: |
BR123 |
|
Description: |
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).
- Guide or influence behavior in desired ways.
- Be motivated by identifiable and important
business factors.
- Be accessible to authorized parties (e.g.
collective ownership).
- 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
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.
This artifact description is
excerpted from Chapter 7 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
 |
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
Translations
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 W.
Ambler + Associates.
 
|
