JT on EDM

An email acquaintance who works with business rules at a large European financial institution sent me an interesting question today. In it he said

I think that some degree of redundancy between UCs[Use Cases] and BRs[Business Rules] are needed, because if all BRs are extracted from the UCs (and not shown there anymore) it would become very hard to understand the UCs and to get them accepted by the business people.

I think this is the key reason I prefer to talk about embedding decisions in use cases rather than rules. A decision is pretty easy for a business user to understand and the list of business rules that must be followed to make the decision can be externalized and referenced fairly easily. For instance, you might identify a decision in a use case like “approve loan” or “select cross-sell offer” and might identify that these things are driven by a collection of rules. The use case is still perfectly clear, even though the rules are externalized.

If you just try and reference rules from steps I agree you might have a challenge but even then I am not sure I would use redundant information to solve the problem. Instead I might use descriptive names for business rules/policies or better yet for a group of rules/policies and still refer to them. The details would be elsewhere but the use case would be clear. For instance, a use case step might talk about the rules to be followed in the user interface but want to externalize them. You could group the rules into “Website accessability rules” in the rule catalog while using the group name in the use case. Again, the use case is clear without having redundant business rules information.

I have started building out an entry on business rules and requirements on the wiki and your input is welcome there as elsewhere in the wiki.

Technorati Tags: business rules, requirements, question, use cases