Analysis and DEsign

Henry Spencer henry at utzoo.UUCP
Sat Jun 7 06:53:36 AEST 1986


>   ...The whole point is doing a
> careful job of program/system design is so that you WILL understand the
> problem fully.

How, when not even the user himself really knows what he will like best?

> ... One of the main tasks that a good analyst
> does is to help the user make decisions!  He guides the user and in that
> process gets a clear view of exactly what it is the user is trying to do and
> what the user will expect as a result...

And what the user *guesses* he will like in the way of a user interface.
Finding out that he wants his tax calculations to follow a specific formula
is one thing; finding out how he wants the result displayed is another.
The former is readily possible, but not the latter.  The imagination of
the typical user is not up to the demands placed on it by this process.
He really doesn't know whether he will like alternative A or B better, since
he has no experience with either.  It's notorious that even expert intuition
is an unreliable guide in such matters.  How much *less* reliable a guide is
intuition by untrained customers!

> ... The presence of the software only changes the user task's if this 
> has not been discussed with the user.

This is simply wrong.  I'm not talking about changes due to the software
not fitting the user's routine, I'm talking about changes in how the user
works that arise LATER because his tools have changed.  Do you really
believe that the nature of the tool doesn't influence how it is used?

> Again a good analyst will expain to the user how the software will impact
> his working enviroment, and together than can plan with this in mind.

Note we are again back to guesswork as to how the user will react to the
software.  Educated guesswork, perhaps, but guesswork.

> ... Discovering what the users needs are
> is not done in front of a computer terminal writting code, it's done TALKING
> to the user!...

Wrong twice, it's done by observing what the user does, both before the
advent of the first prototype software AND AFTER.  The user himself often
does not appreciate the implications of the way he does things... certainly
not well enough to guess the implications of changes.

> ... you certainly don't want to run out and
> write the entire system and THEN ask the user what he/she thinks.

Agreed that you don't just charge in with no idea what the customer wants.
But in another sense, YOU WILL END UP GOING THROUGH THIS CYCLE REGARDLESS.
The only question is whether the first version is explicitly an experimental
prototype, or is claimed to be the "first production version".  Better you
should plan for this and try to arrange that it happens early.
-- 
Usenet(n): AT&T scheme to earn
revenue from otherwise-unused	Henry Spencer @ U of Toronto Zoology
late-night phone capacity.	{allegra,ihnp4,decvax,pyramid}!utzoo!henry



More information about the Comp.lang.c mailing list