« Business rules, flexibility and rigor | Main | Business rules or decision management or what? »

Use Cases, UML Statecharts and business rules

Interesting post over on the Tyner Blain blog Use Case vs. UML Statechart - Business Rules. This post does a good job of differentiating between use cases and UML statecharts with a view to finding the business rules. Of course, it goes without saying that I think the business rules should be managed as first-class objects in some kind of rule repository, even at the requirements gathering stage, not embedded in the notes attached to either diagram (the post does not make their position clear on this).

Technorati Tags: , , , , , ,

First time on the EDM blog?
Subscribe to the EDM blog feed or check out some other recent posts:


TrackBack URL for this entry:

Listed below are links to weblogs that reference Use Cases, UML Statecharts and business rules:


Scott Sehlhorst

Thanks James for the shout-out.

I purposefully avoided both "how to document" and "are rules peers or subordinates of requirements" issues, in order to stay on-topic.

My intuition on rules v requirements is that they are peers, usually with different rates of churn. Depending on the industry. With my BA hat on, I see that process re-engineering can change rules, without changing requirements. Strategic focus shifts can change requirements (and rules) together.

When I put my product management hat on, I see requirements as generalizations that abstract the needs of a market. I see rules as customer-specific artifacts that represent the intersection of those requirements with the customer-specific process implementations.

Some people seem to encourage rules as subordinates of requirements based on the above. They might be right, I don't know yet. I promise to talk about it when I form a stronger opinion about it. I've comfortably dodged the issue to date by making sure I identify both as a BA, and focus on a requirements as a ProdMgr.

The goal of the article you reference is purely an analysis of the different models for exploration of a given requirements space. While I did touch on "how to communicate", I avoided "how to document" because it is a bigger issue. I wanted to contrast the uses of the two models - since I haven't really read anything along those lines before, and I think the power of having a bunch of tools is knowing which one to use for the right job.

The comments to this entry are closed.

Search Site



  • enter your email

Upcoming Events

  • FICO Tools & Analytics User Forum 2012
    BERLIN: September 11-12, 2012 LONDON: September 18-19, 2012 Gain new insights for improving business performance through advanced analytics and decision management tools.