s of concrete systems are constantly introduced, and will be documented as modifications of the applied system model. The realizes information elements then support designers in identi- fying which parts of the implemented system will be affected by the new require- ments. The other scenario is probably more important and frequent: systems management often wants to introduce new technologies for realizing products in order to improve characteristics, simplify system maintenance or decrease produc- tion costs. Changes in product structures are also sometimes considered for the same reasons. It is important that designers can analyse which requirements are affected by such changes to make sure that the integrity of concrete systems is pre- served. By now you are probably thinking: "All this talk about product structures and information elements seems to be very complicated. Why do we need to manage product structures at all? It should be possible to fulfil the needs of project planning 1.5 System Models and model management through a coherent system model that is handled by some clever tool. Model designers and users would then not have to know anything about product structures and information elements." Of course you are right-in principle! In industry, a model management approach to information management is also becoming increasingly popular for pure soft- ware systems. But for all other types of systems, the product structure approach is practically the only approach that is used. Figure 1.15 illustrates the two main approaches to management of system models. Product structure management Model management General Model information management management system system Database Database fragment, /subsystem blockgroup block HW-product SW-product Fig. 1.15 Product structure management versus model management A product structure can be stored and managed by a general relational or object- oriented database management system (a DBMS). From a tools point of view, this is a low-cost and well-known way to handle the info