Use Cases and Business Rules: Can They Work Together?

(This article assumes knowledge of the Decision Model. If you are not already familiar with the theory of the Decision Model, you can download a brief primer from You can order the book here including a Kindle version)

Portions of this article are drawn from the book, The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, © 2009 Auerbach Publications/Taylor & Francis, LLC. This article consists, in part, of abstracts from the book; directly quoted passages, diagrams, and tables are cited, and are copyright © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.

Use Cases and Business RulesThere is much written today about separating business rules from other dimensions of automated business systems. Without proper separation, they operate in enterprises without a great deal of thought given to them. Ironically, they may be the most important dimension because they represent important business thinking behind processes, use cases, for example.

This article discusses various approaches for dealing with business rules and use cases. We begin with three important questions.

Question #1: Why Separate Business Rules?
The primary benefit to separating them is to manage them separately. If we separate them properly, we can:

  • Make changes in one with minimal impact on the other. This is desirable because business rules often change more frequently than do use cases.

  • Share business rules across many use cases.

  • Define, analyze, and test business rules prior to, or in parallel with, development of use cases.

  • Iterate between use case development and business rule capture.

  • Involve different business people in use case development versus business rule capture, as appropriate.

Question #2: How to Separate Business Rules?

To separate business rules from use cases, they must be different. The good news is that business rules and use cases are fundamentally different considerations. Use cases are primarily about actor interactions. Business rules are about reasoning and logic.

The second way is to pull them out of the use case altogether. We accomplish this by providing pointers to them in a business rule repository.

Both approaches separate them from the major emphasis of the use case, actor interactions. Therefore, both approaches simplify the use case because the use case reduces essentially to the flow of actor interactions, not distracted by business rule logic. Approaches 1-4 in this article accomplish such separation. Each approach does so better than the one before it.

However, separating business rules is not the same as promoting them to a new dimension in their own right. This idea is worth contemplating.

Question #3: How to Promote Business Rules to a New Dimension?
To promote business rules to a new dimension, they must not only be different from other dimensions, they must have their own existence, independent of how and where executed, and whether automated or not. The combination of their own existence and independence means we should be able to cast them in their own model that is recognizably different (in structure and behavior) from all other kinds of models. If not, we can only separate them, not promote them higher.

Approach 5 in this article delivers business rules as a new dimension.

The approaches below do not address ways to express business rules nor do they recommend specific use case templates. Instead, a simple example, informal business rule expressions and a basic use case template will suffice.

Buried Business Rules

Once upon a time, use cases had no notion of business rules. Use case templates contained places for pre-conditions, post-conditions, basic and alternate flows, but nothing for business rules. So, the business rules, if anywhere, were buried in the use case flow. See Figure 1.

Figure 1: Use Case without a Place for Business Rule Statements (so business rules are buried)

Approach 1: Dangling Business Rules
Approach 1 is an improvement because it contains a place for business rule statements usually at the bottom of a use case template. They are no longer lost, but are dangling and unconnected. See Figure 2

Figure 2: Use Case with Business Rule Statements at the Bottom (so business rules are dangling)

Nevertheless, there are three advantages to Approach 1:

  • It separates business rules by giving them their own section in the use case template.

  • It simplifies use case flow to include only actor interactions, devoid of business rule logic.

  • It accelerates use case development because we can add business rules later as we discover them.

However, Approach 1 has three disadvantages:

  • It leaves unclear which business rules execute in which steps.

  • It forces business rule changes in the use case. That is, to change a business rule, we must do so in every use case referencing it.

  • Despite separated within the use case, business rules do not emerge as anything outside the use case.

Approach 2: Positioned Business Rules
Approach 2 offers a use case template in which business rule statements connect to use case steps. Therefore, the business rules are positioned within the use case flow. See Figure 3.

Figure 3: Use case with Business Rule Statements within Use Case Steps (so business rules are positioned where needed)

Approach 2 has the same advantages as Approach 1, with one additional advantage:

  • It makes clear which business rules are executed in which steps.

However, Approach 2 still has two disadvantages:

  • It still forces business rule changes in the use case. Here, to change a business rule, we must change it in every use case step referencing it.

  • Business rules still do not emerge as anything outside the use case.

Approach 3: Anchored Business Rules
Approach 3 uses a use case template that associates a use case step with a business rule identifier. The identifier points to the business rule statement in a business rule repository. Therefore, the use case template anchors the business rules to the use case steps, but the business rules themselves are elsewhere. See Figure 4.

Figure 4: Use Case with Business Rule Identifiers within Use Case Steps (so business rules are anchored to a business rule repository)

Approach 3 has three advantages:

  • It establishes business rules as a deliverable outside the use case, encouraging business rule sharing.

  • The business rule repository can include metadata about them, such as effective and expiration dates, version, and stewards.

  • It removes business rule changes from use cases. To change a business rule, we change it in the business rule repository without changes to use cases.

However, Approach 3 has one disadvantage:

  • It forces us to make changes in the use case when we need to change membership of groups of business rules. That’s because Approach 4 deals only with individual business rules, not with groups.

