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

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?

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 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

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.

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.