Syndicated from ebizQ
Barb von Halle and Larry Goldberg had an interesting article titled Use Cases and Business Rules – can they work together over on Modern Analyst. In the article they discuss the role of the Decision Model and business rules in use cases.
They make some good points and I have a simple summary I would like to share for those who want to capture use cases and business rules during requirements gathering:
- Look for decisions in your use cases (see this post by a friend of mine on finding decision points and my follow-up on types of decisions).
- Make them explicit, describe them, understand what question/answer is at the heart of the decision (“Is this customer eligible?”,”What’s the right risk adjusted price for this product for this customer?”)
- Track but don’t embed the rules that drive them so you can trace from a use case to a decision to the rules that describe it
- Don’t list rules in the use case steps or in the description of the use case – let the decisions act as a layer of indirection
- Remember that business rules can be reused across decisions and that decisions can be reused across use cases.
You might also find this technique for decomposing decisions to be helpful.
I also wrote an article on the same site on the role of Decision Management in requirements.
Comments on this entry are closed.
Hi James, all good points. I think it also worth highlighting that you can turn the telescope around and look through the little end! Use cases should exist to support some decision making by the organization – it is the decision making that creates value. So hunting down these core decisions can be used to ferrit out use cases rather than the other way around – they are usually found in business policy documents, which are always a reassuring place to start. The good part is that you can model these decisions and get them right by testing them against the policy BEFORE doing the hard yards on use cases. If you cant get the decision making right, what value will the use case be? Better still, the decision making prescribes the use case in some detail in terms of data requirements and inferred process; the reverse is not true – a use case does not prescribe the decision making (other than, at best, indicating that a decision is required).
The other point worth noting is that when we refer to decision making in this context we are usually referring to a decision model as a model of decisions that are related to a single outcome a’la Alan Fish’s DRA or Idiom’s own more active model (also described on Modern Analyst, google ‘beast of complexity’), rather than a model of a decision as described by Barbara Van Halle and Larry Goldberg.
Regards,
Mark Norton, I like the idea here. By documenting decsions and when they are made can help to identify Use Cases. I think this is sometimes easier than starting with the Use Cases. The added benefit, as you point out, is that documenting decisions indirectly describes the data that’s needed too.