In our ongoing exploration of how to meld the worlds of business rules and requirements, we look at an example use case and see how to extract the business rules.
Separating Business Rules From Requirements
In our earlier article we described one benefit of separating business rules from requirements. That article explored the benefit that we get from spending less time defining requirements and less time interpreting requirements. Ultimately, we spend less time developing our software as a result.
Business rules tend to be embedded in structured requirements artifacts because those rules tend to be uncovered during elicitation activities for the requirements. One very common and powerful artifact is the use case. And business rules often get embedded in use cases. We’ll look at an example.
Use Case Example
In Patterns for Effective Use Cases, by Steve Adolph and Paul Bramble, we find an example that shows several opportunities to embed (or more importantly, to abstract) business rules. The authors (there’s a link to the book at amazon at the top of this article in the Recommended Reading box) do a fantastic job of providing examples, both good and bad, that highlight behaviors common in use case development. It is a great resource, and if you are anything short of a use case expert, you should own this book.
Use Case 6.9, from p.160 of the book is a use case for withdrawing cash from an ATM. I’m retyping and editing it for our example – all mistakes are mine:
Name: Withdraw Cash
Primary Actor: Account Holder
Normal Flow:
- User inserts his ATM card.
- System reads and validates the card information.
- User selects transaction and enters transaction details.
- System validates transaction details.
- User collects cash and withdraws card.
- System updates the account and resets the system.
Finding Rules-Extraction Opportunities
The same normal flow from above is duplicated below, but with bold text to identify places where there is an opportunity to abstract business rules. We will look at each example.
Normal Flow:
- User inserts his ATM card.
- System reads and validates the card information.
- User selects transaction and enters transaction details.
- System validates transaction details.
- User collects cash and withdraws card.
- System updates the account and resets the system.
Looking at each opportunity…
- Validates the card information. What does it mean to validate the information? What information must be on the card? Possibly only the account number. Perhaps both the account number and an encrypted copy of the account number. Since a bank almost certainly maintains unique account numbers, and people’s names are never reasonably unique, the name of the account holder is redundant information – but it may be used as a redundant piece of information in a set of validation rules. Regardless, the validation criteria represent a decision – which is determined by a set of rules.
- Selects transaction. What is the set of possible transactions for the machine? That list of transactions may change over time. Are different types of transactions allowed for different accounts? While not an explicit decision – the list of transactions implies an implicit decision of what transactions the system must support.
- Validates transaction details. There will be validation rules associated with every transaction. What types of accounts can be used to transfer money to other accounts? What are the maximum and minimum withdrawal amounts? And do those vary for account holders (maybe high balance accounts allow larger withdrawals, or maybe account holders can restrict the withdrawal amounts for secondary card holders)? Each possible transaction will have a set of allowable actions / valid details.
- Updates the account. Perhaps service charges are made (or waived) based on a set of criteria. Maybe people with multiple accounts get free withdrawals. Perhaps the fees (charged by the machines) are paid by the bank and credited to the account.
Instead of writing requirements that specify these details, we should abstract out the rules (e.g. “See transaction list XYZ”).
Summary
[Ed: Added 2007-07-17, thanks Bengt for pointing out that this was missing.]
The requirements discovery and elicitation process uncovers both requirements and rules. While not a formal definition, rules are “discrete requirements”, in that they should be managed differently. Rules can be changed independently of requirements – the transaction-validation rules, for example, do not need to be defined in order to write the software, and should be easy to change once the software is written. Rules may represent constraints, as Roger alludes in the first comment in the discussion below – such as regulatory compliance, or fraud-risk policies that are independent of the ATM interface/process design. Rules may also be implicitly reflected, again, as Roger points out – such as a rule that requires an account to be verified prior to processing a transaction.
In all of these cases, the frequency of change, people responsible for the changes, or the impact on consumers of rules and requirements encourages us to abstract the rules from the requirements.
It seems there are two kinds of opportunities to extract business rules from use cases.
The first kind is when the rule is embedded directly in the use case. The very order of steps in the use case might constitute a business rule (e.g. validate card information before selecting a transaction). Or a step in the use case might constitute a rule (e.g. if the card is identified as stolen, then notify the theft department).
The other kind of opportunity is when the use case contains actions that have rules underlying them. Your examples focus on these kinds of opportunities. You note, for example, that many possible business rules underly the “Validates transaction details” step of the use case.
One important thing to recognize is that the nonfunctional requirements surrounding the use case drive the business rules. For instance, there are security and usability constraints on the Withdraw Cash use case. The business rules must be such that these constraints will be satisfied as the user carries out the use case. As I’ve mentioned, the nonfunctional requirements can be expressed as preconditions and postconditions of the use case.
I added a summary after your comment, Roger. Thanks, as always, for helping everyone here with your inputs.
The hidden implicit rules you point out are definitely worth noting. For example, a rule that constrains the sequence of steps is hard to capture when it is not explicitly called out. Definitely food for thought.
I very much like the idea of “Barely Good Enough” Use Cases, and would like to see all business rules referenced in an external document, in something that would look like Object-Oriented Documentation. This way, through iterations of documentation and hyperlinks, your docs are always accurate.
I very much do not like it when Use Cases straitjacket the System. Hard coding business rules into Use Cases can be problematic, especially if the development team is using a new technology. While the business rules need to be adhered to, do we have to tell the developers HOW to implement them?
Nice post.
Josh
Thanks Josh, for reading and commenting!
OO Documentation is definitely very handy. I remember the first hyper-text documents back in the late 80’s when I was in school – it was a mind-opening experience – sort of footnotes on steroids. And wikipedia takes it to the next level. There is still a challenge in making that work in printed documents, as well as offline docs – but it is definitely the way to go.
One challenge that comes from this sort of tracing is knowing when references become invalidated. Consider a use case that depends upon (is linked to) a rule. Imagine the rule is then updated. We need to know that the use case is still valid (complete, consistent, etc.). Some of that validation was deferred to the rule as capturing the business rules.
The use case relies upon that rule to maintain its validity, and the rule may have been changed in a way that invalidates the use case. A solvable problem, but still something that has to be addressed.
I first learned about analysis when James Martin and Information Engineering was ‘the’ thing. Before you blow off my comments below as antiquated, I honestly do want to understand…
Creating an IE process decomposition for the use case above, anything connected with an ‘and’ is two processes. Simple, basic rule. Therefore #2, #3, and #6 would each break down giving you not 6 but 9 processes to further decompose. Obviously a process like ‘User inserts her ATM card’ can not be further decomposed. But a process like ‘Validate Transaction Details’ clearly has more to it that needs to be understood, therefore I would further decompose that process.
I think that either way you go – Use Case or Process Decomp – you ultimately have the same information – it is just depicted differently.
With IE, a process called ‘Finding Rules-Extraction Opportunities’ would not be necessary. You just keep breaking a process down until you get to the ‘Reach into your pocket and pull out your ATM card’ level.
so, my real question… if you had an IE process model that was decomposed down to the detail level of defining exactly how to ‘validate transaction details’, how do you differentiate Requirements from Business Rules?
Linda, thanks for commenting and welcome to Tyner Blain! The last thing I would do is blow off your comments, and antiquated doesn’t mean bad.
Einstein’s general relativity theory, Newton’s 2nd law, Euclidean geometry, and the mythical man-month are all “antiquated” ideas. I feel sorry for anyone who discounts them.
You make a good point that process vs use case documentation is essentially the same information, from nearly the same point of view. I accept your premise that they are equivalent for this discussion.
Also – the “compound steps” issue you identify – completely agree. I stole the use case as an example, and I agree with you. However, that’s a tangential one. On to the real question…
I differentiate business rules from requirements for the purpose of improving readability, to reduce the effort of maintaining documents in a world filled with constant change, and most importantly, to encourage the development team to implement them separately. This separation of implementation provides the biggest bang for the buck, because it dramatically reduces the cost and time to change the way your business operates.
Given that premise, ‘validate transaction details’ may include (since you’re decomposing further) ‘confirm that resident address is within 10 miles of ATM.’ Yes, we who travel see that as a dramatic inconvenience. Imagine that the ATM is in rural China, and as a mechanism of combating fraud and violence, the bank established a policy that prevents people from stealing the cards (or identities) of rural villagers in order to cash in at an ATM far away.
That policy works fine for 99% of their customers, until the local economy and culture evolves to the point where more customers desire to have access to their cash while in the next village. The bank changes the policy to allow a 20 mile range, in response to this customer demand.
The policy (a limitation, in this example) is orthogonal to the process – in other words, changing the policy doesn’t change the way the process works, just the criterion about which the flow branches.
If the developers had implemented a complex location-inference approximation that works up to a distance of 15 miles, the cost of changing this policy could be very hard – intense development combined with software (or even firmware) updates to the ATM machines. That would be bad.
If the developers had written code that says “Check distance <= X" and then abstracted the value of X to a lookup table, then the cost of change would be much lower - just update the data (maybe even through a nightly update) without changing the software (logic). Take this to the next level - so that the developers are only writing "call all required validations" into the code, with a separate database that says "these validations are required (with the details of how each one is implemented)". Now the bank can eliminate the policy, or add new ones, again - without updating the software. This is a contrived example, but it demonstrates the power of the abstraction. One distinction between rules and requirements is frequency of change. The bank is much more likely to change the validation policies than it is to change the requirements. One example of requirements would be around asking the user to enter transaction details. The bank could have taken an approach where you insert the card and get 100 yuan. No custom transactions, simple interface - just insert card and get money. Need more money? Do it again. Need less? Do it less frequently. Hopefully, that addresses your question. If not - build on this example or create another one, and let's dive in together. Thanks again, Scott