From: Andrew Gabb (agabb@tpgi.com.au)
Date: Fri Jan 02 2004 - 09:20:14 EST
HaimK@aol.com wrote:
>>>If this is true, wouldn't a formalization (that can be directly
>>>translated into a user-oriented "readable" form) be more useful
>>>in keeping everyone on the same page, and in helping to reconcile
>>>everyone's interal model of both the problem domain and the
>>>"machine" (ala Michael Jackson)?
>>
>>It would be excellent!!! A dream come true!!!
>
> I completely agree, see below.
>
>>But only if it *was*
>>essentially correct, comprehensive and complete, was maintained and
>>was translated into assimilable models as soon as it changed. I've
>>never seen this happen. Never. Ever. And apart from in simplistic
>>toy projects, I strongly doubt I ever will.
>
> I've seen and made this happen, up to a point (sorry for the self-promotion).
Oh, and I should have added that I've seen countless cases where people claimed that *their* methods worked (the Z/VDM schools often claim this), as long as you follow *their* model of the project from go to whoa. Unfortunately for a number of reasons their models are typically unrealistic, unachievable, and too effort intensive, to be used for real projects with real users and developers. Which is precisely why the take-up is so low using these methods, even though they've been pushed fanatically for some 20 years now (often with different names and badges).
Note again that I have no problem with the use of symbolic, logical and mathematical (SLM) models for analysis and design purposes, but not (usually) for the representation of user requirements.
I find the over-concentration on the 'legislative' aspects of requirements quite unhealthy, particularly since it's led to these SLM methods. In many cases, it's involved researchers with a strong mathematical inclination, but limited understanding of the human problems (not you, Haim), to appy the only tool in their toolbox (an SLM hammer) to problems which are much more complex than they'd ever understand. And this becomes part of the problem rather than a solution to it.
As I've said before, I truly believe that it's not usually possible (or perhaps cost effective) to express user needs and activities for a complex system in a strictly formal (legal) way, and any customer who signs up to such a statement of requirements is an idiot - and most aren't and won't.
Most of the more serious problems I've seen involving requirements are caused by (a) omission of important requirements, and (b) developers having insufficient understanding of the users' needs and activities. Another is predatory developers finding loopholes in the requirements, sometimes just to reduce their cost, and sometimes because they didn't spend enough effort understanding them in the first place.
One effect of these is that the system may 'technically' provide all the functions and features that are needed but in a way which is extremely inefficient for the users. This is a typically difficult area to tie down either technically or legally, and it's why you need to understand both the needs and activities. It's also an area which is hard to represent using SLM methods. (Note that I don't include use cases in SLM methods - the diagrammatic aspects of use cases are useful but much less important than the text.)
We need to accept the fact that a high level of trust is needed between the customers and developers (and I've seen this trust in numerous successful projects). Then we can concentrate on improving the understanding of everyone, rather than using obfuscating methods which actually reduce the information flow across the interface.
Andrew
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon Jan 05 2004 - 09:00:14 EST