Business rules

A business rule is a statement that defines or constrains some aspect of the business that is intended to assert business structure or influence the behavior of your business.

While a data (or object) model describes the structure of a business – what the business can do – for the most part, it cannot describe what it must do, or what it cannot do. Indeed, there are few notations available for representing business rules in all their subtlety.

Business rules are intended to assert business structure or to control or influence the behavior of the business. The business rules that concern the project are atomic - that is, they cannot be broken down further.

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.

Business rules address the core business. Organizational rules address how the organization runs its business. A good rule of thumb is that 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.

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.

Business rules should:

· Be written and made explicit.

· Be expressed in plain language.

· Exist independently 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 (UML), and in fact constraints can apply to either technical or business issues.