The Business Rules Approach
by David Wright
“The biggest risk to your company is not being able to change fast enough… Business Rules are the answer.” …Ron Ross
I am a great appreciator of Mr. Ross. He has written extensively on the topic of Business Rules, offers excellent training on the subject, and is the keynote speaker at each year’s International Business Rules Forum. I would like to start my own article on Business Rules with an ‘icebreaker’ he used on a seminar I attended.
| Attachment | Size |
|---|---|
| The Business Rules Approach.pdf | 165.55 KB |
Rules, Use Cases, and COTS
Hi Julie,
As you might expect, I would avoid embedding Rules in Use Cases, as that could tend to implementing the Rules in code. So, I document them separately, and reference them in a Use Case as needed; this is also an advantage when the Rule is used in multiple Use Cases. There is some debate about how Rules should be referenced: should they be named? should they be numbered or otherwise identified? I have used both methods, just as long as I can reference them.
One particular aspect of Rules in Use Cases I have found is that they are often invoked when determining if the main or an alternate path is to be followed.
As for configuring COTS, Business Rules exist in of themselves, however they are implemented, so they can all be documented the same way. You could/would do this before you know if a COTS product, or which one, is going to be used for your solution.
David Wright
Member, IIBA
"The Devil is in the Details." ...attribution unknown