Some Discussion of HPM
PP85 - 90
Business Rules. When working with databases, particularly when first designing them, it is very important that they have data that reflects how the business or organization really works.
This definitions are still somewhat vague and yet involved. So, as is usual, I will try to make sure I give plenty of examples to help people get much more sense about what these largely abstract statements are intending to say.
Some examples of business rules are
The book has some other examples.
The truth is, in their general sort of high minded somewhat abstract way I think HPM do a real nice job on this section. Though, I definitely want to hear your views. Professors can have their tendencies to choose books they like and not be all that good on choosing books that are the best for students.
But HPM states there are three main things you need to do as a business analyst.
I have plenty of experience trying to figure out the business rules of organizations. It can be one of the most challenging aspects of doing database, software, network and security development. In my mind and experience developing systems that help an organization much more effectively reach their goals is very important.
Now I'm trying to decide on which consulting experiences I want to focus other than those I'm already using as cases.
I worked on a client database system that was going to be housed on a small LAN within a medical testing facility. I was a subcontractor to someone who knew they guy who was running two such facilities in the Boston Massachusetts area. Trying to make sure the forms and tables underlying the forms were appropriately configured was probably the most difficult aspect of the work. Fortunately, using Access to quickly develop prototype forms that we could put in front of the owner and key users really helped the process. This way we could get constant feedback about what the eventual end users really wanted to see and how they wanted it laid out. As we were doing this we were able to develop more and more of the business rules.
Trying to get clients to come up with their own business rules really isn't particularly easy. When HPM describes surfacing business rules as a continually ongoing process I definitely agree them. This is even more difficult for an external consultant to do unless the organization has had some previous preparation and experience. I also like how they use the word surfacing, because it really is like they emerge in some sort of raw form from the psyche of those you are working with.
HPM goes on to reference Halle which states
Scope of Business Rules. We really do need to focus on business rules that impact an organization's databases. I like the little table HPM have in the book so I am summarizing it here.
|Declarative||A business rule is a statement of policy, not how it is enforced or conducted.|
|Precise||Each rule must have a clear and singular interpretation.|
|Atomic||The rule makes one statement, not several. No part of a rule can stand on its own as a rule.|
|Consistent||A business rule must not contradict other rules.|
|Expressible||A business rule must be able to be stated in natural language. Which I think is a bit extreme. Often times you really want to use mathematical formulations. For example, computing commissions on sales is something that will likely be better expressed in more mathematical terms.|
|Distinct||Each rule must not repeat another rule. But they may refer to each other.|
|Business Oriented||There need to be ways to state the rules in ways that people within the organization can understand. You want the businesses to take ownership of their business rules as they are stated.|
Business Rules. We've
already talked about this some.
But you never know when such rules will
surface. They might be in meeting
notes or human resource policy
statements or reports from data
collection sessions or interviews or
marketing brochures or ...
There needs to constant effort towards clarifying the rules and making them comprehensible.