From: Andrew Gabb (agabb@tpgi.com.au)
Date: Wed Dec 31 2003 - 10:37:23 EST
Overmyer, Scott wrote:
> Playing devil's advocate, which I dearly love to do, how do you
> ensure that when the reader "assimilates" (to use your term) the
> requirements, that they will not use their own internal model of
> the problem domain to, perhaps unconciously, "tailor" this
> assimilation in some way. This is a largely natural phenomenon
> that causes the "assimilated" representation to become secondary
> to the external representation (i.e., the specification).
This is almost always true, Scotto. Different users *will* have a different understanding of the user domain - different from each other and different from the REs. In some cases individual models will be more sophisticated than others (and the REs') - in other cases they are simplistic and just plain wrong. This is one of the common barriers working against RE and understanding at least some of these models (or viewpoints) is essential. I've also noticed that this problem tends to be much more pronounced when the requirements are poorly expressed (not readily assimilable) and/or there is little user involvement in the ongoing project.
In one or two larger user spaces I've worked in, I found that in some specific areas, I was the only one that had a reasonably comprehensive model of how it all worked. But that's relatively rare.
However, in my experience it's far more likely that individual developers (even REs) have less adequate models, and more dangerous misconceptions, than the users do.
> 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!!! 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.
Old army saying: "When the map differs from the terrain, believe the terrain." You're searching for the perfect map, I believe - one which updates itself as the terrain changes and has infinite resolution.
> It's my assertion that there must, for most system requirements
> specification, be a formal representation at the heart of the
> specification. Otherwise, there is far too much ambiguity and ad
> hoc decision making, which is generally bad for the software
> process.
This depends totally on what you mean by a 'formal representation'. If you mean Z or VDM, forget it. If you mean various forms of UML-like diagrams, then I tend to see these as analysis or further development tools rather than *the* representation of the users' needs. I've got absolutely no problem with the use of systematic representations of various kinds as tools to assist in understanding and completing the requirements. However, to me the 'primary' requirements must be in an assimilable form, which normally means text in user speak as requirements and/or activities (OCD, use cases), coupled with diagrams which are either natural to the user domain or which are relatively simple to understand (eg sequence diagrams).
So while you see a danger in ambiguity and incompleteness, I assert that for a sizable project you can *never* completely represent the richness of the users' needs formally. Any attempt to do so will act as a form of constraint, and limit the requirements, which you may pay for later - I've seen this happen countless times. You need to try to minimise, live with and cater for the misunderstandings, which *will* happen.
CAVEAT: I'm talking here about the *user* requirements. As I've frequently demonstrated, the sets of 'requirements' that the developers use at different levels as they move from initial analysis to implementation are progressively constrained, and increasingly unambiguous, and the developers can use any representation that *they* are comfortable with.
But remember that product validation, which is the ongoing critical 'correctness' check, must be against the current user needs and activities. If you can find a formal model that can be used for validation, it either means you're very, very lucky to be working on such a simple, static and/or homogeneous project, or more likely that you're kidding yourself. In many ways, validation is the ultimate check that your models (at different levels) are correct, or perhaps validation can be seen as an important ongoing activity which compensates for the inevitable limitations in your models.
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