From: Don Mills (donm@softed.com)
Date: Fri Feb 01 2002 - 19:36:30 EST
At 01:27 1/02/02, Matthias Patzak (hi, Matthias!) wrote:
-----<snip>-----
>One task of the analysis is to hide complexity!
-----<snip to end>-----
Not sure that I agree with this, Matthias. I'd have thought it was the task of analysis to *reveal* (underlying) complexity.
(Here's an interesting question to ask "systems analysts" / "business analysts" you work with or encounter: "What's 'analysis' mean?")
The trick is (as I try to teach test analysts on my courses) to identify the level of complexity (read, "detail") that's appropriate to the analysis you're doing. I use the analogy of a forensic chemist who analyses an unknown substance to the level of radicals, molecules, and atoms, but not below that level; because though neutrons, electrons, and protons are real, and are relevant to someone else, they're not relevant to the forensic chemist. (In Cause-Effect testing, the appropriate level of analysis is that of the simplest verifiable assertions, unzipped at AND / OR boundaries; below that level, all you have is individual words. However, the analyst must also preserve information about the permitted and necessary relationships between the nodes.)
And (again as I teach my students) the only level of detail that's appropriate is the level that removes uncertainty and ambiguity.
*After* that level has been arrived at, it will probably be appropriate to *synthesise* a set of simpler representations (the columns of a Decision Table, in Cause-Effect testing); but the detail (complexity) must still be available behind them (the "Condition Stub" of the Decision Table).
Regards,
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:30:38 EST