The 2010 Business Rules Forum (BRF) had a new format and a new catch phrase — "Building Business Capability."  The BRF was co-located with a new Business Process conference and the inaugural International Institute of Business Analysis (IIBA) conference.  While business process analysis and modeling has been a focus of the BRF for many years, its alliance with the IIBA attracted a new audience to the conference:  Business Analysts (BA).  Over 700 people attended the conference, including BAs, many who had no prior experience with business rules.

It was interesting eavesdropping on the hallway and lunchtime conversations.  Many of the business analysts I spoke with were asking, "What's a business rule?"  Many of the business rule analysts were asking, "What's a business analyst?"

I've been asking that latter question since BAs started appearing on the same projects I was supporting in 2007.  Prior to that there were Requirements Analysts and Business Process Analysts on the project teams, but Business Analysts were new to me.  Given that the Data Management Association International (DAMA) has its roots in its initial chapter formed in 1980 and the first Business Rules Forum was held in 1997, the IIBA (which started in 2003) is a relative newcomer.

The IIBA states that its mission is "to develop and maintain standards for the practice of business analysis and for the certification of its practitioners."  In 2009, the organization published its Business Analysis Body of Knowledge (BABOK), Version 2.^[1]  The BABOK provides a project plan template that describes the tasks for which a Business Analyst is often responsible, the inputs and outputs for each task, and techniques that can be used to accomplish each task.  This task plan template can come in handy to the lead BA who often also serves as the project manager for the business analysis, requirements development, and testing activities.  As such, the lead BA is responsible for selecting which analysis techniques will be used.  Given the plethora of techniques with which business analysts are expected to be familiar, selecting the right ones can be a daunting task.  You could say that a BA must be a "jack of all trades," knowledgeable with just about every methodology that exists.

Each task and technique is briefly described in the BABOK.  The intention is to introduce the technique, not fully describe how to actually use it.  A fairly comprehensive bibliography is provided that guides the reader to additional resources.

Business Rules Analysis has been incorporated in this version of the BABOK, probably owing to the fact that Ronald Ross and Gladys Lam are on the BABOK experts advisory board.  This may also account for the number of BAs attending the business rule sessions at the BRF.  If a BA is supposed to be proficient in Business Rules Analysis, (s)he needs to know what a business rule is and what it isn't — thus, those hallway conversations about "What is a business rule?"

Of all the techniques included in the BABOK, the one that I have found to be almost universally used by BAs is the Use Case.  Since BAs are often the first point of contact with the project's Subject Matter Experts (SME), business rules may inadvertently be discovered during the development of use cases.  But are use cases really any good for capturing business rules?  Before this question can be answered, there must be a common understanding of just what a use case is and is not.

The best definition I've found for 'use case' comes from Alistair Cockburn:  "A use case captures a contract between the stakeholders of a system about its behavior.  The use case describes the system's behavior under various conditions as the system responds to a request from one of the stakeholders, called the primary actor."^[2]  The intention of the use case is to provide a clear understanding of the expected interaction, without concern for how that interaction will be implemented within the system.

Use case is a broad topic and the answer to the question depends on the context:  business or information system.  When use cases originally emerged and were incorporated into Object-Oriented Programming (OOP) approaches in the mid-1980s, use cases were used to specify the interactions between an external actor/role and an information system for a specific event.  The primary actor was a role usually assumed by a person directly using the information system, although the primary actor could also be another information system.

In 1997, the Unified Modeling Language 1.1 (UML), which included Use Cases, was adopted by the Object Management Group (OMG).  This standard was focused on OOP.  An information system's requirements were usually expected to be specified prior to the development of its use cases.  Those requirements that dealt with the expected behavior of the information system became the basis for the interaction analysis specified through use cases. 

At some point in time, someone decided that portions of UML could be use in analyzing a business system and in development of an information system's requirements.  Specifically, class diagrams and use cases were adapted for this purpose.  Often, they are referred to as the Business Object Model (BOM) and the Business Use Case to indicate that they are intended to describe a business system, not an information system.

Regardless of whether a project employs use cases at the business level to articulate the business requirements or at the system level to describe the expected interaction with the information system, an important distinction is that use cases are not intended to be the only requirements vehicle.  Cockburn states that use cases are only intended to address behavioral requirements.  Although he rarely mentions business rules, he does include them as a category of requirements that fall outside of use cases, along with Data Formats, Performance, User Interface, and others.  He does state that a use case should be cross-referenced to these "non-behavioral" requirements.

