The Community Blog for Business Analysts

Good points. Yes, they have to be taken care of even now but differently.

The focus of each use case is the "Business Service Goal and dialog (exchange of messages and data between the system and actor) necessary to reach it".

The business rules exist in the form of policies and conditions / actions / exceptions affecting setting up and operation of businesses. Some rules are external in the form of laws and regulations. Some are within the purview of the business organization. They have to be captured from organizational documentation / managers and applied to various UML Diagrams. The basic logic is the same as what was used in earlier methodologies and conventions.

The rules may be captured at inception and through ongoing interactions with identified actors. Then they should propagate to class diagrams, sequence diagrams and their contents (attributes, operations, messages etc).

I have felt a need to create an actor “Business Manager” to present the policies and rules to the system which contains an “internal rules repository & supplier”. Ideally rules should NOT be hardcoded into software but should flow from business manager as parameters and limits into objects. Business Rules Community (brcommunity.com) has well evolved methods to handles this.

[email protected]

Thanks for that. Might I ask then what is the form of a policy, a condition, an action, or an exception, if you were to write each of them down?

Would they all have clearly distinguishable forms of expression, such that one could look at a statement, and know immediately which one it was, or that it was clearly none of them?

Dear David Fletcher:

From ISO 9000:2005 definition of quality policy I take that policy on any subject is “Overall intentions and direction of an organization related to ABC as formally expressed by top management”. I consider this captures and presents the meaning and scope of “policy” precisely compared to dictionary meanings which spread out the scope and talk of other factors / parameters (decisions, actions and other matters) which are related to policy but not a part of it. “guiding principle” is also acceptable as the meaning of “policy”.


ISO 9001:2008 Quality Management System --- Requirements spells out how a policy, in this case ‘quality policy’, is defined and implemented. See sections 5.3, 5.4 and 5.5 and their subsections for one possible structure and content of a policy. It is possible that there are other sources which may deal with structure and content of a policy & its implementation but I found ISO 9001 well-developed and adoptable.

Policies, rules, and procedures are expressed in natural language text with some structure for humans to read / implement / manage.

It has to be more structured and precise (structured text or mini spec) for computerization or automation. Categories, conditions, exceptions, decisions and actions presented in the form of tables or spreadsheets (Ultimus1) serve as good examples. I also use predicate calculus and enhanced RDF for this purpose. I understand that ‘brcommunity.com’ has more information on the structure and content. I have not studied them yet.

As I said I am recommending Business Manager as default Actor of every “Business System” and “Business Rules Repository” in text and tabular form or enhanced RDF to define / manage any business automation system.

I note that you have observed some problems with “business rules”. I wish to understand the problems since I see the aforesaid structure and procedures actually use business rules to bring order to business automation. Let’s explore.

Best wishes,

[email protected] 20MAY11

Just a small remark on the topic: business rules had existed long before 80's. Any business adheres to them. All models are just a reflection of these rules.

Cheers,

Seo