| documentation | can be a source of rigidity in software development unless it is managed appropriately |  |
| can entrench poorly made decisions that are hard to change | |
| can waste resources if it is never read | |
| has purpose to document decisions and to communicate them to others | |
| includes requirements, designs, user documentation, instructions for testers and project plans | |
| is a subtopic of 1.8 - The Eight Themes Emphasized in this Book | |
| is a kind of representation | |
| 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 | |
| should adhere to standards for the company | |
| should be as short and succinct as possible | |
| should be written at all stages of development | |
| should not be written prematurely just to meet specific deadlines because writing documents then becomes the objective, instead of solving problems | |
| will not be read if it is excessively voluminous, poorly written or not made readily available | |
Object Oriented Software Engineering View all facts Glossary Help
