ISO 21886:2019

INTERNATIONAL ISO
STANDARD 21886
First edition
2019-04
Space systems — Configuration
management
Systèmes spatiaux — Management de la configuration
Reference number
©
ISO 2019
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 General . 2
5 Configuration management planning . 3
5.1 General . 3
5.2 Configuration management plan . 3
5.3 Configuration management interfaces . 4
6 Configuration identification . 4
6.1 General . 4
6.2 Main activities of configuration identification . . 4
6.3 Product tree . 4
6.4 Configuration item . 5
6.5 Selection of configuration items . 5
6.6 Configuration documents list . 5
6.7 Identification marking . 6
6.8 Configuration document . 7
6.9 Configuration baseline . 9
6.10 Configuration change documentation . 9
6.11 Publication and maintenance of the configuration documentation . 9
7 Configuration control .10
7.1 General .10
7.2 Configuration control requirements .10
7.3 Change .10
7.3.1 Change classification .10
7.3.2 Change procedure .11
7.4 Deviation/waiver .12
7.4.1 Deviation/waiver requirements .12
7.4.2 Deviation/waiver classification .13
7.4.3 Deviation/waiver application .13
7.4.4 Deviation and waiver control procedure .14
7.5 Interface control .15
8 Configuration status accounting .16
8.1 General .16
8.2 Configuration status accounting requirements .16
8.3 Configuration status accounting process .16
9 Configuration verification .18
9.1 General .18
9.2 Verification of the product configuration definition .18
9.3 Verification of the product configuration.18
10 Configuration audit .18
10.1 General .18
10.2 Configuration audit requirements .19
10.3 Configuration audit team .19
10.4 Responsibilities of the supplier and the customer .19
10.5 Meeting minutes .20
10.6 Functional configuration audit .20
10.7 Physical configuration audit .21
10.8 Others .21
11 Configuration control board .21
Annex A (informative) Structure and content of a configuration management plan .23
Annex B (informative) Configuration management.25
Annex C (informative) Configuration status accounting reports .26
Bibliography .29
iv © ISO 2019 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 20, Aircraft and space vehicles,
Subcommittee SC 14, Space systems and operations.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
Introduction
The space system is a complex system and needs configuration management to ensure its success.
Configuration management establishes and maintains a consistent record of a product's functional
and physical characteristics compared to its design and operational requirements in order to allow
personnel that are involved to know, at any time, the technical description of a product using approved
documentation, and the operational possibilities and limitations of each product time.
vi © ISO 2019 – All rights reserved

INTERNATIONAL STANDARD ISO 21886:2019(E)
Space systems — Configuration management
1 Scope
This document defines the contents, methods and requirements of configuration management for
space projects, and the responsibilities and authorities of related parties. It can be used together with
ISO 14300-1:2011, Clause 10.
This document is applicable to the configuration management of space projects from the mission
analysis phase to the disposal phase.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 14300-1, Space systems — Programme management — Part 1: Structuring of a project
ISO 10795, Space systems — Programme management and quality — Vocabulary
ISO 10007, Quality management — Guidelines for configuration management
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 14300-1, ISO 10007 and
ISO 10795 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
configuration
interrelated functional and physical characteristics of a product or service defined in configuration
information
3.1.1
functional characteristic
performance parameter and design constraint to be realized or required, including operational and
logistic parameters and their respective tolerances
Note 1 to entry: Functional characteristics include all performance parameters such as range, speed, lethality,
reliability, maintainability and safety.
3.1.2
physical characteristic
quantitative and qualitative expression of a product and its tolerance
EXAMPLE Mechanical, electrical, chemical or biological characteristic.
3.2
configuration management
activity for establishing and maintaining consistent records of the status of and changes to the
performance parameters of a product and its functional and physical attributes compared to the
product design and operational requirements
Note 1 to entry: Configuration management is applied throughout the entire life of the product (i.e. development,
production, deployment, operation and disposal).
3.3
configuration item
aggregation of hardware, software, processed materials, services or any of its discrete portions,
that is designated for configuration management and treated as a single entity in the configuration
management (3.2) process
Note 1 to entry: A configuration item can contain other configuration item(s).
3.4
configuration document
document that defines the requirements for the function, design, build, production and verification for
a configuration item (3.3)
Note 1 to entry: For space systems, configuration documents can include documents relating to the operation
and disposal of the configuration item.
3.5
configuration baseline
approved status of requirements and design of a product at a project key milestone that serves as the
reference for activities throughout the life cycle of the product
3.6
change control
activity for controlling the changes or deviation/waiver to the product after the formal approval of its
configuration baseline (3.5)
3.7
change
official numerically issued alterations to a document or any portion thereof, usually brought about by
changed conditions or more complete information
Note 1 to entry: “Class 1” (Major) are changes that impact the contractual/technical agreement reached between
the project and its customer. It is necessary that such changes be submitted to the customer for review and
approval before implementation.
Note 2 to entry: “Class 2” (Minor) are changes that do not impact the customer contract and that are necessary
for the project and its supply chain to meet the technical/contractual requirements and provisions. Such changes
can be implemented after configuration control board (CCB) approval.
4 General
4.1 Configuration management establishes and maintains a consistent record of product functional
and physical characteristics compared to its design and operational requirements. Configuration
management shall be applied throughout the entire life cycle of the product and improved as the project
develops.
4.2 Establish the CCB consisting of representatives of related fields on the basis of the complexity of the
configuration item and its position in the project breakdown structure. The CCB consists of permanent
representatives of all programme or project disciplines necessary for the review and evaluation of
changes. The members of the CCB are with the decision-making authority.
2 © ISO 2019 – All rights reserved

