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.
“Business rules are not requirements”?
While I value the distinction you are seeking to make, I think you’ve got it wrong. Sorry!
Certainly, business rules are not user interactions or system behaviors, so we don’t want their principal residence to be within use cases. And there may well be benefits to a system’s stakeholders from implementing business rules in such a way that they are more readily altered (which is a non-functional requirement that comes at a cost, of course, so we had better strive for net benefits). This should not force us to conclude that business rules are not requirements, however.
In any event, it seems to me that there are other places that business rules may lurk within use cases. First of all, the goal of the use case may itself be compliance with business rules. To take your FAA inspection example: “…before every flight” is explicitly “corporate policy”. That the airline chooses to enforce and monitor this policy is implicitly corporate policy. That the airline chooses to do no more than enforce and monitor compliance with FAA guidelines, rather than its own higher standards, is tacitly corporate policy. We might hope that the use case will be reusable whatever the pre-flight checks may be, but “hope” is not solid foundation…
A second place that business rules may lurk is within the definition and selection of actors. In your example, “a pilot” ought, perhaps, to be “the pilot”: the particular pilot for the flight. But perhaps it could be a co-pilot (for the flight), any of the airline’s pilot’s, or any person with certain minimum qualifications. Again, the business rules here may originate with the FAA or be further qualified by corporate policy (airline’s and, indirectly, airport’s). It may be necessary for “the pilot” to perform the checks, for example, but not to be the actor in the use case, or for someone else to perform the checks, overseen by “the pilot” who [currently] must be the actor in the use case.
Sepcific or generic? It seems necessary to define for any system the environment or milieu in which it is expected to operate. I’ve always called this the “operational context”, and business rules are a major part of this (especially if you add “facts” or “invariants” to your list of types). In recent discussions, it has been suggested that “operational envelope” may be a more appropriate term. The suggestion is that an “envelope” is a more generic environment than a “context”. I’m not sure that the terminology is important, but the critical factor is documenting appropriate limits to design to (relatively extreme environments rather than typical ones). Broadly speaking, the more extreme the limits, the higher the cost, so I treat the “operational envelope” specification as a multi-dimensional non-functional requirement. Since the supported variability of business rules translates directly into variability of the “operational envelope”, I hope you can understand why I find the idea of business rules not being requirements a little perplexing.
Alan,
Thanks very much for reading and commenting. I especially appreciate the insight you’ve put into this discussion.
When I describe rules as being “not requirements” I am not saying that they are not required, but rather that they are not the necessary components of an approach to achieving a value-based goal. Rather, they represent constraints on how that goal is to be achieved for a given company.
Those constraints may be external regulations or internal policies that the company has chosen to adopt, enforce, or extend. They certainly represent criteria by which the success of the software will be evaluated.
There is value in making the distinction, although it is more practical than semantic. Why separate rules from requirements? I’m going to switch gears and write that as a blog post right now. I’ll add another comment with a link to it.
Oh – great catch about the selection of an actor being a possible source of “hidden rules.” To make requirements more easily consumable, I would tend to write it as a precondition of the use case “The actor has current FAA certification for inspection.” Or “The actor must be one of the pilots.”
That is definitely a policy (or regulation) being enforced. Many people who are qualified to do the inspection could, but the pilot (of that flight) is the one who is required.
The longer response is up Why Separate Rules and Requirements
Thanks again for starting a great discussion. It probably makes sense to move additional conversation to the latest article.
A policy when rendered as a requirement embeds the policy in code. A policy when rendered as a business rule, is data. When a business manager changes a policy that has been embedded in code, they must task IT/development with making the change. If that policy had been rendered as data, the manager would change that data.
A sales commission might be set at 25% of the revenue from a sale. There is no reason why a programmer should be required to change the percentage involved. That percentage is a business rule. The computation of the revenue from a sale would likewise be a business rule.
What is required is the ability to use the specified percentage from the business rule in the calculation of the sales commission.
Signals travel around a circuit. The signal can vary, but the circuit is stable. The signal is the business rule. The circuit is the use of the signal in the calculation.
The circuit is the carrier. The signal is the carried. Requirements define the carrier or infrastructure. A business rule defines the carried or content.
The circuit or carrier must be built, hence a requirement. The requirements need not change when the carried varies.
Thanks for the good article. I learn by example, and I have found several situation in which I was confounded as to what approach I should take to document a use case. here are some good examples:
1. Accept claim use case
Flow:
1.1 timestamp the claim (once received)
1.2 Validate the calim (this would involve, structural validations – e.g., NCPDP trxn, format validations – required vs optional, numeric vs alpha, etc, content – if the member’s insurance company is “X” and the date of claim is before “Y” then associate claim to insurance company “Z”, etc)
1.3 Based on validation determine whether to reject or continue claim processing.
This is a simple 3 step use case it seems. But, 1.2 has tons of validation rules falling under structure (purely a technical transaction concern), format, content. How do you propose these rules are documented? I mean there can be 100s of rules. For example,
For the Rx number there could be rules like, Rx number must be numeric. Rx number should have 10 digits.
How about if there was a requirement that said, if Rx number starts with “1” this claim is a worker’s comp claim.
etc…
Bottomline…how would someone document this rules (stuctural, format, content – business and technical) be documented?
Here is a nother example:
Use case: View order processing claendar (i.e., what are my cut-off times for order processing)
1. Use chooses to view the order processing calendar
2. System displays the order processing cut-off start time and end times.
BR: cut-off start and end time is based on either historical actuals (i.e., what were the official times) or based on a future schedules start and end time.
Should this be a BR? What we are trying to say is, that in another “configuration” use case, we can potentially change the cut-off start and end times, which should be reflected correctly when I execute the view order processing calendar.
So bottomline, is I don’t know whether to write this as a rule or just say the system will lookup this information as part of the flow.
Any thoughts?
thank you