Show TOC

Business RulesLocate this document in the navigation structure

A business rule is a written statement specifying what a system must do or how it must be structured. Rules can be derived from a government-imposed law, a customer requirement, or an internal guideline. You can attach rules to your model objects to complement your diagrams with information that is not easily represented graphically.

For example, a rule stating that "An employee belongs to only one division." can help you graphically build the link between an employee and a division. Rules often start as simple observations that develop, during the design process, into more detailed expressions. You may, for example, develop rules to explicitly define what information a customer supplies when placing an order, or how much a customer can spend based on a credit limit.

Rules can be developed from procedures that the system must respect, specifications dictating the scope of the project, and external constraints.

You can create a business rule in any type of model/diagram:
  1. Navigate to the model property sheet by clicking the Model link in a diagram property sheet.
  2. Click the Children facet. If the Business Rules list is not visible, add it by clicking the Add objects... (or Other objects...) link and then clicking the Business Rules link.
  3. Click the + button above the Business Rules list and then click its name link to open its property sheet.

Business rules can have the following properties:




Identify the object. The name should clearly convey the object's purpose to non-technical users, while the code, which is used for generating code or scripts, may be abbreviated, and should not normally include spaces. You can optionally add a comment to provide more detailed information about the object. By default the code is generated from the name by applying the naming conventions specified in the model options. To decouple name-code synchronization, click to release the = button to the right of the Code field.


Extends the semantics of the object. You can enter a stereotype directly in this field, or add stereotypes to the list by specifying them in an extension file.


Specifies the nature of the business rule. You can choose between:

  • Constraint – a check constraint on a value. In a PDM, constraint business rules can be generated in the database. For example, "The start date should be inferior to the end date of a project."

  • Definition – a property of the element in the system. For example; "A customer is a person identified by a name and an address".

  • Fact – a certainty in the system. For example, "A client may place one or more orders".

  • Formula – a calculation. For example, "The total order is the sum of all the order line costs".

  • OCL constraint [OOM only] – An Object Constraint Language expression.

  • Requirement – a functional specification. For example, "The model is designed so that total losses do not exceed 10% of total sales".

  • Validation – a constraint on a value. For example, "The sum of all orders for a client must not be greater than that client's allowance".

Server expression/ Client expression Though business rules typically start out as descriptions, as you develop your model and analyze your business problem, you can enrich them by adding technical expressions.