A project usually develops a template that provides topics that should be addressed when developing a use case.  The use case is given a name, which often is the goal that the primary actor wishes to accomplish, and the set of alternate paths that can lead to successfully accomplishing that goal or that can result in failure.  The use case goal is not the same as a enterprise's goals that are developed adhering to the OMG Business Motivation Model.^[3]  For use cases, the goal may be "withdraw funds from my account at an ATM" or "buy goods at a retail store" or "submit a presentation proposal for a conference through the conference's website."  They are more like events to which the business system must respond, rather than enterprise-level goals.

The use case also identifies the primary actor.  For the above-mentioned use cases, that actor is the bank's or retail store's customer or the conference's prospective speaker.  In addition to the primary actor, stakeholders may be identified who have an interest in ensuring that the system behaves as prescribed.

The essence of the use case is the "flow" section that describes the steps required to complete the event.  A use case contains at least one flow that represents the main success scenario (or "happy path").  The use case may also contain multiple additional flows that represent alternate ways of successfully achieving the goal or that result in failure.  The flow's steps, usually listed sequentially, may be an action or the invocation of another use case.

Other topics that may be included in the use case template that are relevant to business rules include:

• Scope:  Is the use case intended to be Business- or System-oriented?
• Trigger:  Action that causes the use case to be initiated.  Often, however, the trigger isn't specified because it is pretty much the same as the use case name (e.g., Customer requests a withdrawal from account).  However, timers/passage of time and state changes can also be triggers.
• Precondition:  Identifies states that must exist in order for the use case to proceed.

Interestingly, I find use cases to be quite comparable to the Event-Condition-Action (ECA) approach that some business rule practitioners use to specify business rules.  In ECA, the "Event" is equivalent to the use case goal and, occasionally, to the trigger; the "Condition" is comparable to the use case preconditions and conditions that cause a specific flow of events/scenario to be followed; and the "Action" encompasses the use case steps that are followed to reach the event's conclusion.  ECA uses the term 'otherwise' to differentiate between separate sets of conditions and corresponding actions.  Thus, each set of conditions and actions represents a single use case scenario.

Cockburn provides several real world use case examples, each using its own customized template.   However, I prefer the one that was developed by the team for a government agency project that was implementing a new case management system to support the granting of travel visas.  The primary user was the Visa Processing Officer (VPO), who determines whether or not a visa application is to be approved.  The information system was being re-engineered to be business rule-centric by embedding the business rules — extracted from legislation, regulation, and policy — in a Business Rules Engine (BRE).  The BRE determined the tasks that needed to be performed, based on the information provided by the visa applicant(s).  At any time during the process, the VPO could request that the BRE provide a recommendation as to whether or not the visa should be granted by assessing that visa application against the appropriate business rules.

The team consisted of both business analysts and business rule analysts (BRAs).  The BAs were responsible for developing the use cases while the BRAs harvested the business rules from the legal sources (e.g., legislation, regulations, and policy documents).  However, the BAs were responsible for identifying any process-oriented business rules they encountered while developing the use cases.

Proper cross-referencing between the use cases and business rules was essential.  The use case templates provided for a finer level of linkage than most templates I had previously encountered as the cross-referencing was done, appropriately, at the "flow of events" step level.  Often, a use case step was linked to multiple business rules.

This project's use case template further diverged from the standard templates used in the industry in its use of the term 'scenario'.  Traditionally, a scenario is just another name for an alternate flow.  On this project, a scenario was an explicit story that described an event at the level of detail that could be used to exercise a specific flow through the use case.  These scenarios could be used as the initial set of test cases and scripts for user acceptance testing.  As such, they added value beyond the traditional use case templates.

When first asked "Are use cases any good in capturing business rules?" my knee-jerk reaction was "No Way."  However, upon reflection, I realized that there are two questions being asked:  "Are use cases a good way to discover or harvest business rules?" and then, "Are use cases a good place to document business rules?"  When looking at use cases from these perspectives, I modified my opinion slightly.  To the first question, the "No Way" answer applies to system use cases, as they are developed way too late in the development life cycle — after the information system's requirements have been specified.  For business use cases, my answer to the first question is a qualified "Maybe."  To the second question, my response is an unqualified "No Way."

In the ideal situation, business rules are discovered and articulated very early in an enterprise's life cycle.  As an essential component of the Business Motivation Model, business rules should be initially specified while an organization is determining its business direction by articulating its mission and vision, goals and objectives, strategies and policies. According to the BMM, Business Rules are derived from Business Policies.  Business rules come into existence long before the enterprise determines what information systems it requires.  Business rules exist before the requirements are articulated for those information systems.  Therefore, business rules exist before the analysis that results in business use cases has even begun.

