The project workbook is not so much a separate document as it is a structure imposed on the documents that the project will be producing anyway.
All the documents of the project need to be part of this （?。? This includes objectives ,external specifications , interface specifications , technical standards , internal specifications and administrative memoranda(備忘錄).
Technical prose is almost immortal. If one examines the genealogy ( Ff ) of a customer manual for a piece of hardware or software , one can trace not only the ideas , but also many of the very sentences and paragraphs back to the first （?。?proposing the product or explaining the first design. For the technical writer, the paste-pot is as mighty as the pen.
Since this is so, and since tomorrow's product-quality manuals will grow from today’s memos, it is very important to get the structure of the documentation right. The early design of the project （?。?ensures that the documentation structure itself is crafted, not haphazard. Moreover, the establishment of a structure molds later writing into segments that fit into that structure.
The second reason for the project workbook is control of the distribution of （請(qǐng)作答此空）. The problem is not to restrict information, but to ensure that relevant information gets to all the people who need it.
The first step is to number all memoranda, so that ordered lists of titles are available and h worker can see if he has what he wants. The organization of the workbook goes well beyond this to establish a tree-structure of memoranda. The （ ） allows distribution lists to be maintained by subtree, if that is desirable.
A.product
B.manual
C.document
D.information