Example business rule domains include: *
Business rules exist for an organization whether or not they are ever written down, talked about or even part of the organization’s consciousness. However it is a fairly common practice for organizations to gather business rules in at least a very informal manner.
Organizations may choose to proactively describe their business practices in a database of rules. For example, they might hire a consultant to come through the organization to document and consolidate the various standards and methods currently in practice.
More commonly, business rules are discovered as part of a formal requirement gathering process during the initial stages of a project. In this case the collecting of the business rules are coincidental. Projects, such as the launching of a new product, might lead to a new body of business rules for an organization, i.e. this new product would require the employees to conceptualize about what the purpose of the organization is in a new way. This practice of coincidental business rule gathering is vulnerable to the creation of inconsistent or even conflicting business rules within different organizational units, or within the same organizational unit over time.
Business Rules Methodology is the process of capturing business rules in English, in real-time while empowering users to manage rules with a few simple steps.
Gathering business rules is also called rules harvesting or business rule mining. Business analysts or consultants can extract the rules from Use cases, system code or by organizing SME workshops/Interviews etc. Software technologies designed to capture business rules through analysis of legacy source code or of actual user behavior, can accelerate the rule gathering process.
Despite many software vendors, consultants and research institutions offering business rules solutions, business rules are usually only gathered when dictated by law, as the first step in the automation process or as an ephemeral aid to engineers. This is mostly due to the overhead and effort required to maintain this database of rules. This becomes most severe the more dynamic and fluid the business rules for an organization are, for example in start-up companies. Another factor mitigating usage is the lack of incentive for employees to part with their most valuable asset to the organization; their knowledge of the business rules. A third factor is access to viable technology for maintaining business rules. A classic solution is the business rules engine. Rules engine products have been gaining traction in the market place.
Software packages automate business rules using business logic. The term business rule is sometimes used interchangeably with business logic; however the latter connotes an engineering practice and the former an intrinsic business practice. There is value in outlining an organization's business rules regardless of whether this information is used to automate its operations.
Business rules can be expressed in a very formal language. An example of when this rigour is required is in highly technical enterprises such as the building of a bridge. Another example is a project trying to automate the business rules gathering process. Example languages include Unified Modeling Language, Z notation, Business Process Execution Language, Web Services Policy Framework, Business Process Modeling Notation, or Semantics of Business Vocabulary and Business Rules (SBVR)