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

f)  If more than one source of direct evidence is supplied for the attribute of a software safety requirement, backing evidence should be available for each of the chosen sources.
g) Unless an argument can be made that the assurance can be achieved by other means:
i)  Test evidence should be available for each attribute.
ii) Where Field service experience exists, it should be analysed and available as evidence.
iii) If statistical testing or field experience is used in a Primary argument then this should be demonstrated at the 95% confidence level.
iv) If systematic tests are used to demonstrate that a requirement is met, all tests must succeed.
h) Any evidence (e.g. from test, field service or analysis) that contradicts the demonstration of the software safety requirement should be explicitly identified. If the contradiction cannot be resolved, the software safety requirement should not be considered satisfied.
7.2  Direct Evidence for Requirements Satisfaction (all attributes) For Direct evidence to be acceptable it must comply with the following requirements:
7.2.1  Direct Evidence from Testing
a) Arguments and evidence should be available that show:
i)  Tests were specified for all the relevant behavioural attributes of each safety requirement.
ii) Testing was carried out to show that the acceptance criteria for each applicable attribute have been met.
iii) The results of the testing show that the specified acceptance criteria for each applicable attribute for each software safety requirement has been met.
b) For direct evidence of testing to be credible it should include test specifications, test criteria, test results, an analysis of test results, and an analysis of faults discovered during testing.

7.2.2  Direct Evidence from Field Service Experience
a) Arguments and evidence should be available that show:
i)  An analysis process, with pass/fail criteria, was specified for each attribute of the software safety requirement that is being justified from field experience.
ii) The analysis of the field service records shows that the criteria for each attribute of the software safety requirement being justified from field experience have been satisfied.
b) For direct evidence from field service experience to be credible, all of the details relevant to the argument being made (e.g. of length of service, history of modifications, list of users) should be included.

7.2.3  Direct Evidence from Design Analysis
a) Arguments and evidence should be available that show:
i)  An analysis process, with pass/fail criteria, was specified for each attribute of the safety requirement that is being justified by analysis of design.
ii) The specified acceptance criteria for each attribute of the software safety requirement being justified by analysis of the design, have been satisfied.
NOTE:  Analytic arguments usually rely on the source code and therefore, for high AELs, there should be a demonstration that the object code is a correct translation of the source code.
7.3  Backing Evidence for Requirements Satisfaction (all attributes) For Backing evidence to be credible it should comply with the following:
7.3.1  Backing Evidence from Testing Arguments and evidence should be available that show: i) The test methods and techniques used are appropriate for the attributes of the software safety requirement under consideration. ii) Procedures and tools used to support testing have been verified and validated to a level appropriate for the AEL. iii) The tests are sufficiently thorough and are representative of the demands that will be made on the software when it is in service. iv) The test criteria are a complete and correct interpretation of the software safety
requirements. v) The test cases provide adequate coverage of the input domain. vi) Testing was performed independently from design, e.g. independent
　
中國航空網(wǎng) m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：CAP 670 Air Traffic Services Safety Requirements 1(73)