Approach 4: Grouped Business Rules
Approach 4 associates a use case step with a collection of business rules, grouped in a meaningful way. We can create collections of business rules in many ways. However, the most popular collection of business rules (and somewhat disciplined) is a decision table. Let’s use a decision table as an example for Approach 4.







1. Candidate Initial Interview Rating

= 5





2. Candidate Compensation Expectation






3. Candidate Personality Rating






4. Candidate Cognitive Rating












1. Candidate Ranking






2. Candidate Culture Fit






3. Make Job Offer to Candidate






Figure 5: Typical Decision Table

The decision table Figure 5 is a collection of five business rules, numbered 1 through 5. They evaluate some or all of its four conditions to arrive at its three actions. In Approach 4, an entire decision table has an identifier which is associated with relevant use case steps as seen in Figure 6.

Figure 6: Use Case with Decision Table Identifier within Use Case Steps (business rules are grouped)

Approach 4 has four advantages:

  • It removes changes in individual and collections of business rules from the use case. That is, we make these changes only in the decision table (or other grouping) in a business rule repository, with no corresponding changes in use cases.

  • It is a format easily understood by business audiences.

  • Its format is easy to analyze and validate a collection of business rules.

  • It establishes the decision table (or other grouping) as a separate deliverable outside the use case.

Today Approach 4 is the most common practice due to its advantages. However, there are two disadvantages.

  • While the decision table in Figure 5 is simple, many are more complex. If their logic includes Ors among conditions, ELSE’s or OTHERWISE among conclusions, the decision table resembles program code, difficult for business people to validate or analyze.

  • A more subtle disadvantage is the execution of several decision tables within a use case step. Should the use case list them? Should it separate them into more than one step even if their execution happens on behalf of one actor interaction? Does the use case include or point to a process flow among them? How much of this is design and not appropriate for a use case?

Approach 5: Modeled Business Rules
Let’s consider a similar goal and its solution from the past.

Almost 50 years ago, there was a desire to separate data from process. This separation started by identifying individual data elements, grouping them into logical collections, storing them in data dictionaries, and connecting them to processes. However, this failed to achieve anticipated benefits. Specifically, separation alone did not deliver on the promise!

“Success came with the introduction of a model for data that was different from existing models….that model for data changed forever the way the world thinks about, manages and leverages data stored in databases.” One reason for the endurance of the Relational Model is that it is based only on the inherent nature of data itself, and nothing more.

Approach 5 takes that leap again. It goes beyond lists and groupings of business rules and delivers a model that is uniquely different from others. “It is a model that addresses an important unsolved problem: how to effectively manage business logic and rules, not as lists or annotations attached to or buried in other models, but in a model of their own.” The Decision Model is neither a language nor a grammar; it is a new, disciplined model.

Therefore, Approach 5 associates a use case step with a business decision – something bigger in importance than individual or collections of business rules, but driven by them. See Figure 7.

Figure 7: Use Case with Decisions within Use Case Steps (so business rules are modeled)

The business decision is the anchor point for a structural model comprised only of business rules and called a Decision Model. The Decision Model for Decision #16 is in Figure 8 and contains two Rule Families connected with an inferential relationship.

Figure 8: Decision Model with One Populated Rule Family.

The advantages of Approach 5 are significant because they come from managing a model, not lists or groups. Advantages are:

  • Represents business rule logic in its most atomic form and with inherent connections

  • Enables sharing of entire Decision Models

  • Supports a step-by-step iterative development of business rules in a model (at various levels of detail for different purposes)

  • Removes all business rule changes from use cases (and other models) because all changes in an entire Decision Model happen in one place without corresponding changes elsewhere.

  • Solidifies the natural boundary between procedural use case steps and declarative business rules

  • Enables visual impact analysis across entire Decision Models

  • Delivers a representation understandable by business and I/T and amenable to automation

  • Serves as the foundation for building Decision Model views (customizations of whole models for specific geographical, political, or business requirements)

  • Has proven in practice to be faster to develop and implement than any of the other options.


Use cases and business rules definitely work together. Because they represent fundamentally different considerations, you can choose the optimum way to separate them.

But, if you believe that business rules have their own existence, independent of how and where executed, and whether automated or not, then you must cast them in their own model. Otherwise, you miss the opportunity to promote them to a higher, more visible, more valuable and agile business asset. It is easier than you might think.

Authors: Barbara von Halle and Larry Goldberg of Knowledge Partners International, LLC (KPI)

Larry Goldberg is Managing Partner of Knowledge Partners International, LLC (KPI), has over thirty years of experience in building technology based companies on three continents, and in which the focus was rules-based technologies and applications. Commercial applications in which he played a primary architectural role include such diverse domains as healthcare, supply chain, and property & casualty insurance.

Barbara von Halle is Managing Partner of Knowledge Partners International, LLC (KPI). She is co-inventor of the Decision Model and co-author of The Decision Model: A Business Logic Framework Linking Business and Technology published by Auerbach Publications/Taylor and Francis LLC 2009.
Larry and Barb can be found at

1Rule Families are similar to decision tables but with more rigor. This Decision Model is incomplete. It is missing at least three Rule Families, maybe more, as indicated by the positions of fact types above the dotted lines.

posted @ Tuesday, July 20, 2010 7:15 AM by speeditonline