4.3 Each supplier produces a configuration management plan (CM plan) responding to the
customer’s configuration management requirements. The CM plan shall specify the objectives, missions,
responsibilities and requirements of each phase during the entire life cycle and make necessary revisions
according to the specific circumstances as the project develops.
4.4 Configuration management interfaces with engineering, product assurance, manufacturing and
production and contributes to the programme or project organization and their schedule for execution
by identifying all constraints related to the business agreement provisions.
5 Configuration management planning
5.1 General
Configuration management planning is aimed at-specific configuration items. Effective configuration
management planning coordinates configuration management activities in a specific context over the
product life cycle and shall be performed at the initial phase of the project.
Configuration management planning shall:
a) ensure the configuration management process can comprehensively and accurately record and
control the evolution of product configuration;
b) ensure the participating personnel know the correct configuration documents of a product at
any time;
c) ensure the configuration documents used are complete, correct, controlled and approved;
d) ensure the traceability of the configuration evolution;
e) ensure the consistency of internal and external interfaces of a product;
f) ensure the consistency of the configuration of the inspected product and requirements of the
technical documents.
5.2 Configuration management plan
5.2.1 Configuration management plan is a document specifying the organization and its
responsibilities, the procedure, resources and means to implement configuration management. The
output of configuration management planning is a configuration management plan. The configuration
management plan prepared by the supplier shall be submitted to the customer for approval in response
to a requirement from customer.
5.2.2 For a configuration item, the configuration management plan shall:
a) meet the requirements of the contract;
b) establish the overall objective and phase objectives for the implementation of configuration
management;
c) specify the responsibilities and authorities for the implementation of configuration management;
d) establish the procedure and means to implement configuration management;
e) comply with the configuration requirements defined by the customer;
f) clarify the interface control requirements;
g) ensure that the process of the configuration management is under control.
5.2.3 Annex A provides the structure and basic contents of the configuration management plan.
5.3 Configuration management interfaces
Configuration management is an integral part of project management. Configuration management
processes shall interface with engineering management, product assurance, product manufacturing and
information/documentation management. For the definition and phasing of configuration management
activities, configuration management should also take into account the contractual provision and
schedule.
6 Configuration identification
6.1 General
Configuration identification incrementally establishes and releases controlled documentation for the
purpose of identifying configuration characteristics of a product until it is fully defined with respect
to its intended functional and physical characteristics. Configuration identification establishes
and maintains a documentation basis for configuration control, status accounting, verification and
audit, and is the basis for the implementation of configuration management. The management of the
configuration documents should be incorporated into the information/document management process,
and the relationship is detailed in Annex B.
6.2 Main activities of configuration identification
Main activities of configuration identification are:
a) select configuration items on the basis of the project breakdown structure and product tree;
processes and requirements of project breakdown structures are performed according to
ISO 27026;
b) determine configuration documents produced at different phases (including internal and external
interface documents) and form the preliminary configuration documents list;
c) specify identifiers for configuration items and configuration documents;
d) produce configuration documents based on the approved configuration documents list;
e) establish the configuration baseline;
f) document the configuration change information and provide its identifier.
6.3 Product tree
6.3.1 The supplier shall break down the task of the project, starting from the functional requirements
and according to certain logic and requirements defined by Level 1 customer. On the basis of the project
breakdown structure, the supplier shall determine the project structure levels and the corresponding
work, and complete the respective product trees in accordance with functional requirements for each
product.
6.3.2 The product tree, based on the approved final function, breaks down the system into successive
levels and defines the top-down architecture framework of a product, such as system level, subsystem
level, unit level etc.
6.3.3 The supplier shall ensure that the product tree can comprehensively describe the product’s
successive breakdown, the product’s compositions and their positions and the necessary configuration
items for the delivering of the product function.
4 © ISO 2019 – All rights reserved

