documentation | can be a source of rigidity in software development unless it is managed appropriately | ![2001-08-30 14:55:21.0](facet.gif) |
can entrench poorly made decisions that are hard to change | ![2001-08-30 14:55:21.0](facet.gif) |
can waste resources if it is never read | ![2001-08-30 14:55:21.0](facet.gif) |
has purpose to document decisions and to communicate them to others | ![2001-08-30 14:55:21.0](facet.gif) |
includes requirements, designs, user documentation, instructions for testers and project plans | ![2001-08-30 14:55:21.0](facet.gif) |
is a subtopic of 1.8 - The Eight Themes Emphasized in this Book | ![2001-08-30 14:55:21.0](facet.gif) |
is a kind of representation | ![2001-08-30 14:55:21.0](facet.gif) |
must provide the information the readers will need, and must be organized in a way so that the readers can find what they need easily | ![2001-08-30 14:55:21.0](facet.gif) |
should adhere to standards for the company | ![2001-08-30 14:55:21.0](facet.gif) |
should be as short and succinct as possible | ![2001-08-30 14:55:21.0](facet.gif) |
should be written at all stages of development | ![2001-08-30 14:55:22.0](facet.gif) |
should not be written prematurely just to meet specific deadlines because writing documents then becomes the objective, instead of solving problems | ![2001-08-30 14:55:22.0](facet.gif) |
will not be read if it is excessively voluminous, poorly written or not made readily available | ![2001-08-30 14:55:22.0](facet.gif) |