Input data must be identified in order to provide the basis for the formulation of requirements that are used to verify and validate the output data. Input data can be external and internal.

To ensure that the needs and expectations of all interested parties for a process and/or service, process or system are met, design and/or development inputs must be accurate and complete. Resolution of ambiguous or contradictory inputs should be done with input from affected external and internal parties.

External inputs may include customer or market needs and expectations, stakeholder specifications, contractual requirements, regulatory requirements, international or national standards, and industry codes and regulations.

Internal inputs may include policies, standards and specifications, qualification requirements, documentation and data for existing products and/or services, and outputs from other processes.

In the case of design and/or development of software or services, inputs arising from end user requirements (as well as direct customer requirements) may be particularly important. Such inputs must be formulated in such a way that they can be effectively controlled during subsequent verification and approval. Such inputs must be formulated in such a way that they can be effectively controlled during subsequent verification and approval.

Inputs may also arise during the development phase from activities that are not even fully evaluated. Also, input data should be the subject of evaluation of subsequent review and verification and approval activities.

Other inputs identify those design and/or development characteristics that are critical to the safety and proper functioning of the product and/or service or identify processes such as work operations, storage, handling, operation and disposition requirements.

Typical examples of development activities include:

modified materials,

changed product components,

new technologies for providing services,

market analysis results.

Inputs that are critical to the product and/or service or process must be identified in order to assign appropriate responsibilities and resources.

ISO 9001:2000 - Quality management systems - Requirements 7.3.2 Design and development inputs. The requirements for the product and/or service should be defined and recorded (see 5.6.7). These requirements should include: performance requirements from the customer or market; applicable regulatory and legal requirements; applicable requirements for environment requirements arising from previous similar projects; any other requirements essential to the design and development. These inputs must be reviewed for adequacy or inconsistency with respect to the requirements to be met.

Design and Development Inputs

Input data related to product requirements shall be defined and records shall be maintained (4.2.4). This data should include:

a) functional and performance requirements;

b) relevant legislative and mandatory requirements;

c) where appropriate, information drawn from previous similar projects;

d) other requirements important for design and development. These input data must be analyzed for adequacy. Requirements must be complete, unambiguous and consistent.

Design and development output

The design and development outputs must be in a form that can be verified against the design and development input requirements and must be approved prior to release.

Design and development outputs should:

a) meet design and development input requirements;

b) provide relevant information on procurement, production and services;

d) determine the characteristics of the product that are essential for its safe and correct use.

History of work in the field of quality in Russia.

Speaking about best practices in the field of quality management, one cannot help but recall the domestic practice of quality improvement.

What quality improvement concepts existed in our country?

1. BIP concept(Defect-Free Manufacturing of Products) This system was based on a mechanism for activating participants production process, stimulating them to identify and eliminate not product defects, but their causes. After re-presenting the product, the worker lost his bonus.

2. CANARSPI concept(Quality, Reliability, Resource from the First Products) Was introduced at Gorky aircraft factory. Recognized as the best in the country, the system was based on the following principles:

· versatility (can be used in other industries)

· comprehensive product quality assurance

· conducting research aimed at improving product quality and developing the enterprise’s development services

· organization of comprehensive accounting of the quality of products

· concentration on product quality at the development stage

· involving consumers in product improvement

1. NORM concept In the mid-1960s. at the Yaroslavl motor plant "Avtodizel" the NORM system was introduced, in which one of the most important technical parameters was taken as a quality criterion - service life before the first overhaul. Particular attention was paid to the development of design and technology that ensures an increase in the technical level and quality of the engine. In the NORM system, the main elements of the Saratov and Gorky product quality management systems were used and developed.

2. KSUKP concept(Comprehensive Product Quality Management System)

In the first half of the 1970s. As a result of a joint research and production experiment between enterprises of the Lvov region, the All-Russian Research Institute of Standardization of the USSR State Standard and the scientific and production association "Sistema", a comprehensive product quality management system was developed and tested.

the main objective system was to ensure high and sustainable growth rates in the quality of products manufactured by the enterprise due to:

· creation and development of new high-quality types of products;

· timely production launch new products;

· discontinuation of obsolete products;

· improving the quality indicators of manufactured products by improving and modernizing them.

What was the specificity Russian experience quality management?

The specificity of quality management in Russia was that efficient systems Quality management systems were created at enterprises of the military-industrial complex (MIC). It was in the military-industrial complex that methods of quality assurance were widespread at the stages of research and design of new products, statistical quality control using control charts, and special standards. In the depths of the military-industrial complex were born KSUKP ( complex systems product quality management, including automated ones).