6.3.4 The product tree is established on the basis of historical information or knowledge gained
through the project. The product tree shall be updated under configuration control.
6.4 Configuration item
6.4.1 The selection of configuration items is conducted on the basis of the project breakdown structure
and product tree. Configuration items correspond with the structure of product tree and are identified at
various levels of the product tree.
6.4.2 Configuration items fall into two categories, developed configuration item and non-developed
configuration item. A developed configuration item is subject to development and fully or partially
designed for the programme or project, while a non-developed configuration item is a standardized or
“off-the-shelf” product that is not developed specifically for the programme or project. Both of the two
categories shall by managed by the requirements of configuration management.
6.5 Selection of configuration items
6.5.1 Select configuration items as early as possible. Configuration items of upper levels (system and
subsystem level) shall be selected at the early definition phase; configuration items of lower levels (unit
level) shall be selected at the initial stage of its life cycle.
6.5.2 The number of configuration items selected shall take into account the management effect, cost,
risks, including safety and security, and development time etc., in order to maximize the project control
capacity of the organization.
6.5.3 The organization shall determine configuration items according to certain selection criteria. The
selected configuration items usually are:
a) items whose functional and physical characteristics can be separately managed;
b) items of system level, sub-system level or developed cross-unit and cross-sector;
c) items that have critical characteristics from a safety, risk and mission success point of view;
d) items that incorporate new design, technology or methods;
e) items interfacing with other items;
f) items designated for separate procurement;
g) items that are critical for use and security.
6.5.4 For configuration items controlled by the customer and their related baseline review, the
customer and supplier shall make mutual consultation to determine the principles to be defined in the
configuration management plan.
6.5.5 A list of confirmed configuration items shall be submitted to the customer for approval. The list
shall indicate the structure (system, subsystem and unit), names and identifiers of the configuration items.
6.5.6 Review and update configuration items as the project develops.
6.6 Configuration documents list
6.6.1 Each supplier shall determine the configuration documents related to design, manufacturing,
testing, operation, maintenance, storage, etc. (including internal and external interface documents) to be
prepared during the entire life cycle of the product. The configuration documents list shall be improved
and updated with the progress of configuration identification activities.
6.6.2 The configuration documents list shall include:
a) document title and identifier;
b) type of document;
c) phases during the life cycle;
d) expected release time (determined by the phases and supplier’s schedule);
e) preparation company and document status;
f) classification (open, classified), etc.
6.6.3 The configuration documents list prepared by the supplier shall be submitted to the customer for
approval.
6.7 Identification marking
6.7.1 General
For confirmed configuration items, their identification marking mainly includes configuration item
identifiers and configuration document identifiers.
6.7.2 Configuration item identifier
6.7.2.1 Configuration item identifier is a code to indicate the item (product) designation and type, and
shall be produced by the customer, supplier or related parties according to its sources and breakdown
structure (such as system, subsystem, unit, etc.).
6.7.2.2 A configuration item identifier shall be unique. A configuration item identifier shall include:
a) model identifier;
b) serial number;
c) configuration item identifier;
d) manufacturer identifier;
e) product name, etc.
6.7.2.3 Identifiers for standard products and off-the-shelf products shall comply with relevant
standards and requirements.
6.7.3 Configuration document identifier
6.6.3.1 Configuration document identifier is a code to indicate the entity described and the document
type and is usually produced by the supplier according to internal regulations.
6.7.3.2 A configuration document identifier shall be unique.
NOTE To avoid the possible existence of the same identifier for different products (items), a common practice
is to prefix the identifier with an enterprise identifier.
6 © ISO 2019 – All rights reserved

