Agile Modeling Logo

Business Rules: An Agile Introduction

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).

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:

Figure 2. 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 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 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 ( or a word processor. 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:

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.