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

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 ( www.wiki.org) 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:

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

Source

This artifact description is excerpted from Chapter 7 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

Translations

• Japanese