Business rules are not requirements. Yet they are often gathered at the same time as requirements, from the same sources, by the same business analysts. And unfortunately, often documented in the same artifacts. In this article we look at some of the ways that business rules are commonly hidden inside use cases.
Separate Business Rules from Use Cases
As we’ve discussed before, business rules need to be separated from requirements. James Taylor and I continue to explore how best to isolate rules from requirements. To quickly summarize (and dramatically oversimplify) one of the points from James’ book, Smart Enough Systems, isolating the implementation of business rules allows you to update the way your business runs on your software much more quickly. And the first step to driving this isolation at the implementation layer is to isolate rules from requirements at the documentation layer.
Types of Business Rules
In our earlier article, we touched briefly on how business rules are used to define decisions within a use case or process flow. David Wright wrote an article, The Business Rules Approach, where he identifies five classes of business rules:
- Constraints – mandated criteria such as “the applicant must not be a felon”
- Guidelines – suggestions such as “the applicant should not have been rejected previously”
- Action Enablers – rules that initiate or trigger behavior, like “when the customer’s card has been rejected, it must be confiscated”
- Computations – the embodiment of calculations, like “pay 1.5 times the wager for a two-card total of 21″
- Inferences – the canonical “if…then” statements
These types of business rules can easily be hidden in different elements of a use case.
Where Business Rules Can Lurk
When we look at the structure of a formal use case, we see several areas where business rules can be hidden.
Description
Since the description acts as a summary or overview of the entire use case, any of the different types of business rules might be captured within it. Looking at an example from one of our old articles:
A pilot performs an FAA mandated list of equipment and operational inspections prior to every flight. All inspections must pass before the flight is allowed to take off per corporate policy.
“All inspections must pass…” is a constraint, and therefore a business rule. “Prior to every flight” is also a constraint. It would be better to write the description as follows:
A pilot performs an FAA mandated list of equipment and operational inspections [see FAA-1] prior to flights.
We’ve removed both business rules from the description, and added an explicit reference to the FAA mandated list. If the list of inspections defined by the FAA should change, we should not have to update our use case.
Triggers
Very often, these are action enabler rules. A trigger of “Student submits college application” is a trigger for the “Evaluate student application” use case. Although you could possibly argue that this is a business rule, there doesn’t seem to be much value in making the distinction. However, a trigger could also be “It is Friday at 5pm” for the use case “Process pending orders.” This represents a company-specific business decision to process orders at the end of the week. The order-processing use case would not change if the frequency were changed to every day, or every other week. The trigger really represents an implicit decision – “Is it time to process pending orders?” Using language that is more correct for a trigger, we would write:
It is time to process pending orders [See BR021, Order-processing time].
This would allow us to change the way our business operates more quickly. We could start processing on any frequency – or even start processing whenever more than 10 orders have queued up, or whenever outstanding orders represent $1000 in revenue (or profits). The key point is that by abstracting out the decision, Is it time yet?, we again can change how we run our business without having to update and re-validate the use case.
Preconditions
Business rules that represent constraints very often show up as preconditions to a use case. Since preconditions describe “what must be true” before the use case starts, this is understandable. Imagine we were writing a use case named “Process New Car Loan Application.” An obvious precondition might be that the amount to be borrowed has been resolved for the new car.
This would reduce labor, by only processing loan applications (which include running credit checks, etc), after a buyer has been locked in to a price, their trade-in value has been agreed to, and any deposit has been defined. However, this represents a linear process. An interesting business decision might be to immediately process a loan application as soon as the buyer agrees to start negotiations. The car dealer could use a conservatively estimated amount to get approval from the financing institution for a loan for “up to amount X.” Then, once negotiations have been completed, the only step remaining would be to fill in the exact amount and get the buyer’s signature. A much improved shopping experience for the new car buyer.
We could write this as follows:
A maximum amount for the loan has been identified [See BR033, Determining loan-application amount].
And then, within that business rule we can define heuristics like “Subtract Kelly Blue Book value of indicated trade-in from 5% below the sticker price” or use the average selling price for the particular model car + 5%, or any of a number of rules. Those rules can easily be changed without affecting the loan-application use case.
Normal and Other Flows
There are many opportunities within the normal course of a use case to hide business rules. Every point in the use case that could cause branching to an alternate or exception flow represents a decision. Each of those decisions represents the combination of one or more business rules. To be more precise, each decision represents a set of rules that are applied together to reach a conclusion (stay in the normal flow, or branch to another flow).
A use case named “Review conversation transcript” for a CIA analyst would have a normal course that probably documents that the transcript has been reviewed, and follows some archiving procedure. If the transcript identifies a “red flag” word or phrase like “Blackbriar” or “Touchstone”, then an alternate flow would be initiated. [Yes, I did watch the Bourne Ultimatum this weekend.] The trigger for this alternate flow could be written as:
3. Review of the transcript identified a red-flag word or phrase [See BR US-21744.6, Identification of red-flag words and phrases].
Then this business rule could be defined as a lookup into a database, it could be filtered – so that counter-terrorism analysts look for different words and phrases than people looking for drug dealers. This allows the “review a transcript” use case to remain stable while the rules for identifying onerous phrases are modified on a regular basis. This also allows the “review a transcript” use case to be changed without impacting the phrase-identification business rules.
Key Element
The key element of this reworking of use cases is to reference the sets of business rules that make up individual decisions, constraints, and action enablers. Those rules are maintained in separate documents. These other documents may be distinct documents, top-level objects within a requirements repository, or rule sets managed in a rules repository.
Most importantly, the rules are not hidden within the use case. Hiding the rules in this way makes it more difficult for developers to interpret the documents. It makes it all but impossible for the developers to abstract the rules into abstract decision services. It also slows down the approval process of the requirements and the rules – both initially, and when managing changes.
Latest Articles
Comments on all Articles
