Where to document business rules ?

[Mariano]

I would like to know which is best practice to document business rules.

Where in the tool should those business rules be documented ?

[thomaskilian]

See here http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1098039210;start=22#22 and here http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1093308726;start=1#1

[TrtnJohn]

Another alternative not described in these links is to draw a domain model.  A domain model is a class diagram that shows the high level components of the business as classes.  Each association between classes will have both source and target multiplicity and a name that describes the association.  

For example:  Bees[0..*]  ---- live in ----> [1]Hive.

Craig Larman has a excerpt from one of his books on his site that describe the Domain Model in details.  Here's a link if you are interested:

http://www.craiglarman.com/book_applying/domain%20model%201.pdf

[thomaskilian]

Another alternative not described in these links is to draw a domain model.  

Domain Modeling is essential in the step between requirements/use cases and class modeling. But IMHO it has nothing to do with business rules. You can find more about BR in these sources: http://www.businessrulesgroup.org/brghome.htm and http://xml.coverpages.org/brml.html or simply search the web for "business rules".

[TrtnJohn]

I think I understand a business rule.  But, where I get confused is why business modeling needs to be so different than systems modeling.  Why is there a need for new notations?  I realize no one will implement a business rule using a programming language.  But, I don't see why Use Cases, Domain Modeling, Interactive, and Logical Views don't apply.

[sargasso]

Consider the case of organisations that must comply with some regulationary body, act or constraint.  An Australian example is the FSRA - Financial Services reform Act - which amongst other things requires that any officer of the corporation (customer facing or otherwise) must understand how that act applies to them. This gives rise to the  folowing business rule:

BRxxx: An officer of the corporation shall be made aware of their duty requirements under the FSRA.

BRxxx: The corporation shall maintain a register of officers and their attendance at FSRA compliance training.

etc

These may give rise to enterprise requirements for one or more business and/or IT systems, each of which may have specific requirements and "system" rules.

BRM (at least the Finklestein/Zachmann/ etc version) is essentially about a formalised syntax for anaylsing and describing these rules.

Systems can then adopt/import/use these rules as necessary to design their implementations (which as I said above could be as a busines or technical system or part thereof).  

I actually find these (Zachman et al) formalised approaches a bit anal.  They are overkill in small/medium enterprises and impossible to maintain, manage and police in large enterprises.  However, (IMO) there is nothing wrong with  adopting their syntaxes (syntaxii?) to unambiguously describe a specific rule as it applies to a system.

In general I find these rules appear most often in E-P process models as requirements for the process.

bruce