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.