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
Comments on this entry are closed.
When I think of the relation of rules and use cases, what I find is that use cases have internal decision points, that when a scenario is run the decision must be made if the normal path or an alternative path should be taken. I have found that real business rules usually form the basis for this path decision.
Overall, relating the two is about how you name things and cross-reference them. Use Case’s will have recognizable phrase names, but naming rules is not so straightforward. Some people don’t like to name them, but I have used Barbara van Halle’s naming method, and used those names to xref from their use in a Use Case to where the rule is separately captured/managed.
Now, when you have hundreds/thousands of rules (a volume level I have not worked with yet), I don’t know if names like “Minimum Age Constraint” will work. I also know you will start to group rules into rule sets (perhaps better to be called Decision Sets?) which I think you would have to name.
What has been your experience in managing large numbers of rules?
Me again.
Do you know Tom Debevoise? he is blogging on this topic today as well, from a BPM perspective.
http://www.tomdebevoise.com/blog/