At least, that's what supposed to happen in the ideal world.  Unfortunately, from what I've seen, most organizations don't operate in the ideal world and never document their business rules before commencing their activities.  An organization's business rules are often part of its folklore, never stated but always understood.  They lie quietly waiting to be discovered in the organization's procedure manuals (if they exist) and extracted from the brains of its subject matter experts or from the current application portfolio's code.  In fact, for many organizations, business rules are not formally captured until the requirements for their information systems are specified.  Thus, we come full circle, because one of the more popular ways of specifying information systems' requirements is through business use cases.

Business rules can emerge while developing business use cases if the business analyst is very careful in constantly asking "WHY?"  At each step in the main success scenario and extensions, the BA should ask, "Why is this step necessary?"  The answer will usually be that some set of business rules must be satisfied because those business rules specify why the behavior that is articulated in the use case must occur.  Business rules are intended to control (or at least guide) the process or interaction so that the intended behavior occurs.  This is why I prefer the use case template that cross-references the individual flow of event steps to its guiding business rules.

Triggers can be another source of business rules, particularly when they are time-based or are the result of a state change.  For example, suppose I set the option that an email notification be sent to me when a payment is due on my credit card.  In this case, the customer is the primary actor of the "send payment due notification" use case, but the trigger is the passage of time that causes my account to move into the "payment due" state.  There are business rules lurking behind the action of changing the account's state.

Business use cases are valuable in identifying other stakeholders who are not the primary actor but who have an interest in the outcome of events that the use case describes.  In the case where the process owner is standing in for the "primary actor" I have found that the process owner whose needs are articulated through a use case is not the owner of the business rules that control the expected behavior.  The business rule owners are marketing, product management, finance, or the legal department.  In fact, these SMEs often complain that their needs are not taken into account during process re-engineering, yet they are the people who are responsible for the policies, decisions, and business rules that the process must enforce.  Likewise, they are the people who are responsible for defining the data that will be analyzed in the business intelligence environment — data that is often not directly related to the process but that the process needs to capture.  This is data that are the indicators of the health of the organization rather than what is needed to support a specific event.

In use case analysis, these organizations are identified as some of the use case's stakeholders.  Now the business rule analyst knows from whom (s)he should harvest the details of the business rules discovered during the development of business use case.

While business use cases may be acceptable to use in certain situations to uncover some types of business rules, business rules should not be documented within the body of the use case.  Just about all BAs with whom I've talked agree.  A separate template specific to business rules is needed to document their unique properties.

There are several reasons why business rules should be documented separately from other project artifacts.

Impact Analysis

Many projects start by describing the business processes, either through business process models or use cases.  When this occurs, if the project doesn't have a separate team of business rule analysts the only mechanism for discovering business rules is as the processes are designed.  The business rules are perceived to be a component of the process and are embedded in the process documentation (e.g., use cases, business process descriptions, user interface specifications).

However, the reality is that business rules are more volatile than processes.  Unless a process is terribly inefficient and in need of re-engineering, processes usually change because they are adapting to changing business rules.  If business rule statements are buried in process-oriented specification, the business rules are difficult to find so that the impact of the new business changes can be assessed.

Likewise, business rules shouldn't be disguised as requirements for the information system.  First, not all business rules can be automated but, instead, must be manually enforced.  In this case, requirements may never be stated for these types of business rules.  For those business rules that can be supported through the information system, requirements statements are developed.  Once a version of the system is delivered to support a set of requirements, the requirement statement ceases to exist as a living artifact.  However, the business rules that raised the need for the requirements persist.  When the business changes its policies, it will modify the business rules.  No one ever goes back and says, "I want to change that implemented requirement."  They just provide a new requirement to support the new version of the business rules in a future release of the information system.

Business Rule Sharing

Often, an enterprise's projects are organized around the point of interface.  For example, a bank may have separate development teams for their in-branch teller system, for their customer-facing automated teller machines (ATM), and for their on-line banking, internet-based applications.  Even though the same business event is available at all these delivery points, if an enterprise architecture does not exist in which the business use case for a common event — such as "Withdraw Funds" — is developed once and invoked by each of the device-dependent use cases, it is probable that each team will develop its own business use case.  When this occurs, the business rules are harvested multiple times and embedded in each use case.

Consider the situation in which customers had to apply for a specific service provided by the organization — for example, when applying for a loan, a government benefit, or entrance to a university.  A service had many variations that supported different customer needs.  It was important that the customer apply for the correct version of the service.