6.7.3.3 A configuration document identifier usually includes: name of the publisher, document
identifier, phase identifier, status identifier, document change or revision identifier, etc., and it shall be
marked at certain positions of technical documents (such as the title bar):
a) name of the publisher: name or name abbreviation of the document publisher;
b) document identifier: document number consists of product identifier, entity code, code and
document category number, where:
1) product (item) identifier is the symbol specified to distinguish different products;
2) entity code is the code specified to distinguish the technical documents for different types of
products, generally including the model product code, design serial No., etc.;
3) code is the code specified in accordance with specific rules and on the basis of the hierarchal
relation or technical characteristics of products;
4) document category number is the code specified to distinguish the different types of
documents;
5) enterprise code is the code specified by supplier to distinguish different suppliers.
Documents describing the same configuration item shall be numbered consecutively.
c) phase identifier: to identify the phase where the formed document is located in the product′s entire
life cycle; see ISO 14300-1 for phase division;
d) status identifier: to indicate the status of entity, such as M for model satellite, F for mission satellite;
e) document change implementation identifier: implementation document change identifier includes
the change to the number of implementation document and change to the marks.
6.8 Configuration document
6.8.1 Organization shall prepare a complete set of configuration documents according to the
configuration documents list required by each phase during the life cycle.
6.8.2 During the project’s development, document all functional characteristics, physical
characteristics, interfaces, changes and other information of each configuration item, and assign them
with unique identifiers.
6.8.3 The information of a configuration item is usually described in the following documents:
a) specification: a document defining requirements, including functional specification and technical
specification (such as the system specification, development specification, product specification,
process specification, material specification, etc.) Functional specification and technical
specification are prepared in accordance with ISO 21351;
b) drawing: a document showing the product structure, composition, shape and other information
using graphics and (or) the specified symbols, including drawings and diagrams;
c) list: a document describing the composition and quantity of products or documents using tables or
lists, including summary lists, supporting lists and complete-set document list, etc.;
d) procedure and manual: a document specifying the approaches and requirements to carry out an
activity or a procedure, such as the operation procedure, operation and maintenance manual, etc.
6.8.4 The realization of objectives during project development is usually defined by three types of
configuration documents: functional configuration document, development configuration document and
product configuration document.
6.8.4.1 The functional configuration document defines the customer’s mission demand, specifying
the overall functional requirements, mission requirements, interface requirements, design constraints,
acceptance and operation requirements. The functional configuration document is usually expressed in
the form of functional specification and (or) system specification.
The functional configuration document usually includes:
a) mission definition;
b) performance, risk, requirements and objective;
c) functional and physical characteristics of the main system or sub-system;
d) internal and external interface requirements;
e) design criteria, conditions and operation constraints;
f) test and reliability requirements;
g) organization, cost, schedule, etc.
6.8.4.2 The development configuration document defines functional requirements, mission
requirements, interface requirements, design constraints, acceptance and operation requirements for
compositions and items assigned from an upper level configuration item. The development configuration
document is usually expressed in the form of development specification.
The development configuration document usually includes:
a) requirements of functional characteristics of the system, sub-system or unit;
b) major physical characteristics of the system, sub-system or unit;
c) internal and external interface requirements of the system, sub-system or unit;
d) requirements for all tests or reviews necessary to verify the design;
e) design criteria, design constraints, etc.
6.8.4.3 The product configuration document defines functional characteristics, physical characteristics,
inspections and acceptance requirements of a specific item. The product configuration document includes
a complete-site of technical documents describing design, manufacturing, acceptance, operation, support
and interfaces of the delivered products. The product configuration document is usually expressed in the
form of product specification, material specification, procedure specification, drawings, diagrams, lists, etc.
6.8.4.4 Functional, development and product configuration documents are prepared, reviewed and
maintained during each phase of the life cycle. The three types of documents are gradually expanded and
detailed, coordinate and traceable.
6.8.4.5 When conflicts arise among functional, development and product configuration documents,
their order of precedence is: functional configuration document, development configuration document
and product configuration document.
8 © ISO 2019 – All rights reserved

