I don't think it's possible to do either without knowing the history of
the product and your organization. If the A2 version is merely an
update of an already-successful A1, its business model is already
validated and the only real "requirement" that needs to be addressed
is why you need an A2. OTOH, if A1 has been floundering for its
entire life trying to find a niche and A2 is being developed to try to
resolve market targeting issues that undermined the success of A1,
not doing and documenting an A2 business analysis may just be
repeating the mistakes of A1.
> Today, one of the powers that be sneezed, shifted a brain cell, and suddenly
> decided that no documentation was needed for the 'as is' app. In fact, he
> decided that we could skip the business requirements for the A2 app and go
> directly to the functional requirements.
>
> At the moment I'm putting together a brief memo that details the importance
> of establishing business requirements before starting the A2 project, and
> establishing at least some business requirements for the legacy app.
>
> Do you agree? Disagree? Why?
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
