Re: [re-online] Requirements vs Agile User Tests

From: David Lightstone (david.lightstone@prodigy.net)
Date: Sat Apr 12 2003 - 22:25:53 EST


> David Lightstone wrote:
> >>What would we lose by doing this?
> >
> > Among other things:
> >
> > (1) Understandability. (I have no reason to belief that the "tests" will
> > readily be understoud. I am inclined to believe that a specification
will be
> > understandable. Note a specification is by definition something that is
well
> > written as opposed to the poorly written requrements document)
>
> I agree with David's concern about 'tests as requirements'. This is
> yet another example of trying to overload work products with
> additional objectives, with unfortunate side effects in some situations.

I never thought of it that way, but this observation - trying to overload work products with additional objectives - is something that I consider very important. (ie avoid doing it when possible)

One of the dreams of management is establishing synergisms as a mechanism for improving productivity (the proverbial 2 birds with 1 stone). It is in conflict with a goal of eliminating inappropriate coupling

>
> I tend to use the horrible word 'assimilability' (I made it up, but
> I'm sure I'm not Robinson Crusoe) rather than understandability. If
> I were forced to define it, it would mean something like: "The
> ability to be understood quickly and accurately, by those who need
> to read it". In other words, it's not just that it should be
> understandable (in a requirement sense), with a little effort, but
> that it should facilitate easy understanding.

"Assimilability" as you have used it was my intent. An ability/inability it infer the operational characteristics is the primary concern.

>
> I suspect that this may be difficult and go against the grain of
> many test definitions. If we compromise, whose objectives do we
> sacrifice - the testers or the 'requirements' audience?

You compromise neither. The effort to do so establishes an inappropriate coupling. Test descriptions are the result of a transformation performed upon the requirements. Requirements are the result of an analysis (possible resulting in problem abstraction) performed upon incomplete descriptions.

A tests as description strategy attempts? to eliminate this analysis. In the world of AI it would be equivalent to a belief that computer (as opposed to human) learning can occur by example (for some problems yes, but not most)

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


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 Apr 14 2003 - 09:00:10 EST