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 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|
|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 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 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) 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.
|This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.|
|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 fundamental programming and testing techniques for successful agile solution delivery. The book also shows how to move from your agile models to source code, 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.|