QMS: Management of non-conforming products.

Methodology for managing nonconforming products.

1) we determine the products included in the scope of application of the QMS, 2) we determine what the corresponding products are, 3) we determine which control mechanisms are applicable to which products (can be in the form of a table), 4) we describe in detail these mechanisms as applied to specific products: who is responsible for what, what powers they have, what they do.

For now we have the products.

What can we do to ensure product conformity when a non-conformity is found?

The first is obvious: fix it. those. make the correction in terms of ISO 9000. But this is not always possible.

Then the second is to evaluate the extent to which the nonconformity interferes with the intended use of the product and, if acceptable, allow the deviation. If possible, permission to deviate is also requested from the consumer, whether he agrees. The customer, having analyzed exactly which functions will be missing, may consider this quite acceptable and give permission.

If neither the first nor the second is possible, then the third option remains: change the original use or abandon the use of the product altogether.

It is obvious that a procedure for managing nonconforming products cannot be fully developed if

 the products themselves, the quality of which is managed within the framework of the QMS, have not been defined,

 it is not defined what conforming products are, because this is equivalent to not defining non-conforming products.

From listening experience: if I cannot understand from the quality manual what specific products are included in the scope of the QMS, then I may not even look at the procedure for managing non-conforming products, guaranteeing in advance that it is formal.

Control mechanisms in each of the three cases:

Change products (correction)

 indicate the method for identifying non-conforming products and the person responsible for this identification,

 indicate the person responsible for preventing the release and delivery of identified non-conforming products and his powers,

 indicate the person responsible for the correction,

 establish a re-control procedure and the person responsible for its implementation,

 establish in what form a record is made of the nature of the nonconformity and the decision to correct it.

Change requirements

 indicate the person authorized to give permission for deviation and his powers, as well as establish the procedure for such permission, including identifying the person authorized by the consumer to give permission for deviation,

 establish in what form a record is made of the nature of the nonconformity and permission to deviate.

Change Application

 establish the person responsible for preventing the initial use of non-conforming products by the consumer and his powers, as well as the procedure for such prevention,

 establish in what form a record is made of the nature of the nonconformity and actions to prevent initial application.

Products at the consumer.

Obviously, in this situation, none of the mechanisms described above are applicable: the products are out of our control. All we can do in this case is to take actions that reduce the negative consequences or the risk of such consequences for the consumer. As an example here we can give everyone well-known companies on car recalls.

7.3.1. Design and development planning

The organization must plan and manage the design and development of products.

During design and development planning, the organization should determine:

a) design and development stages;

b) carrying out analysis, verification and validation appropriate to each stage of design and development;

c) responsibility and authority for design and development.

The organization must manage the interaction of the various design and development groups to ensure effective communication and clear distribution of responsibilities.

Planning results should be updated, if necessary, as design and development progress.

7.3.2. Design and Development Inputs

Input data related to product requirements must be defined and records maintained (4.2.4).

Inputs should include:

a) functional and operational requirements;

b) relevant legal and other mandatory requirements;

c) where possible, information taken from previous similar projects;

d) other requirements important for design and development. Input data must be analyzed for sufficiency. Requirements must be complete, unambiguous and consistent.

(Changed edition. Amendment No. 1).

7.3.3. Design and development output

The outputs of design and development shall be presented in a form that allows verification against the design and development input requirements, and shall be formally approved prior to their subsequent use.

Design and development outputs should:

a) meet the design and development input requirements;

b) provide relevant information on procurement, production and service;

d) determine the characteristics of the product that are essential for its safe and correct use.

(Changed edition. Amendment No. 1).

7.3.4. Design and development analysis

At appropriate stages, a systematic analysis of the design and development should be carried out in accordance with the planned activities (clause 7.3.1) in order to:

a) assessing the ability of the design and development results to satisfy the requirements;

b) identifying any problems and making suggestions for necessary actions. Participants in such a review should include representatives from departments relevant to the design and development stage(s) being analyzed. Records of the analysis results and all necessary actions must be maintained in working order (clause 4.2.4).

(Changed edition. Amendment No. 1).

7.3.5. Design and development verification

Verification shall be carried out in accordance with planned activities (clause 7.3.1) to ensure that the design and development outputs meet the input requirements. Records of verification results and all necessary actions must be maintained in working order (clause 4.2.4).

7.3.6. Design and development validation

