 simpler com- are prepared to spend sometime (possibly weeks or months) cus- ponents. As part of configuration management it has to be decided tomising the method and the items which are automatically gener- which components are to be given distinct formal identities and ated. which are not. Those with formal identities are configuration items Category (3) is for users who have developed their own method and are visible to the configuration management system. (possibly combining hardware and software development tech- niques) and wish to generate an environment containing tools to support the method. The input to a meta-environment is a set of 25.9.2.2 Documentation plans notations, syntax and rules defining the semantics. Typically it will take several months to define such a method and use a meta-envi- Each project should operate a documentation plan identifying all ronment to create the necessary support environment, and care must configuration items created or used by the project, and for each be taken to ensure that the underlying method and techniques are configuration item identifying the documents and files which com- complete, consistent and appropriate to the problem domain. prise the item. Documentation plans are usually simple and generic. 25/18 Software systems in telecommunications 25.9.2.3 Parts list and 'where-used'lists design documentation), and in particular that the change is consist- ent with customer requirements. For each configuration item constructed from other configuration In the later stages of software development several baselines may items a parts list has to be maintained. This identifies the consti- have been drawn; specifications, design descriptions, code and test tuents of the item and also the other items needed for its construction packages may all exist. When a change is made it may affect several (such as the tools used to build it). of the baselines. The auditing function checks that the baselines are The approximate inverse of the parts list is the 'where-used' list, in s