The
Business Rules Group, an independent standards group of business and IT professionals, published
The Business Rules Manifesto, principles of rule independence.
It looks like a "Declaration of Independence for Business Rules", and it is pretty interesting reading for people interested in the rules movement.
The original document is here: http://www.businessrulesgroup.org/brmanifesto.htm
The Business Rules Manifesto*
Article 1. Primary Requirements, Not Secondary
1.1. Rules are a first-class citizen of the requirements world.
1.2. Rules are essential for, and a discrete part of, business models and technology models.
Article 2. Separate From Processes, Not Contained In Them
2.1. Rules are explicit constraints on behavior and/or provide support to behavior.
2.2. Rules are not process and not procedure. They should not be contained in either of these.
2.3. Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.
Article 3. Deliberate Knowledge, Not A By-Product
3.1. Rules build on facts, and facts build on concepts as expressed by terms.
3.2. Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.
3.3. Rules must be explicit. No rule is ever assumed about any concept or fact.
3.4. Rules are basic to what the business knows about itself -- that is, to basic business knowledge.
3.5. Rules need to be nurtured, protected, and managed.
Article 4. Declarative, Not Procedural
4.1. Rules should be expressed declaratively in natural-language sentences for the business audience.
4.2. If something cannot be expressed, then it is not a rule.
4.3. A set of statements is declarative only if the set has no implicit sequencing.
4.4. Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.
4.5. A rule is distinct from any enforcement defined for it. A rule and its enforcement are separate concerns.
4.6. Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.
4.7. Exceptions to rules are expressed by other rules.
Article 5. Well-Formed Expression, Not Ad Hoc
5.1. Business rules should be expressed in such a way that they can be validated for correctness by business people.
5.2. Business rules should be expressed in such a way that they can be verified against each other for consistency.
5.3. Formal logics, such as predicate logic, are fundamental to well-formed expression of rules in business terms, as well as to the technologies that implement business rules.
Article 6. Rule-Based Architecture, Not Indirect Implementation
6.1. A business rules application is intentionally built to accommodate continuous change in business rules. The platform on which the application runs should support such continuous change.
6.2. Executing rules directly -- for example in a rules engine -- is a better implementation strategy than transcribing the rules into some procedural form.
6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.
6.4. Rules are based on truth values. How a ruleís truth value is determined or maintained is hidden from users.
6.5. The relationship between events and rules is generally many-to-many.
Article 7. Rule-Guided Processes, Not Exception-Based Programming
7.1. Rules define the boundary between acceptable and unacceptable business activity.
7.2. Rules often require special or selective handling of detected violations. Such rule violation activity is activity like any other activity.
7.3. To ensure maximum consistency and reusability, the handling of unacceptable business activity should be separable from the handling of acceptable business activity.
Article 8. For the Sake of the Business, Not Technology
8.1. Rules are about business practice and guidance; therefore, rules are motivated by business goals and objectives and are shaped by various influences.
8.2. Rules always cost the business something.
8.3. The cost of rule enforcement must be balanced against business risks, and against business opportunities that might otherwise be lost.
8.4. More rules is not better. Usually fewer good rules is better.
8.5. An effective system can be based on a small number of rules. Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.
Article 9. Of, By, and For Business People, Not IT People
9.1. Rules should arise from knowledgeable business people.
9.2. Business people should have tools available to help them formulate, validate, and manage rules.
9.3. Business people should have tools available to help them verify business rules against each other for consistency.
Article 10. Managing Business Logic, Not Hardware/Software Platforms
10.1. Business rules are a vital business asset.
10.2. In the long run, rules are more important to the business than hardware/software platforms.
10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.
10.4. Rules, and the ability to change them effectively, are fundamental to improving business adaptability.
*Version 2.0, November 1, 2003. Edited by Ronald G. Ross.
Copyright, 2004. Business Rules Group.
Permission is granted for unlimited reproduction and distribution of this document under the following conditions: (a) The copyright and this permission notice are clearly included. (b) The work is clearly credited to the Business Rules Group. (c) No part of the document, including title, content, copyright, and permission notice, is altered, abridged, or extended in any manner.
Note: The original document is here: http://www.businessrulesgroup.org/brmanifesto.htm
We use this tool to document your business rules independent of any BRE - yet it can be implemented using any BRE. Again, this is a logical model of your business rules. It can be used as the rulebook or specs for authoring the rules in any BRE.
