Business Analyst Community & Resources | Modern Analyst

Use Cases and Business Rules: Can They Work Together?

Featured

126737 Views

28 Comments

51 Likes

(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 www.TheDecisionModel.com. 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 Rules There 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.

Conditions	1	2	3	4	5
1. Candidate Initial Interview Rating	= 5	<3		<3	<=3
2. Candidate Compensation Expectation		aligned	aligned	aligned
3. Candidate Personality Rating	Excellent	good	good	excellent
4. Candidate Cognitive Rating	Excellent	excellent	excellent	average
Actions
1. Candidate Ranking	1	2	3	4	5
2. Candidate Culture Fit	Yes	Yes	Yes	No	no
3. Make Job Offer to Candidate	Yes	Yes	Maybe	No	no

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.

Summary

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 www.TheDecisionModel.com.

¹Rule 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 in: Unified Modeling Language (UML), Use Cases, Business Rules, Decision Management

51 members liked this article

Featured

126737 Views

28 Comments

51 Likes

Use Cases: The Business Analyst’s Best Friend

When Use Cases Aren’t Enough: Event Analysis

Parking Consternations: Rules, Rules, Rules

AI & Citizen Development: Fueling Business Transformation beyond Cost Cutting

COMMENTS

zarfman posted on Friday, August 13, 2010 7:38 PM

Hi:

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

zarfman writes: Can you recommend any publications or other sources that can teach me how to choose the optimum way?

Regards,

zarfman

Marc Thibault posted on Saturday, August 14, 2010 11:57 AM

You could improve this by fixing two problems:

First, present the use cases with use case interactions, not system workflows. Your "use case" is really a functional spec.

Second, your "business rules" are in fact preconditions; they need to be true for the use case to succeed--quite possibly this use case alone. You need better examples.

Barbara von Halle posted on Monday, August 23, 2010 3:14 PM

To Zarfman: Thank you for your question. We use BPMN to represent process and siimple scenarios to represent the flow of use cases. We always use the Decision Model to represent business rules because they are not about flow, but about logic/thinking.

It turns out, when looked at it that way, business rules are as different from use cases as data is because business rules and data are declarative, not procedural. Use cases (and business processes) are procedural, all about sequence.

Ours is the only book (so far!) that provides a formal model for representing busienss rules as they relate to an entire holistic decision. A holistic decision is usually more than one Rule Family (i.e., disciiplined decision table). So, the model we present is what we use, just like people use a relational-like model to represent a holistic perspective of data.

If you want to learn more about the Decision Model notation, our book is the only reference so far. Also, we will continue to explain it in Modern Analyst (and we are presenting it at various conferences in the next few months).

Did I answer your question?

Barbara von Halle posted on Monday, August 23, 2010 3:24 PM

To Marcthibault,

You are so right that we need better examples!!! Thank you for pointing that out. In an effort to keep it simple, perhaps the value of the representation is lost.

To your second point that business rules are pre-conditions, that is only a small part of the story. In any business process or use case, pre-conditions are tested so that the use case kicks off under proper circumstances. But there are many many "business rules" that are not pre-conditions at all, but are part of the "meat" of a use case because these are how the use case makes "business decisions". Let me give hopefully a better example than in the article.

Suppose there is a use case for determining whether a loan applicant is to be granted a particular loan. And suppose prior to that decision, there are pre-conditions about the data the applicant has provided. Once those pre-conditions are met, the use case may execute many separate decisions in order to conclude whether the applicant should be granted the requested loan.

One decision may be whether the Applicant's credit score is acceptable to the lending institution. There may be many rules about this based on the kind of loan, the amount of the loan, the payout period of the loan, and so forth. These may form an entire Decision Model (maybe 4-8 Rule Families connected together).

Another decision may be whether the Applicant has enough skin in the game. If the loan is a mortgage, the decisione may evaluate the value of the property versus the value of the loan and also include specifics related to different geographical regions. These may form an entire Decision Model (maybe another 4-8 Rule Families connected together).

Does this help? These are not pre-conditions, but are criteria to test in order to reach a business judgment (and those criteria need to change quickly due to market movement or catastrophic events, etc).

zarfman posted on Monday, August 23, 2010 4:20 PM

Ms. Von Halle

Zarfman writes: No you did not answer my question. My question is about optimality.

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

zarfman writes: specifically, by what means does one choose or determine the optimum way relative to separation use cases and business rules. Moreover, how does one prove the choice is optimal?

Zarfman writes: To me optimization requires the use of algorithms. These algorithms solve constrained and unconstrained continuous and discrete problems. these algorithms include functions for linear programming, quadratic programming, binary integer programming, nonlinear optimization, nonlinear least squares, systems of nonlinear equations, and multi-objective optimization. You can use them to find optimal solutions, perform trade off analysis, balance multiple design alternatives, and incorporate these optimization methods into other algorithms and models.

Marcthibault suggested better examples. I suggest FASB 157

Regards,

Zarfman

Marc Thibault posted on Monday, August 23, 2010 4:20 PM

I didn't say that business rules were preconditions. I said _those_ business rules were preconditions. On the other hand, there is an argument for the more general case.

I can't comment much on your example because you've put it in functional specification terms, not use case terms (Not unusual; functional specs are hard-coded into many analysts' viscera).

What I see are preconditions, what you see are flow charts. Use cases are known by the actor's goal. The use case isn't "Determine whether ..." It's "Get a Mortgage"; use cases are driven by ambition.

If the applicant's credit score is unacceptable, the use case will fail. That makes it a precondition. The algorithm for computing credit score is a business rule.

In not confusing a functional spec for a use case, the order in which success and failure conditions are tested is not material to a use case. A precondition is any factor that's required to successfully enact the use case. The "happy scenario" assumes that all the preconditions have been met and doesn't test for them. That's an implementation detail you leave up to the designers or programmers.

You may think it's not possible to test for a specific precondition until you are part way through the use case, but it remains a precondition. The programmer may be smarter than you.

The preconditions are a list of non-obvious statements that must be true for the use case to succeed. Some of them will be "this business rule has not been violated."

As much as possible, the designer will do what he can to prevent a use case from starting if the preconditions aren't met (you don't let someone start a process you know they can't complete), but that's clearly not always doable. A good designer will front-load the tests to minimize waste of the user's time. But that's design, not requirements.

Anyway, I've never met a business rule that was both relevant and not at least part of a precondition for some use case for some system. I've seen lots of design decisions masquerading as business rules, but they don't count.

Barbara von Halle posted on Tuesday, August 24, 2010 9:20 AM

For Zarfman:

I am sorry for not answering your question. But, I know why, and that is a disconnect in the intended meaning of the word "optimal."

Our work with business rules, Decision Models, use cases is done with business analysts and business SMEs (yes, we even have pure business people, like credit experts, who are not BAs creating Decision Models and "writing rules"). Wit that in mind, our intended meaning of the word "optimal" is as follows:

- business SMEs can understand the business rules/logic, correct it, analyze it, and sometimes even create it
- business SMEss are able to instigate and make changes to it with a quick-time-to-automation (agility)
- I/T is able to quickly automate the business rules/logic in that form or to generate the automation from it.

So, in our projects, these are the goals for optimum representation of business rules/logic that sit behind business-critical decisions behind use cases and processes.

Your insights into optimal design are excellent and valuable. So, they can be applied in the use case/BR/DM process also, but I see them happening after the business people are sure the rules are as they want or need them to be.

If you want more information, there is a public presentation given by a financial instute to MIT last month:

http://mitiq.mit.edu/IQIS/2010/FinTrack/IQIS10%203D%20-%20Pettit2.pdf

Barbara von Halle posted on Tuesday, August 24, 2010 9:28 AM

For marcthibault,

Again you are correct that the very simple business rules in the article would be considered pre-conditions by most.

Also, thank you for your clarification of my "Determine Whether an Applicant is Granted a Loan" is not a use case. My error. What we usually do is create business process models for decision-aware processes and then define use cases or scenarios and Visualizations on top of that. So, I stand corrected in that I worded it as if it were a "decision" or a "process" but not necessarily a use case.

Be that as it may, we are finding that in doing business process models, use cases, and business rules that the notion of a Decision Model (managed by business analysts or actual business people) is valuable because the same Decision Models are shared across use cases and across many business process models and systems. So, this elevates them to something of larger business value to business people, they actually see them as a new business asset (more business-centric than the idea of pre-conditions, although related). We are able to share and change Decision Models with less effort than otherwise.

Another realizatioin is that entire Decision Models can be shared (or even made mandatory) among different companies when those models have to do with regulations. The Decision Models can be the same but each company can build its own software (business processes, use cases, systems) around them. I think that is a realistic near future based on what we have seen.

Regardless, the sharing of decision models across use cases, processes, systems, and organizational boundaries streamlines adherence to the logic and also enhances proper governance for it because it is seen as a business asset and larger-grained deliverable At least that has been our experience to date.

As i indicated above, you can learn more at a recent presentation given to MIT last month:

http://mitiq.mit.edu/IQIS/2010/FinTrack/IQIS10%203D%20-%20Pettit2.pdf

Marc Thibault posted on Tuesday, August 24, 2010 8:04 PM

Ah--

The Decision Models are independent of the applications that put them to use and constitute a system (or system component), complete with use cases ideally named as and driven by questions. The actor's ambition is to have the question answered.

Depending on the level of automation involved, the actor is an anonymous software application or its programmer, not the application user.

The Decision Models are independent of application use cases, but not vice-versa. The link is application use case preconditions that are satisfied, or not, by enacting Decision Model use cases.

As is sometimes effective, the precondition might be turned into an "includes", perhaps named "Am I Credit-Worthy?" in this example.

Barbara von Halle posted on Wednesday, August 25, 2010 8:55 AM

To marcthibault,

Yes, yes! In fact, in some cases, clients implement an entire Decision Model as a decision service callable by anything that needs the answer to the decision's question! This is the technical perspective.

However, from the actual application user, the Decision Model is still visible (via looking at it in a repository) or also seeing the error messages that it generates.

A positive is that we can write use cases (or simulate them using Visualization software) without necessarily knowing all of the business rules up front. We can have a skeletal decision model in place and even an object model and fill it in iteratively until we get it right. We can also test decision models independently of broader testing which is turning out to be a tremendous boost to the testing approach.

Your comment about use case pre-conditions is intereting. We have wrestled with the pre-conditions involved with data quality (completeness of data, reasonableness of data values, and relationships among pieces of data) and have recently separated those from "business" decsion models. The DQ decision models are governed by data stewards while the "business" Decision Models are governed by other people (credit managers, etc). That way, we can share DQ logic across Decision Models and use cases, etc.

We have also created specific Views of Decision Models (much like a view in a relational database). So, we can have an "inclues of "Am I Credit-Worthy" and we can have a different View of the logic for each state, or each industry, or specific special customers, etc. This has turned out to simplify the management of corresponding business rules.

I think it would be worthwhile to explore use of the Decision Model and use cases in more detail with real-world examples (anonymous examples). If you (or any other readers) want to co-author something on this, that could be very useful!

Can i ask you two questions. Do you typically do an overall business process model for context and then define use cases on top of that? Have you done software visualization as part of requirements elicitation and if so, does that change the way you do use cases or does it solidify them and you still document them as fully as before?

zarfman posted on Wednesday, August 25, 2010 8:45 PM

Ms. Von Halle

Thanks for your definition of optimal; I have a better understanding of what you mean when you say something is optimal. I don’t agree with your definition, but such is life.

I checked out the Freddie Mac presentation at MIT as you suggested. Freddie Mac is a farce and so is Freddie Mae. Both entities were seized by the government because they were financial disasters bleeding millions in loses. Now the Treasury department has to figure out what to do with them. The shareholders aren’t too happy either.

I see your firm is involved in some manner – Congratulations.

If you want to tackle a real world example, try FASB 157.

Regards,

Zarfman

Marc Thibault posted on Wednesday, August 25, 2010 9:41 PM

Barbara:

Business model: always. The software exists to support a business process. Without a clear linkage to the business, the rationale for the software and the best arbiter of conflicts is lost. I do skeletal business use cases for the parts of the process that will be supported by the software, along with an informal presentation of the associations between business and system use cases. This part is about justifying the system use cases, not architecture.

For example, on a border services system project, the two business use cases were "Enter Canada" and "Bring Goods into Canada." You can see how that would color the system use case design.

Software visualization is also an integral part of the requirements deliverable. I like to use storyboards so I don't get bogged down by what color a button should be, and high level object models to pin down the key user-visible information. I document everything as fully as I can.

The idea is to have as many views as are necessary to make sure that no one can possibly misunderstand what has to be built. In that respect, if I've worn out everybody's patience with my questions and requests for feedback on the various artefacts, I consider it a job well done.

I have a blurb on use cases at http://smpro.ca/nb/usecases.html

Barbara von Halle posted on Thursday, August 26, 2010 2:58 PM

Marc,

Thank you for you explanations. I also read your blurb on use cases and I like it very much!!!

Do you have any favorite software tools for your uses cases and Visualization?

Barb

Marc Thibault posted on Thursday, August 26, 2010 6:13 PM

Barb:

My normal tool is Word with embedded Visio diagrams and Excel tables.

I'll also have a "sketchbook" Visio file with many pages of pictures with heavy commenting (something like a graphic novel.) Visio is where I do the real work, Word is for presentation to stakeholders.

And then there's the client's thousands-of-dollars-per-seat Suite. The two I've used most are the RUP suite and Visual Architect/Paradigm. I still do the work in Visio, but I transfer it to the client's tool of choice when I'm happy with it.

The irony is that no one, not even the programmers, use the Suite output. The programmers take the use cases and my drawings and code from that. Without the automation straight jacket, my diagrams are easier to use.

Barbara von Halle posted on Friday, August 27, 2010 10:34 AM

Marc,

Your message made me smile. I think your experience is shared by many. We do most of our business process models and decision models today with Visio (we have a visio plug-in for the Decision Model notation) and we use excel for our RF tables, linking them to the visio diagrams. (That said, I am looking forwar to upcoming Decision Modeling software - we just announced a software partnership in a press release yesterday with eDev for that).

We also have found that many (large) companies don't have a requirements software tool or aren't really using the one thay have.

I have one more question for you (do you have the patience for one more)?

What do you do with business rules? I am guessing that you don't put them into your use cases, but treat them as a separate functional requirement because, per your first comment, a use case aims for a goal, not for the answer to a specific set of business rules? Where and how do you store them? Or maybe they become a design artifact (which is also common practice, I didn't have that option in my article, I guess I don't like that option LOL!)

Barb

Marc Thibault posted on Friday, August 27, 2010 2:39 PM

Barb,

That's not a small question. It would be easier if we called them "policy statements" instead of "business rules"; it would put them in proper perspective.

The other part of the problem is that some business rules are preconditions and some preconditions are business rules, but not all.

In any case, I record them all. If some stakeholder can express a constraint unambiguously and no one objects, it's a business rule. We used to say that a mini-computer is a computer whose maker calls it a minicomputer; a business rule is a rule the client calls a business rule.

How I use that rule in the requirements statement is a whole nuther thang.

My discriminator is that failing a precondition means failing the use case; if it's possible to recover, it's not a precondition--it's an alternative scenario trigger.

Consider: "A property-secured credit line may not exceed 80% of the current property value." That's not a precondition, because the applicant can opt for a smaller credit line than their original request.

I include in the use-case, as preconditions, those business rules that impact the success or failure of the use case from the actor's perspective. Whether a precondition violation is discovered before the use case is enacted, or during, is immaterial.

Also keep in mind that business rules, if they are indeed business rules, will first appear in business use cases. The system use cases supporting the business use cases get them second-hand and possibly specialized.

Cheers

Marc Thibault posted on Friday, August 27, 2010 4:21 PM

Barb,

Another thought. How will you know?

This applies to both post-conditions and would-be business rules. How will you know whether they've been satisfied?

If there isn't a use case that spills the beans, it doesn't matter what you call it because no one will ever know that you've ignored it.

Barbara von Halle posted on Tuesday, August 31, 2010 2:50 PM

I think i agree with most of what you said. I wouldn't, however, consider business rules or even policy statements to be something that should be "included in a use case" at all, but as something separate (in a Decision Model, of course) that the use case points to. And also, the surrounding business process also points to.

We tend to do business process models first and identify the list of decisions needing logic/rules (like credit score compliance, for example). We may create a whole decision model for important decisions even before we do use cases, especially if these are decisions that may seriously impact the business and if we know what the policies ought to be (dictated by regulatory agencies or required by underwriters, etc). We can build these models earlier than use cases sometimes.

Then we identify scenarios or use cases and these may also point to the full decision models (or just an anchor for them if they aren't developed). We do that with Visualization software.

So, I agree that rules/logic may surface during use cases (or earlier, or afterwards) but I don't agree with burying them in the use cases or anywhere else. For example, the rules behind Credit Score compiance can number in the hudnreds (or more) and that decision may be relevant to many processes or use cases and we want to reuse it (or create a customized view of it for specific business situations).

I think a difference between us is that we may be working with very decision-intensive applications which may not be the case in many industries.

When you say a business rule first appears in a use case, do you actually include it in the use case description or do you point to it elsewhere? Does it become a separate requirement? How do you accomplish reuse of rules and maintenance? Or maybe that comes later?

I am asking because we have tried all of the options in my article and usually, maintenance becomes a problem (except for the separate Decision Model).

(thanks for your patience again!)
How do you ensure reuse across use cases of the same policies or rules and maintain them?

Marc Thibault posted on Tuesday, August 31, 2010 3:33 PM

I normally record all business rules in a business rule document of one kind or another, --Word or Excel. The advantage in using MS Office is that you can go beyond references or links and embed text from one document to the other so that updating the authoritative source updates all the copies. A wiki works pretty well too.

One of the bits of information with each business rule is a reference to at least one affected use case (ref How will you know). Orphans are ignored.

Where a business rule has the effect of being a precondition for a use case, I will include it as a precondition with a dynamic link to the text in the business rules. One thing I will not do is force the developers to trawl through multiple documents to figure out what to build (unless the client insists).

I definitely won't make them repeatedly explore all the business rules in case one of them applies to what they're doing. If it's not mentioned in a use case, it doesn't exist.

There's a use case design process impact here. It all works better and faster if you go against the flow. Start with the outputs (the consumer use cases) and work your way back to the inputs. It's the output use cases that create the demand for the rest. It's backward from the usual approach but it's far more efficient.

Barbara von Halle posted on Wednesday, September 1, 2010 9:19 AM

Thank you again. Essentially, you do it similarly to how we do it, although we put them in a model. So, we translate policy statements into decision model format (and we can tie those statements to their place in the model). Recently, we have imported the models directly into automation with minimal IT intervention so that policy changes can be automated very quickly.

I like your idea of ignoring orphans. We kind of have the same perspective, we have no where to put a policy/rule if it doesn't fit into a decision model of importance and which will be called by use cases or processes, etc. We also sometimes let the decision model (rules/logic) drive the data models and object models because if there is a piece of data we don't use, we don't need it! This sometimes seems backwards to people who create a data model and object model first and then use these for writing rules.

Anyway, thank you for sharing, I appreciate it. If you publish an article in modern analyst, let me know and I will be sure to comment .

Barbara von Halle posted on Wednesday, September 1, 2010 9:28 AM

One more concept in common. You said you start with the outputs of a use case and work backwards to the inputs. I love it, we do that with decisions!

For example, in a Loan Process Model, for the Decision "Determine Loan to Value Eligibility" we start with what are the possible outputs of this decision? Lets' say (eligible, not eligible, needs underwriter attention). We can stop there for a bit.

Next, if this decision is one to dig deeper, we then ask, what criteria do you need to make this decision. Let's say (Current Loan Amount, Other Loan Amounts on Same Property, Current Valuation of Property, Past Evaluations of Property, and so on). We can stop there for a bit. In fact, sometimes IT can start creating models and prototypes.

Next, we study policy statements related to this decision and how it is made using these criteria. Maybe we find more criteria, maybe we eliminate some, maybe some come from a database, maybe some come from other business rules (such as Other Amounts on Same Property, do we need calculations or more logic) and so we build the skeletal model. We can stop there for a bit.

Next (or in parallel), we start filling in the tables behind the model with translations of each policy statement and maybe we find we need to change the structure.

In the end, we eventually find out all of the persistent data we need as input which will (executing the whole model) give us one of the outputs we listed in the first step.

So, I, too, find value in doing things backwards! It also sparks business innovative thinking more often, we find. Like, why do we look at that? Who decided that criteria is important or that a certain value is acceptable.

Anyway, just had to share that on re-reading your comment again.

zarfman posted on Wednesday, September 1, 2010 11:10 PM

Greetings: Barbara and Marc:

This is the old finance and accounting dude.

I’ve been following your posts with interest and I like your train of thought. In dealing with IT which was typically under my control. I made sure as best I could that they were provided with the following requirements information;

All reports mocked up on paper/Word with information where to find the data and how it would be created if not in the system. The reports should also be displayable with up and down scrolling capabilities, etc.

Any calculations, such as compound interest with different compounding periods including continuous compounding and interest rates could vary over time.

A mockup of the input screens with error checking requirements, and copies of input source documents if required.

If some or all of the data was already in the system, I had IT copy the data to a developmental database. Then I would have one of my accountants introduce errors in the developmental data.

I also gave IT a list of people to call if they had questions.

This approach seemed to get the project of to a good start. I agree with your idea of starting with the output first. At least in worked reasonably well in my case. I never had a business analyst per se. The personnel in accounting and finance were the de facto business analysts.

With regard to business rules the Financial Accounting Standards Board and the IRS supplies us with lots of business rules, so we don't have to go hunting for them. Moreover, the rules often change over time. IT worked on methods to store the rules or create objects so we could hopefully avoid what IT called re-factoring.

I also tried to make sure that IT didn’t view accounting as the enemy and vice versa. I'm not quite sure if that worked or not.

I seem to be rather fond of the letter I.

Regards,

Zarfman

Barbara von Halle posted on Thursday, September 2, 2010 9:18 AM

To Zarfman,

Excellent, excellent input from you! Thank you. And the word "I" is very important when talking about business-focused participants, not to mention business leadership. And congrats to the accounting and finance personnel acting as business analysts.

Some of what you talk about can be done in a semi-automated way with Visualization Products. We do models first (process, decision models, sometimes data/object models), and scenarios/use cases. Then we, "visualize" (your mockups) using Visualization software to solidify the flow and to attach decision models/business rules to the right places in the flow and also add comments to that visualization per the business input. Sometimes we create protocasts, a video showing a typical user walking through the Visualization depiction, as if the software was already built.

This is very similar to what you are doing and it is working for you. We don't necessarily view the Visualization as a prototype for the final product, but more as another means for eliciting requirements we may have missed.

I would be intereste in other readers' experience with Visualization and what benefits were realized and when it is and isn't necessary or desirable.

Thanks Zarfman for your post!!!!!

Marc Thibault posted on Thursday, September 2, 2010 2:32 PM

Zarfman:

It sounds like you're indulging in my favourite sport: Develop enough different views of the requirement that no one can possibly misunderstand what's to be achieved.

It works well for me too; you can never have too much information.

Cheers,
Marc

Patrick Devick posted on Wednesday, September 15, 2010 3:31 AM

For sure that Use Cases and Business rules can sure work together.

I think that specifying business rules have allready to be started when modelling the processes. By leaving them out of the process spefications and only refer to them from the processes they are allready seperated.

Later on when Use Cases are specified to support some steps of the the processes, they can reference to the same rules (library) the same way as are referenced from the processes. For sure don't include them, because it will hard to manage.

I see often that thinking about business rules comes up when use cases have to specified. Because then questions come up wat has to be checked, and what has to happen when it is not valid etc. And then the rules are suddenly owned by the IT project and not by the business. It should be done and owned by the business. Of course the system analyst can help.

By using a modelling tool (Sparx Enterprise Architect) instead of Visio, or Excel for rules, processes and use cas models, you can make a full model (including traceability relations) which offers different ways to do analysis on the information available in the model. For example a rule can be selected and the tool shows by which parts in the processes it is used and also which uses cases. And viceversa when selecting a use case or part from the process the used rules are shown. Of course this information has to be entered in the model and connected to each other. The tool I use also support the modelling of decision tables as you proposed in the article.

Information which is not specified easy in a model is still specified in Word and Visio and referenced from the elements in the model. Also because the readers are not used to it when presenting it another way. For example sketches of screens are we doing in Visio or other screen prototype tool. Exmaple of letters and reports are specified in Word. Full Use Case specifications is done in Word, but we are looking for a way to do it more structured way to enter it in the model and from there generate a Use Case

Barbara von Halle posted on Wednesday, September 15, 2010 1:39 PM

You make some excellent points, so I would like to re-iterate them.

1. I think that specifying business rules have allready to be started when modelling the processes. By leaving them out of the process spefications and only refer to them from the processes they are allready seperated.

Outstanding! The one common "gotcha" is if rules or parts of them are incorrectly modeled as process. For example, if a process model has a task for "Evaluate Credit Score" and the next task is "Evaluate Income" when, in some cases, these are simply conditions in rules that can sit behind one task for "Evaluate applicant's ability to pay" or something like that. But, as time goes on, we become more experienced at recognizing the difference between "process" and "logic/rules".

2. Later on when Use Cases are specified to support some steps of the the processes, they can reference to the same rules (library) the same way as are referenced from the processes. For sure don't include them, because it will hard to manage.

Excellent!

3. I see often that thinking about business rules comes up when use cases have to specified.

Yes, often, but not always. If a process is very decision-intensive (such as making credit decisions), it is possible to identify discrete decisions while doing the process model, then complete the entire set of business rules behind each decision prior to doing use cases.

OTOH, sometimes many or most of the rules do surface while doing use cases because we start to focus on details.

We find it useful to do it the first way because, while the business rules are truly the details, the entire decision (set of business rules) is the bigger picture and most often can get more management attention. IOW, the whole decision is seen as more than the sum of its parts.

4. And then the rules are suddenly owned by the IT project and not by the business. It should be done and owned by the business. Of course the system analyst can help.

This is a wonderful point! They should be "stewarded" by the business and they should remain readable and changeable by the business in a business-friendly form. I think some commentors have stated that the tools for doing so (including the traceability) are not simple for business people to use. And I think that is where we lose the business connection. What do you think? How can we keep them better connected to the rules?

5. By using a modelling tool (Sparx Enterprise Architect) instead of Visio, or Excel for rules, processes and use cas models, you can make a full model (including traceability relations) which offers different ways to do analysis on the information available in the model.

I totally agree. What we need are friendlier interfaces for business people for the raw rules/logic and the business analysts or systems analysts can make the useful connections.

6. Full Use Case specifications is done in Word, but we are looking for a way to do it more structured way to enter it in the model and from there generate a Use Case

An intriguing thought. I think of use cases rounding out models, but it would be interesting to be able to generate use cases.

Thank you for your input! I think it is valuable to most readers.

dejohnny posted on Friday, August 26, 2011 10:09 AM

This article really opened my eyes to new approaches for analyzing business requirements. However, the authors didn't mention anything about how business rules relate to User Stories. How could we use the same approach used here for Agile Projects?