Classifications

Classifications allow development teams to classify Business Rules in a more customized fashion than is possible with the pre-defined values in the Type field.

Examples of Classifications are:

•Terms and Facts

For most projects, it is a good idea to use a Classification value such as TERM or DEFINITION to mark lexical definitions that explain the meaning of some technical term. This allows the team to produce a glossary of terminology used simply by querying all the Business Rules with this Classification. These definition rules usually have the Requires Implementation flag set to No.

Some development teams also find it useful to mark facts such as "Driving Licenses have an Expiry Date". Facts are typically, but not necessarily, implemented by defining tables, columns or relationships rather than by defining data integrity constraints.

•Application tiers

One example of useful Classification values are values that indicate at what level or application tier a rule is implemented: INTERFACE, SERVICE, BATCH, PROCESS, RULE, DATA INTEGRITY, DATA STRUCTURE, APPLICATION DATA.

•Exclusions and exceptions

For most projects, it is a good idea to use a Classification value such as EXCLUSION to mark business rules that state what the target system must NOT support, and consequently what need not be built. These rules should have Requires Implementation set to No. Rules with Type = Instruction are typically of this type.

For rules that belong to another rule, you may find it helpful to mark

•Assumptions

Every development team makes assumptions or interpretations on the basis of requirements communicated to them. It is often helpful to formulate assumptions as Business Rules, especially if for some reason the team wants to implement the assumption in the system before having the rule validated by the customer. To indicate that the assumption is of a specific other rule stated earlier by the customer (an interpretation of a rule), you can refer to that rule in the Belongs To field.