The client developed two information systems.  One was used by the case workers who decided whether the customer was eligible for the requested service. The other was used by potential customers to assist them in determining for which service to apply.  Each project developed their own use cases which included harvesting the appropriate business rules, written using a consistent vocabulary internal to the project.  The business rules were tested separately through extensive scenarios and the results approved separately by the business rule owners.  However, to keep the customer guidance application simple, only the most essential business rules were included, while the actual service application assessment system included all of the eligibility business rules.

Nothing was shared between the two projects — not the business use cases, the business rules, or the terms and definitions.  The customer guidance project factored in the time necessary to develop its own artifacts so it was completed on time.  But, as the business rules changed, impact analysis had to be done on both applications.  Had they shared the business rules and vocabulary, it would have been easier to determine whether both applications were impacted by the new version of the business rules.  Since the projects were using the same BRE, had they shared the same rulebase it could have been changed once and made available to both applications.  Any savings the customer guidance project achieved during development by staying independent of the service eligibility applications was reduced in on-going maintenance.

Technology Platform Migration

Should your project decide to incorporate a BRE into the technology platform, the analysts responsible for determining which business rules need to be migrated will be grateful if the project's business rules have been documented separately from other artifacts.  Harvesting business rules from use cases, process models, and requirements can be extremely tedious and error prone. Very often, the business rules are not specified at the level of detail to enable you to know, with certainty, that you have stated them correctly.  SMEs tend to remember the high-frequency business rules but often forget the more obscure business rules that are essential to the business but aren't invoked often.  It is probably better to extract the business rules directly from the application code since you know that you are getting the most current versions. 

On a recent assignment, a current state business rules repository was required as the initial step of migrating to a BRE.  The business rules were embedded within documentation that included the requirements, process models, use cases, user interface specifications, and data definitions for a given release.  The documents from the initial release had to be reviewed in creating the base set of business rules, and then the releases documentation was reviewed in sequence to find those business rules that had been added, deleted, or modified.  The only documentation that was maintained project-wide was the model for the database.  From this documentation, the current state process model, logical data model, and business rule repository were developed.  The models and business rules were reviewed by the application architects.  Quite often, they had to review the code to ensure that the harvested business rules were correct.

In hindsight, the project team members who had decided to organize their project's documentation around the release said that they would rather have maintained a project-wide view of the business process model and business rules so that, should a migration to a Business Process Management (BPM) or BRE suite of tools be necessary, the current state documentation would facilitate, rather than hinder, that migration.

Documenting business rules separately is a step in the right direction but not enough to be able to manage those business rules.  One of the criticisms of the business rules approach has been that it can lead to a profusion of seemingly-disorganized business rules that are difficult to navigate and understand. 

Organizing business rules by cross-referencing them with other artifacts is extremely important.  Several of the projects that I have been involved with include the use of a repository that maintains the master version of the use cases, business rules, process models, semantic/fact models, glossary, and test scenarios.  When a repository (an interactive metadata-driven application) is used, it is easier to navigate from one artifact to those that support it.  Reports and documents can be generated from the repository that can organize business rules by use case, business process model activity, business entity, decision, or policy.

When a repository product is used, the use case and business rule templates become the basis of its database design.  Each topic in the template is entered into the repository.  I have found that many analysts resist using a repository product, preferring the control they have by working directly with Microsoft Excel, Word, and Visio.  This approach provides benefit at the release level, while compromising the ability to manage the project's components over time.  Impact analysis is much easier — and usually more accurate — when using a repository where the current state component descriptions are maintained, including their cross-references to one another.

When a robust repository product is used to manage both the current and future states, the project team members (e.g., analysts, SMEs, developers, testers) then have the ability to maintain their individual perspectives (e.g., use cases, business rule sets, data glossaries) while also being able to navigate between these perspectives.  The project's documentation can be generated from the repository, at both the project-wide and release-specific levels.  In addition, most repository products can generate models and diagrams to a website so that the most current analysis can be made available to those who do not have direct access to the repository.

While use cases (or business process models or requirement statements) are not the best way to capture business rules, the use of a repository can facilitate the process of communicating the analysis results across the project team.

[1]  A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2, Self-Published by IIBA (2009), ISBN 978-0-9811292-1-1 (print).  

[2]  Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley (2001), ISBN 0-201-70225-8.  

[3]  Object Management Group, Business Motivation Model (BMM), Version 1.1 (May 2010).  

# # #