6.9 Configuration baseline
6.9.1 The project is usually divided into several phases in order to achieve the overall objective. Each
phase has its own objective and task. For configuration management, the objective of each phase is
realized through the establishment of a configuration baseline.
6.9.2 A configuration baseline comprises the documentation that is formally approved at certain
points during the project’s development. The documentation is designated as the baseline for subsequent
development and production activities. The baseline is determined together by the supplier and the
customer and shall be used as the starting point for configuration control.
6.9.3 During the life cycle of the product, configuration baselines are elaborated in the following
sequence:
a) from the feasibility phase (phase A), establish the functional baseline at the early definition phase
(phase B). The functional baseline is complete when the documentation of overall requirements on
the function, performance and interface index are approved by the customer;
b) from the early definition phase (i.e. after the establishment of the functional baseline), establish the
development baseline at the late definition phase (phase B). The development baseline is complete
when the documentation of requirements on the function, performance and interface of the lower
level configuration item is confirmed by the supplier;
c) the product baseline is established in the late production phase (phase D) and after the product
qualification. The product baseline includes the documentation and approved changes necessary
for product manufacturing, assembly, testing, acceptance and operation.
6.9.4 For systems, sub-systems and lower levels, new configuration control points can be added based
on the item’s complexity and the mission’s progress. For example, the design baseline can be established
from the early development phase (phase C) and after the critical design review. The design baseline
includes technical specifications and design data documents prepared by the supplier and corresponding
documents of configuration items of lower levels.
6.10 Configuration change documentation
6.10.1 When a baseline is established, all changes after it shall be documented and each document shall
have a unique identifier to keep consistency between documents and entities.
6.10.2 The configuration change documentation includes change request, change proposal, application
for deviation and waiver and related implementation documents after approval.
6.10.3 Identifiers for implementation documents shall usually include change implementation
document number, change frequency and change places, etc.
6.11 Publication and maintenance of the configuration documentation
Submit the approved configuration documents by the specified time for publication. The supplier shall
keep and control the original copies of all configuration documents.
7 Configuration control
7.1 General
Configuration control is the process for controlling the evolution of, or deviation/waivers from agreed
baselines. It includes the preparation, justification, evaluation, disposition and implementation of
engineering and contractual changes, deviations and waivers.
7.2 Configuration control requirements
7.2.1 In order to keep consistency between configuration documents and entities, the supplier shall
perform configuration change control for controlling the evolution of, or deviation/waivers from agreed
baselines.
7.2.2 Configuration control starts when the functional baseline is established, and is performed during
the project’s entire life circle. Configuration control generally includes:
a) determining the category of configuration control;
b) determining the procedure of configuration control implementation, responsibilities, methods and
requirements;
c) implementing control over configuration changes;
d) tracking and verifying the implementation of approved changes.
7.2.3 For any changes, deviation or waiver, describe its effect on higher level and relevant configuration
items. Related changes of several products resulting from a common need for change shall be processed
simultaneously. Changes related to an element common to several products shall be presented to all the
concerned parties for effect assessment.
7.3 Change
Change refers to an alteration made on formally approved configuration documents during the project’s
development. The customer and the supplier can both propose a “change request”. For a "change
request" proposed by the customer, notify the supplier in written form and get the supplier′s reply
in the form of an approved "change proposal" in a certain time period before implementation. For a
"change proposal" which will affect contract and/or technical requirements, submit it to the customer-
level configuration control board for review and approval before implementation.
7.3.1 Change classification
7.3.1.1 Changes fall into two categories: class I change and class 2 change. The supplier may further
detail the changes according to the management requirements and on the premise that the changes are
under control.
7.3.1.2 Class 1 changes include:
a) Changes specified by the customer and affecting contract requirements:
1) cost;
2) warranty clause;
3) delivery requirements;
10 © ISO 2019 – All rights reserved

4) arrangement of major events.
b) Changes to functional and (or) development configuration documents. As a result, the following
requirements exceed specified values:
1) functional and performance definitions;
2) reliability, maintainability, safety, survivability, environment adaptability and electromagnetic
compatibility etc.;
3) interface characteristics;
4) critical physical characteristics, such as structure size, mass, moment of inertia;
5) other requirements having a direct impact on the success of the project.
c) Changes to product configuration documents that have a significant impact on the following:
1) functional and (or) development configuration documents as specified in a) and b) above;
2) support equipment and application software;
3) interchangeability of configuration items and their compositions;
4) delivered operation and maintenance manual;
5) already delivered items, etc.
Class 1 changes shall be submitted to the configuration control board at appropriate level for review.
Class 1 change can only be implemented after an approval is obtained from the configuration
control board.
7.3.1.3 Class 2 changes do not fulfil the criteria for class 1 changes and are necessary for the supplier to
meet the contract and/or technical requirements and regulations. The supplier shall implement internal
control for class 2 changes.
7.3.2 Change procedure
7.3.2.1 Determine the necessity of change
Any change to a configuration item shall be described and justified by the requesting party before
submission.
7.3.2.2 Changes classification
Classify changes according to the provisions in 7.3.1.2 (class I change and class 2 change) before
submission.
7.3.2.3 Initiation of change
For class I changes, the requesting party shall draft a change proposal (or change request) with
necessary proof materials and submit it to the corresponding configuration control board for review.
For class 2 changes, the supplier shall implement internal control in accordance with the provisions.
7.3.2.4 Change assessment
Change assessment shall be carried out by each corresponding configuration control board according
to change classification, interfaces and phases. The assessment mainly includes:
a) necessity and feasibility of the change;
b) relevant items and documents affected by the change;
c) impact on interfaces, interchangeability, safety and reliability;
d) impact on production, testing and inspection;
e) impact on purchasing and storage;
f) impact on the operation, maintenance and replacement parts;
g) impact on the contract, logistical support and cos
...