曝光臺 注意防騙 網曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

generation of test requirements and independent performance of test specifications. The extent of independence is shown in Table 1 of section 7.1. vii)Any tools used to support testing maintain the integrity of the results and the operational software. viii)Procedures or tools were used to ensure that testing was carried out as required in the test procedure and that the results satisfy the test criteria. ix) Test guidance, procedures, standards and tools were defined and adhered to. x) The test environment and procedures were recorded accurately.
xi) For AEL 1 to 3, any differences between the operational and test environments are identified, and the impact on test results assessed.
xii)For AEL 4 & 5, tests are made on a configuration identical to the operational system.
xiii)The complexity and input domain of a software safety requirement was analysed and used to support the selection of normal and abnormal test data.
xiv)The consequences of failing to meet a software safety requirement have been analysed and have been used to support the selection of normal and abnormal test data.
xv)All faults and their implied undiscovered faults, discovered during testing, have been analysed and that their existence does not adversely affect safety.

7.3.2 Backing Evidence from Field Service Experience
Arguments and evidence should be available that show:
i)  The proposed software and the software for which the field service experience is available are identical or sufficiently similar.
ii) The proposed operational environment and the operational environment for which the field service experience is available are identical or sufficiently similar.
iii) The proposed hardware and the hardware for which the field service experience is available are identical or sufficiently similar.
iv) All attributes of the software safety requirements being justified from field experience have been exercised in the deployed software.
v) A Defect Reporting, Analysis and Corrective Action System (DRACAS) is in place for the deployed software, and is operated in a reliable manner, adequate to support the claims made for the software.
vi) The field service records are correct and complete.
vii)Procedures and tools were used to support the analysis of field service experience, to ensure that analysis has been carried out as required in the analysis procedure, and that the results satisfy the analysis criteria.
viii)The procedures and tools used to support the analysis of field service experience were verified and validated.
ix) Any tools used to support analysis maintain the integrity of the results and the operational software.
x) Sufficient experience exists to demonstrate that the acceptance criteria for each attribute of the software safety requirement have been met.
xi) For all reported failures of an attribute in the software architectural unit, the underlying fault has been corrected, or that the fault is not relevant because it has no safety impact.
xii)All field reports identifying failures of the attributes, of the software safety requirements being justified from field experience have been made available.

7.3.3 Backing Evidence from Design Analysis
Arguments and evidence should be available which show that:
i)  The design notations are capable of supporting the identification of all attributes that are to be analysed.
ii) The analytic methods and techniques used are appropriate for the attributes of the software safety requirement.
iii) The analysis notations are appropriate to the problem domain and representation and allow an adequate analysis of the design.
iv) The analysis techniques have been applied by adequately qualified and experienced staff.
v) Assumptions used in the analysis (e.g. about the environment, hardware, operating system and other interfaces) have been validated.
vi) Models or other abstractions used in the analysis are an adequate representation of the software design.
　
中國航空網 m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：CAP 670 Air Traffic Services Safety Requirements 1(74)