Re: Design specs (Was: Design Methodology forGUIdevelopment)

31 Jul 2004 - 2:10am
474 reads
pabini
2004

Jim Drew wrote:
> On my current project, our initial black box test plans were informed
> by very early mockups done for "what features would you want in this
> product" surveys. We didn't have semi-valid mockups (or text specs)
> of the real stuff for months. As a result, our initial test plans
> were based on our guesses of what the product would do from those
> invalid pieces of info, and we ended up having to fight those
> assumptions back later on.
>
> We wasted time and the mental effort needed to comprehend the product
> because the info we were given was invalid, and known to be so, but
> its invalidity was not transmitted to us. (Once burned, twice shy,
> though. We'll know better next time. Maybe.)

***In the rush to market that's so common these days, these sorts of things
often happen. It's really important to lay your foundations before trying to
build.

> > > discussion of expected feature
> > > interactions and user workflows
> >***PGP Yes. I call the latter usage scenarios. They document user
> >interactions step by step.
>
> They seem to be the hardest things to get into the specs. They tend
> to live in marketing documents rather than engineering specs, but not
> in MRDs or other docs which are available to the entire team.
> Workflow info on the current project has had to be guessed at based
> on incomplete knowledge of semi-competing products. Thank god for
> the marketing and QE people both being in the UI spec reviews, or
> some of that info would never get from them to us, and we're the ones
> who have to test what they want the product to do!

***I must admit that under schedule constraints, this is sometimes a part of
a spec that gets sacrificed, but I know the value that it provides to both
QEs and technical writers.

Syndicate content Get the feed