Introduction

Technical level business rules are restrictions on how the business, including its business process, activities and tasks must operate. They range from laws and regulations imposed on the business to corporate policies. There are two kinds or categories of business rules (this term is used in the generic sense) defined (as in SVBR), each addressing a required aspect of the business operation:

• Definitional Business Rules - the computation, numerical or derived logic that controls a process (e.g. If Inventory(x) < 5 Then OrderMore(x)). They are also called "operative" since they directly control processes, the operation;
• Behavioural Business Rules - these rules ensure that a process does not deviate from prescribed norms. They are external to the process, similar to a referee or policeman enforcing game rules or traffic rules. They are also called "structural" since they are typically external to the process (i.e. they indirectly affect business processes: If orderValue(order) > $1M Then doCreditCheck(customer)).

A good source for definitions and explanations of business rules is the: Business Rules Community  and the Business Rules Group.

The Business Rules Group created the Business Rules Manifesto in about 2003. It defines some very useful and practical aspects of business rules, such as:

• Business Rules are primary requirements, not secondary - rules are essential for, and a discrete part of, business models and technology models;
• Separate from processes, not contained in them - rules apply across processes and procedures, and should not be contained within the activity or process (i.e. not hardcoded);
• Deliberate knowledge, not a by-product - rules are basic to what the business knows about itself—that is, to basic business knowledge. Rules need to be nurtured, protected, and managed;
• Declarative, not procedural - rules should be expressed declaratively in natural-language sentences for the business audience. A rule and its implementation are separate concerns;
• Well-formed expression, not ad hoc - business rules should be expressed in such a way that they can be validated for correctness by business people;
• For the sake of the business, not technology - rules are about business practice and guidance; therefore, rules are motivated by business goals and objectives and are shaped by various influences;
• Of, by, and for business people, not IT people - rules should arise from knowledgeable business people;
• Managing business logic, not hardware/software platforms - rules, and the ability to change them effectively, are fundamental to improving business adaptability.

See the complete definition on the Business Rules Group web site, the link is defined above.

Practicalities

Business rules must be more than fuzzy policies, particularly at the technical level. They must be usable within the system to make decisions regarding its operation ... they need to be enforceable is some fashion through software coding or a rules engine. Definitional rules are usually easy to identify and define in a practical and usable way since they are often based on logical notions and system aspects ... they are computable. Behavioural rules on the other hand may be more difficult to understand, define and implement within an IT architecture.

At the technical level business rules are captured and defined in a more precise manner—they are described in a more technical fashion so that they may be transformed into implementable logic within the Technical Perspective models and code. 

UAM Perspectives

In each of the three Perspectives a limited number of business rules are defined, as derived from BPMN. See: Supporting Material: BPL Summary, and Supporting Material: LPL Summary, and Supporting Material: TPL Summary. These rules are in general Definitional Rules, however some Behavioural Rules may also be addressed through these modeling elements (e.g. If orderValue(order) > $1M Then doCreditCheck(customer)).

Business rules are captured within a process as either part of the description for a "gateway" or "Business Rule Task" within the process, or as a separate Technical Rule entity shown attached to the process, as shown in the example below:

Example

ThuNorTech Corporate Standards, Guidelines, Policies

ThuNorTech Service Delivery Policies & Guidelines. This document lists ThuNorTech’s objectives in terms of service levels and time to publish. This document is the primary source for the business rules that drive the operational processes.

Determine Reports & Lab Studies Needed – Business Rules – Technical Level

Tip 1:  Put values in the cells, not in the condition statement.  This provides greater flexibility when maintaining the rules and makes it easier for the business to understand.

Tip 2:  Include the business rule statement in the decision table for ease of understanding, cross-reference and maintenance.

Tip 3:  Format the rule table to accommodate the rule processing engine selected.  This will also ease maintenance and decrease the possibility of errors introduced by detailed designers / programmers.  The business analysts should be able to maintain the physical rule files. 

Tip 4:  Refer to publications written by Ronald Ross at http://www.brsolutions.com/.

If the rules have been formatted at the Logical level to accommodate the rule processing engine, then there should be no difference between them and the rule table structures at the Technical level. If not, then the rules defined at the Logical level will need to be more precisely re-defined and re-structured for the rule processing engine. Designers may add a default rule for detecting programming errors. Software designers will simply have to add the code references that apply to each condition and outcome.