Separating Business Rules From Requirements Increases Agility

We’ve written in the past about why it is important to gather and manage requirements. In short, you avoid some costly mistakes, and fix others before they become too expensive. We’ve also started exploring how business requirements and business rules live and play together. But why should we bother to separate business rules from requirements? One reason is to increase your company’s agility.

Benefits of Separating Business Rules

There are some significant benefits to separating business rules from requirements, and we learn many of them in our interview with James Taylor from a couple weeks ago. James’ new book, Smart (Enough) Systems, focuses on the benefits of automating decisions, but some of those benefits can be achieved to a lesser extent, just by isolating the business rules that would then ideally be automated. The main benefit that comes to mind is the increased agility of the company when it comes to changing their rules and processes. By isolating the business rules, they become easier to change and manage.

David Wright recently wrote an article at RQNG titled The Business Rules Approach. In it, he also points to the speed with which a company can change rules – not only as a benefit of managing business rules separately, but as a need to adapt and respond to today’s markets.

How Is Agility Increased?

There are two main ways in which agility is increased when separating business rules from requirements. First, the requirements management process will take less time. Second, the company can implement changes to their solution more quickly.

Less Time Managing Requirements

One best practice in writing requirements is to write concise requirements. You can’t just write the requirements with fewer words – that might lead to ambiguity. But you can dramatically simplify the writing, reviewing, and interpreting of requirements by isolating the business rules that represent decisions within a requirements document.

As an example, a process flow might include a decision – “Do we have the needed paperwork to approve the loan?” And that decision might represent a series of rules:

• If the applicant’s credit rating is above 700, we only need a valid driver’s license and SSN.
• If the applicant’s credit rating is between 600 and 700, we need a recent credit check, driver’s license, and SSN.
• If the applicant’s credit rating is below 600, we need a cosigner on the loan.
• If a co-signer is required, the co-signer’s credit rating must be above 600.
• If the applicant’s credit rating is below 600, we must run a new credit check, and have a valid driver’s license and SSN.
• If the co-signer’s credit rating is below 700, we must have a recent credit check for the co-signer, as well as a valid driver’s license and SSN.
• If the co-signer’s credit rating is above 700, we only need a valid driver’s license and SSN for the co-signer.
• If a recent (within 6 months of application date) is not available, a new one must be run.

In a process flow diagram, we could create a series of decision boxes – always requiring the applicant’s SSN and driver’s license, sometimes requiring a credit check (and some of those times requiring the credit check to be new), and sometimes requiring a co-signer. We would then have more branches for the co-signer.

This flow diagram would be pretty complicated. This can be simplified by embedding a decision tree into the requirements documents. However, you still are applying the (potentially) heavyweight requirements approval and validation process to this decision tree. You are also asking your developers to review this decision tree and determine how to implement it. A great developer will see when it makes sense to abstract these decisions from the code, and a less-great developer will embed them. In either situation, you’re asking your developer to spend time thinking about this abstraction – and thinking about how mutable the particular decisions are.

As an analyst, you are better informed about the mutability of the decisions. By documenting the decision as a single decision in the requirements document (“Do we have the needed paperwork?”) that references the enumerated business rules. It is also easier to review the rules and validate them when they are isolated. Business people who don’t have backgrounds designing software do find it easier to review these steps when presented in the context of a decision – and it is easier to grab the context of the decision from a simpler process flow diagram.

Less Effort To Change

Even if you don’t automate the decision, you still make it much easier to review changes. If the thresholds change from 700 and 600 to 650 and 550, it is trivial to update the isolated business rules. It is also an easier process to approve those changes when you are only updating and reviewing the business rules – and not a broader requirements document.

Developers abstract “magic numbers” like 700 and 600 (in this example) into variables and constants when they embed them into code. We are doing the same thing by isolating the business rules from the requirements (which then reference the rules).

What about changes that are more structural in nature? Imagine that we redefine the criteria – eliminating the 700+ rules, and changing the 600 rule to 650 – and always require a new credit check for co-signers. Then we also decide to add a new document – say proof of residence, or proof of employment. If we were managing this within our requirements document, it would take extra time to validate – and possibly re-implement the solution. With a solution like James proposes in his book, the business analyst could make the changes directly into the rules-processing engine and the software would not even need to be modified. In either case, the approval and change process is faster.