David:
Further clarification: by Data Dictionary, I mean a Logical data dictionary. Logical data dictionaries are totally, 100% implementation independent. Now, there are other data dictionaries that are implementation (e.g., database) oriented, but those are developer artifiacts - not business analysis artifacts. These other dictionaries are often called Physical data dictionaries.
The way things are supporsed to work is that the BA creates a business oriented logical data dictionary, and then the developer using such as an input to creating the physical data dictionary. But, often, projects just focus on an implementation oriented dictionary.
Tony
Well, time to clarify terms. When I say "system", I mean an information system. I would still like to hear your views on business rule methods.
Information system sounds "computery" to me. A bunch of people working at a company, with only pencils and paper - zero, nada one computer, can be an information system.
Regarding the term "system", the whole BA career field runs on false partitioning (i.e., false division of tasks and terminology). Exmaple, per the BABOK: data flow diagrams are for analysis of system requirements and business process modeling is for analysis of business requirements. Totally popular, totally twisted. This is tragic as, analysis, especially analysis of business systems, IS largely all about effective partitioning (decomposition).
Regarding business rules, they are system behavior to a more detailed level. Once a complex business system (manual/automated, or a combo thereof) is properly decomposed to smallish, equal size pieces of minimum coupling and maximum cohesion, then business rule discovery can commence per piece (i.e., process/task/function). How business rule documentation occures,can vary. The main point is for a BA to not make the mistake of starting with a bottom up approach on a complex business system, as such approaches, by their nature derail effective decomposition.
low coupling, high cohesion... takes me back 30 years... still a good basis for an information system design architecture.
So, what about rules that impact multiple pieces? Do you define them multiple times, or define them once outside the piece and cross-reference each rule to all the pieces? Certainly the second way makes for less volume and much easier impact analysis when rules change, because rules change a lot in response to what is happening in or to the business.
What about new rules that come from outside the business? like new laws and regulations? how do you determine the pieces that are impacted?
AAAaaaahhhh..... impact across multiple [system] pieces. This (along with ..... tremble..... decomposition) is a forbidden topic amongst BA's!
Proper handling of rules across pieces [of the system] is through proper partitioning, through as many levels of abstraction as needed, to minimize data flow between the pieces. With a farily common five levels of decomposition for a business system (I have often gone alot deeper than this), there simply is no other way to reach the final goal of smallish, loosley coupled, cohesive approx equal size pieces, needed to really address the issue.
When there are still impact between pieces issues, then any of your alternatives could come into play. And there will always be such issues. But, a genuine effort to first logically partition/decompose will result in a much better result than the typically force fit attempts at business rule intergration.
New laws and new regulations require new processes (with interfaces to existing processes) to handle them. So the scope of the info system expands. What would I do? Create a new Context Diagram, then decompose it downward with data flow diagrams until I have the right pieces again.
brought to you by enabling practitioners & organizations to achieve their goals using: