Anyone who breaks in to another person's house is a criminal. Fireman break in to people's houses therefore firemen are criminals. Well obviously that is wrong and any idiot can see that. Is it always so obvious?
Functional requirement: Only a customer can withdraw money from their accounts. Is this ok? What about if they die? Alright, change it then: Only the customer or the executor of a their will can withdraw money from a customer's account. But suppose the customer is a criminal using the account to launder money?
The fallacy of accident is the fallacy of making a generalisation that disregards exceptions - applying general rules that allow no exceptions to circumstances that need to cater for exceptions.
Given these exceptions, a Business Analyst might be tempted then to restate the functional requirement as "Anyone can withdraw money from any customer's account". What the BA has done is commit the reverse of the accident fallacy by making a general rule based on exceptions - in effect by reasoning that since anyone MIGHT need to withdraw money from a customer's account then everyone CAN withdraw money from a customer's account.
So how to avoid these fallacies? Specify what the requirements actually are as definitively as possible:
1. A customer must be able to withdraw money from their account.
2. The executor of a customer's will must be able to withdraw money from that customer's account.
3. Anyone who provides evidence of their legal right to withdraw money from a customer's account can withdraw money from that customer's account.
Hopefully you can start to see how the three process models that would implement these three functional requirements might start to look and how they would involve different validation procedures. Perhaps these requirements need further refinements (for example combining requirements 2 & 3?) - doing these requirements is detailed, tricky work where fallacies are always waiting to trip us up...accidents happen...
Interesting excercise in logic Guy, but how would this play out in the development of a system or business process? Wouldn't the limited range of positive actions be built in rather than the reverse?
Craig,
Glad you find the logic interesting - I am writing an article making the case that the role of the BA in a project is to apply formal logic - no-one else is and there are so many ways to get things wrong we need all the help we can to get them right!
Agree the positive restrictions would be built in for this example. That does not mean we can generalise out from this specific to a universal rule: that would be a logical fallacy :-)!
Guy
Zarfman,
Good tip - thanks. In a similar vein, I worked in a place where we had SUMO cards (Shut Up Move On). You had (I think) 3 per meeting. You could 'play' the cards in meetings and whoever was talking just had to stop and the meeting moved on. Had to be used with care and it tended to get laughs if played right...
A colleague of mine recently attended a Kaizen workshop and remarked drily afterwards that perhaps Toyota is not the best example of success to quote for this approach. Toyota has methods and approaches such as Lean and Kaizen and Toyota was successful so the thinking had been "adopt these things and you will be as successful as Toyota." Now that Toyota is struggling, is the converse true?
The post I made "Great BA Fallacies #4 - Non-Sequiturs: it does not follow" proposes that until a causal relationship between these facts is established, then neither is true. These things may work or they may not. We need to define exactly and specifically and measurably what we mean by "work" and then analysis the cause and effects on these measures to see if these things do - in fact - work.
Trouble is the people promoting these approaches often make this logical mistake. And if they are respected people then we can make the logical mistake of believing them - Great BA Fallacies #1 argue from authority. They will also often quote anecdotal evidence such as "I have been involved in [insert a large but hopefully believable number here] projects and they were all brilliant so therefore this must be a good approach/method". Not until the causal link is proved objectively it ain't!
It is especially hard if these authorites use Great BA Fallacies #1 Proof By Verbosity to establish their case. Like I'm doing in this post... :-)
So really, it all comes back to this: use analysis skills, trust no-one, believe nothing - PROVE everything - in other words develop a BA'd attitude...And apply it to anyone who tries to tell you anything - and to this post...and to all methods and approaches that we see come and go in Business Analysis: just cos its fashionable doesn't make it good: Prove it!
brought to you by enabling practitioners & organizations to achieve their goals using: