Requirements Modelling and Specification for Service Oriented Architecture

3.4. Requirements and Business Rules

It is a common error to confuse business rules with requirements but they are not the same thing at all.

A business rule is a compact, atomic, well-formed, declarative statement about an aspect of a business that can be expressed in terms that can be directly related to the business and its collaborators, using simple unambiguous language that is accessible to all interested parties: business owner, business analyst, technical architect, customer and so on. This simple language may include domain-specific jargon.

The term 'well-formed' comes from Logic and needs explanation. The rules must be executable on a machine if they are to be of much use in a business rules management system. This implies that they must be convertible into statements in some formal logic: statements that are well-formed with respect to that logic.

One corollary of the declarative principle is that business rules do not describe business processes; they do, however, constrain what processes are permissible.

Business rules are statements expressed in a language, preferably a subset of a natural language such as English. I see two clear kinds of statements that must be distinguished: assertions and rules. Assertions or facts have the form: 'A is X' or 'P is true'. These are equivalent forms, e.g. I can convert the former into '"A is X" is true'. Simplifying slightly, until later in this book, rules have the equivalent forms: 'If A then X'; 'X if A'; 'When A then X'; and ...