Pat,
I document these type of questions with a Design Document. The
development process utilize here has this document as a deliverable
before coding begins. Prototypes haven't been officially adopted within
the process, but are used on most projects. The prototype is used for
the input screens only. All that is done with the prototype is replacing
static data with appropriate dynamic statements. The question that
arises there is: where does this data come from? Well, that's what's
defined in the Design Document. Each page, including action pages, has
its own section with all actions, queries, etc., fully described within
the Design Document. I use the prototype to aid in the development of
this document. All pages in the document are titled with the same title
given to the corresponding prototype page. If it is an action page, then
I document "This is the action page for Page Y" and that pretty well
clears up most issues. Not sure if that's what you're looking for, but
that's the process I use.
Phil
Patrick McElhaney wrote:
> > Steve wrote:
> >
> > Sure you can say anything you want. Just try and word it in
> > the form of "this is what we want" instead of "this is how
> > we'll do it"
> Yes, that makes sense. But I think Erki's question is about
> the what rather than the how.
>
> > Do you see the difference?
> >
> > A good game to play is to pretend it's all magical. like "The
> > information is saved" where? how? when? is it fast enough?
> > All of those questions wouldn't matter if it was magical.
> >
> > We can worry about reality later.
> When exactly is later? I thought the purpose of the prototype
> was to "creep the scope" up front?
>
> > Programmers often want to offer numerous edge cases
> > like "what if X happens or what if Y happens?" They say
> > "I'm just being a devil's advocate". Reality doesn't need
> > a devil's advocate, because it can't be ignored. So don't
> > worry about how you're going to make it all work, just
> > figure out what the client is looking for.
> Erki is talking about what the client is looking for. The
> client wants some functionality that's hard to express in
> the prototype. We're not just talking about "edge cases."
> For example, the app I'm working on now has eight fuseactions
> and only two very simple screens.
>
> How do you answer questions like "Which employees show up
> in that drop-down?" and "Who gets an email notification
> when that happens?" and "When they come back to that form
> later will they have to fill it out again or will it retain
> their information?" How do you capture all of that
> information with the prototype? Or do we only get those
> sort of questions in the arctic?
>
> Patrick
>
>
>
ColdFusion Certified Developer
Applicaiton Analyst
Lockheed Martin NE&SS - Surface Systems
Bldg. 104-032
199 Borton Landing Rd.
Moorestown, NJ 08057
Phone: (856) 722-7477
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
