Defining Business Rules

Question

I have been tasked to come up with a list of the Business rules in one of our current applications. We have a very old document that has somethings, but has not been maintained, and as such is very outdated and inaccurate.

In an attempt to do it better than before, and hopefully more useful I have been asking fellow developers what types of things should be in the document and what they consider a business rule. And apparently we all have a different definition. I read over this wikipedia article, and it confused me more.

What we are trying to accomplish is:

• Complete list of business rules in our application to allow for easy review.
• A place to find and lookup these rules, when we are working on something related to it. That way over time when we forget what the rule is a screen is supposedly implementing, we can refer to this document.

Where I get confused is how specific should business rules be. How far do you go?

Example: A screen has two fields, A and B. A is a code and B is the definition of that code. They are stored in the database as a row in some table.

Business Rule 1: When user enters code in field A, field B is auto populated with the corresponding definition.

or

Business Rule 2: Every A code has a single corresponding B definition.

So which is more correct?

Answer 1

Suggestion:

Instead of saving the information inside a document which can outdate very quickly/easily I would suggest setting up a company wiki for maintaining the business rules.

Answer 2

Option 2) is more correct because it is independent of how the codes were entered. Your option 1) describes a user interface "nicety", whereas 2) establishes a system wide fact - that assersion should be true regardless if a user is entering or another system is entering data.

Answer 3

1. first and foremost, you must get whoever assigned you this task to define what he/she thinks is a "business rule"; otherwise you risk doing too much or not enough. What you listed as an example sounds like an application specification, not a list of business rules

2. the remainder of this is my opinion, which may or may not be relevant (see #1) ;-)

"rule 1" is a behavioral specification for the user-interface application, not a business rule. This could be done a different way without losing functionality, e.g. if the app had a droplist of code descriptions to choose from instead of entering a code

"rule 2" is a data model constraint, not a business rule

A business rule is a constraint for how the business operates that is distinct from a natural law, which governs how the world works. The distinction is that a natural law cannot change, while a business rule may change.

A business rule about codes would govern how the code is used in relation to whatever is being coded. For example, suppose the code described something about a customer account (big, fat, lazy, deadbeat, whatever) and that processing of an order varied depending on the code assigned to the account: the rules for processing based on each code would be business rules.

More examples:

• F=Ma (force equals mass times acceleration) is a natural law
• "new customers must have their PO orders approved by a credit manager" is a business rule
• "two objects cannot occupy the same space" is a natural law
• "a customer may only have two outstanding PO invoices at a time" is a business rule

Answer 4

How about "An A code alone is not completely descriptive. Every A code must be further defined by a B code."

If some A codes only allow a subset of B codes you'd have to define that as well.

Answer 5

Have you consider documenting Use Cases of your exiting apps?

Answer 6

I would like to add to the already clear (accepted) answer provided by Steven that

That way over time when we forget what the rule is a screen is supposedly implementing, we can refer to this document.

business rules as such are never implemented, they are -as Steven pointed out- constraints.

Screens do not implement business rules. Systems adhere to business rules.

The purpose of archiving an inventory of business rules is not to document the existing software, but instead to document fundamental knowledge that will enable to replace the whole system some 12 years from today. The new system probably won't have a screen just like yours...

Personally, I like to distinguish business rules and software requirements as explicitly as possible. One is non-negotiable, clear-cut fact. The other is open for discussion for scope and remains malleable to interpretation. Generally I see design documents specifying about 5-10 times more requirements than business rules. More complex domains have more business requirements, but the factor remains.

To adhere to all business rules is a 1 line requirement. To force system/user input to adhere to business rules requires explicit requirements.