Validation of the design and development shall be carried out in accordance with the planned activities (clause 7.3.1) to ensure that the resulting product meets the requirements for its specified or intended use, if known. Where practicable and appropriate, validation should be completed prior to delivery or use of the product. Records of validation results and all necessary actions must be maintained (clause 4.2.4).

(Changed edition. Amendment No. 1).

7.3.7. Project and development change management

Design and development changes must be identified and records maintained. Changes must be reviewed, verified and validated as appropriate, and approved before implementation. Review of design and development changes should include an assessment of the impact of the changes on components and products already delivered.

Records of the results of the change analysis and any necessary actions must be maintained (clause 4.2.4).

(Changed edition. Amendment No. 1).

"GOST R 57189-2016/ISO/TS 9002:2016. National standard of the Russian Federation. Quality management systems. Guidelines for the application of ISO 9001:2015 (ISO/TS 9002:2016, IDT)" (approved by Order of Rosstandart dated 10/25/2016 N 1499-st)

8.3.3 Design and development inputs

Determining the inputs for a specific design and development project is one of the activities that should be included in the design and development plan. These inputs must be unambiguous, complete, and consistent with the requirements that define the characteristics of the product or service. These should include:

a) functional and performance requirements determined by customers, market needs or the organization;

b) information from previous similar design and development activities (which may improve performance and enable the organization to develop good practices or avoid mistakes);

c) legal and regulatory requirements that relate directly to the product or service (eg safety regulations, food hygiene laws) or to the production of that product or service (eg manufacturing process practices, transportation or other delivery techniques);

d) voluntary standards or rules of thumb that the organization has adopted (for example, industry codes, health and safety standards);

e) potential consequences failures due to the nature of products and services; such failures may range from potentially fatal (eg, poor security planning traffic can lead to accidents on occasion) to factors that lead to loss of customer satisfaction (for example, unstable ink on fabric leads to loss of color or staining).

Input data related to product requirements shall be defined and records shall be maintained (4.2.4).

Inputs should include:

a) functional and performance requirements;

b) relevant legal and other regulatory requirements;

c) where possible, information drawn from previous similar projects;

d) other requirements important for design and development.

Input data must be analyzed for sufficiency. Requirements must be complete, unambiguous and consistent.

Design and development output

The design and development outputs shall be in a form suitable for verification against the design and development input requirements and shall be formally approved prior to their subsequent use.

Design and development outputs should:

a) meet design and development input requirements;

b) provide relevant information on procurement, production and services;

d) determine the characteristics of the product that are essential for its safe and correct use.

NOTE Production and maintenance information may include details of product preservation.

Design and development analysis

At appropriate stages, a systematic review of the design and development shall be carried out in accordance with the planned activities (7.3.1) in order to:

a) assessing the ability of the design and development results to satisfy requirements;

b) identifying any problems and making suggestions for necessary actions.

Participants in such a review should include representatives from departments relevant to the design and development stage(s) being analyzed. Records of the results of the analysis and all necessary actions shall be maintained (4.2.4).

Design and development verification

Verification shall be carried out in accordance with planned activities (7.3.1) to ensure that the design and development outputs meet the input requirements. Records of the results of verification and all necessary actions shall be maintained (4.2.4).

Design and development validation

Validation of the design and development shall be carried out in accordance with the planned activities (7.3.1) to ensure that the resulting product meets the requirements for its specified or intended use, if known. Where practicable, validation should be completed prior to delivery or use of the product. Records of the results of validation and all necessary actions shall be maintained (4.2.4).

Project and development change management

Design and development changes must be identified and records maintained. Changes must be reviewed, verified and validated as appropriate, and approved before implementation. Review of design and development changes must include an assessment of the impact of the changes on components and products already delivered. Records of the results of the change analysis and any necessary actions shall be maintained (4.2.4).

Procurement

Procurement process

The organization shall ensure that purchased products comply with established purchasing requirements. The type and degree of control applied to the supplier and purchased product should depend on its impact on subsequent stages life cycle products or finished products.

The organization shall evaluate and select suppliers based on their ability to provide products in accordance with the organization's requirements. Criteria for selection, evaluation and re-evaluation should be developed. Records of the results of the assessment and any necessary actions resulting from the assessment shall be maintained (4.2.4).

Purchasing information

The purchasing information must describe the products ordered, including, where appropriate, the requirements:

a) to the official approval of products, procedures, processes and equipment;

b) to the qualifications of personnel;

c) to the quality management system.

The organization must ensure adequacy established requirements to purchases before they are communicated to the supplier.