Daniel --

Just to start a response...

The types of and distinctions between analysis documents depends on the size of the project. And, there's quite a bit of variation in naming depending on size, contracting body, etc. At this point, a document type tends to be defined by the parties involved.

However, if you do want to do some comparison between different types of analysis documents, Software Requirements: Analysis and Specification by Alan Davis, Prentice Hall, is a good resource.

It sounds like you, your client and your vendor have different expectations which would be needed to be hashed out to proceed in acquiring software.

Not knowing anything further about the situation, I may be stepping out on a limb. But, from your description, it sounds like the DDD should be an internal document developed by the software vendor for the purposes of its own customization. It is hard for me to imagine charging a potential client for that document (if that did happen).

I could consider an analysis charge for meeting business requirements, but in many circumstances that either be included as part of the sales process or determined on your own. A competitive process for acquring a product can often put a potential vendor in the "proper state of mind." Of course, that also will depend on what you want in a quote -- it's harder to get a fixed price quote than time and materials that way.

In any case, if you feel you don't have enough information to proceed, I suspect you don't.

Jay

>Good day to all:
>
>I need your help!
>
>My client is meeting with a vendor this afternoon to discuss the DDD they wrote (after implementation) of an existing system + several (200+) proposed customizatized items. My client and I are not happy with the DDD because because it does not contain enough details. The vendor asserts than it does. It looks like the project will be put on hold until we can agree on the purpose of the DDD.
>
>I need your opinion about what should be the purpose(s) of the DDD (the customization of an existing system that we do not own at this time) and what would you expect to find in it.
>
>Thank you for your help!
>Daniel Rouleau
>
>
>Vendor's comments:
>The main purpose of an as-built design document is to help maintenance and enhancement programmers to trace features of the software to units of code during problem/enhancement analysis. Its purpose is not for a reader to validate whether the as-built system meets stated business requirements. Such validation can occur in one of two ways:
>1. Detailed analysis of existing source code using the DDD as a source code navigation aid, or
>2. Execution of an acceptance test against the requirements. (this is the recommended, more efficient approach)
>
>For customized elements of the system, design documentation can and will be used to check that all software requirements have been allocated to design elements, but again requirement validation can only occur using one of the two methods mentioned above.
>
>Therefore, any document review comments that aim to make the document suitable for requirement validation are not applicable and should not be considered conditions for acceptance of the DDD.