wing: AML_model_1 (in interface A) is the standard view, created by a standardization body. This model is refined (in a supplier's development process) to a supplier view (AML_model_2). This model is used for validation and verification of the sup- plier view. If behaviour specification of interfaces and entities is included in the model, it may be used for simulating properties of the network system as well. When the supplier decides to realize the network system, the verified AML_model_2 is (automatically) translated to one or several UML_model_1 (in interface B). Objects and relations in an UML_model_1 will be (more or less) equivalent to entities and relations in the AML_model_2. A UML_model_1 is used as a requirement specification for sub-contractors. A sub-contractor refines a UML_model_1 to a UML_model_2 that on its lower structural levels refer and specify SW elements, and on its highest structural level is equivalent to the UML_model_1, i.e., refers entities and relations of AML_model_2. This scenario guarantees that requirements can be traced over the whole devel- opment process (from both ends), thereby preserving network system integrity over a longer time. Although it may take some time before standardization bodies will create stand- ards as AMLn models (instead of conventional standard documents), suppliers can benefit at lot of manually translating standard documents to AMLn models: The interpretation quality is considerably improved by creating an AMLn model from standard documents. Analyzing the effects of new requirements on the supplier view is facilitated. A supplier who applies this approach will not risk erroneous and/or ambiguous interpretations later on in the system's lifetime. Note that network developers do not need to work in both AMLn and UML, since the entities, relations, and the behavior described by an AMLn model can always be automatically translated to objects and relations, and the behavior described by an UML model. The translation is done by using an AMLn-to-UML translation 