The Business Rules Approach

Submitted by dwright on Tue, 2007-04-03 11:42.

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

» login or register to post comments | printer friendly version | 2958 reads

Rules and Use Cases

Submitted by julie.blake on Tue, 2007-04-03 19:56. *

Interesting article, thankyou.

I'm interesting in hearing how people who use use cases integrate these with business rules. We tend to use business rules as a support to use cases, describing complex validations or calculations where required. Many of the examples you give of business rules would be embedded in the use cases themselves and not articulated as a separate rule.

You also seem to suggest that business rules should be used to specify the configuration parameters for an off the shelf system. We have a separate document for this, and I'm wondering how you differentiate between rules that are configurable and those that aren't?

» login or register to post comments

Rules, Use Cases, and COTS

Submitted by dwright on Wed, 2007-04-04 14:19. *

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

» login or register to post comments

Apply the Right Artifact

Submitted by ScottWAmbler on Thu, 2007-04-05 11:43. *

Use cases are great for capturing usage, not so great for capturing business rules. BR specs are good at capturing BRs, not so good at capturing usage. You want to apply the artifact which is best suited for the task at hand.

At http://www.agilemodeling.com/artifacts/systemUseCase.htm#Figure1 I present an example of a formal use case. Several steps in the use case reference business rules which would be captured outside of the business case. This potentially increases the reusability and maintainability of the BRs.

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM
http://www-306.ibm.com/software/rational/bios/ambler.html

» login or register to post comments

Use cases

Submitted by larrygoldberg on Fri, 2007-04-06 11:39. *

Julie, we believe that business rules should be seperated from use cases because, among other reasons:
1. The same business rule typically occurs in multiple use cases
2. Many business rules change more frequently than the process represented by the use case

These are among the same reasons we seperate business rules from business process.

Our methodology uses an artifact called a decision to identify in each use case step where business rules are invoked, and we maintain business rules as a element within decision, which then becomes reusable (and easily related to business policy). This makes business rules manageable and an important business asset.

Because we trace rules to the underlying code (or application) we dont treat off the shelf system markedly differently to in-house systems. We do have a governance process that distinguishes buiness rules that we manage from those that do not have sufficient business value to manage. We generally identify those during the scoping part of our business rules methodology.

» login or register to post comments

Do not forget the domain model ...

Submitted by behret on Tue, 2007-04-10 02:29. *

Julie,

One additional comment about the integration of "business rules" and use cases.
Often business rules are associated with the domain objects you (or your use cases) deal with. The pure business rules approach suggests a fact model (the vocabulary). I tend to use a domain model as the vocabulary for the use cases, where I usually prefer to go beyond the fact model. I define the relationships and the cardinality there as well, which do represent business rules (e.g. a customer must have exactly one mobile phone).
This locates the business rule in the "right" place and avoids redundancy improving the structure of your specification.

HTH
- Thomas

» login or register to post comments

Domain/Data Model and Facts

Submitted by dwright on Tue, 2007-04-10 09:27. *

I agree, a Data/Domain Model and a Fact Model are very similar. Have a look at my previous article which covered how Rules integrate with other Artifacts:

http://www.requirementsnetwork.com/node/362
for
Integrating Business Analysis Artifacts for Information System Requirements

David Wright
Member, IIBA
"The Devil is in the Details." ...attribution unknown

» login or register to post comments

Where do Rules stop and Data Handling Conditions begin?

Submitted by KimberHM1 on Fri, 2007-04-06 13:11. *

I agree that you've presented an interesting article, the best bit is coupling Rules concepts with the ideas in the Zachman Framework.

Now, here's a struggle: Rules for an enterprise-wide, health insurance company include references to tabled data and the way that the system must deal with the data. The list of "rules" for handling 5 million subscriber's information are legion!

Where do "business rules" stop here when it comes to the conditional logic the code employs as it encounters data? I am encountering differing opinions.

IF AND patient is member of
THEN route call to [member skill group S]
ELSE GOTO [play benefit detail-msg]

These rules are changing constantly; they do not fit the "atomic" definition of a BR, and they are dynamic, based on the market, the contract, etc.

I look forward to others' replies.

~Kimber
Dallas, Tx

» login or register to post comments

IF/THEN/ELSE

Submitted by dwright on Mon, 2007-04-09 12:38. *

Kimber,

Based on what you have written, I would suggest that your example is not a Business Rule, per se. First off, conditional logic like that is not considered declarative, and routing would seem to be a factor of your Business Process, not Rules. Granted, a Business Process can change frequently, probably more frequently than Rules, whick speaks to the need for Business Process Management; just like Rules should not be embedded in your application code, neither should your Process.

Essential data management belongs to the Data portion of systems I discussed--> making sure keys are unique, that all mandatory fields have values,etc. (although some people treat these as Rules as well.)

So, in your example, membership in a set/domain is something your data system would be able to determine, after which your BPM system would determine what happens next and where.

Does that help?

David Wright
Member, IIBA
"The Devil is in the Details." ...attribution unknown

» login or register to post comments

User login

New forum topics

Recent blog posts

Upcoming events

The Business Rules Approach

Comment viewing options

Rules and Use Cases

Rules, Use Cases, and COTS

Apply the Right Artifact

Use cases

Do not forget the domain model ...

Domain/Data Model and Facts

Where do Rules stop and Data Handling Conditions begin?

IF/THEN/ELSE

Recent Articles

Partners

Recent comments

ARCHIVE MENU

Sponsored Announcements & Special Offers