EN50128中的基本要求

SIL2 认证的中对于信号子系统中软件开发质量保障的标准 EN50128 标准的基本要求摘录。

文档要求

• 5.3.2.7 对于每个文档，应根据唯一的参考编号以及与其他文档的定义和记录关系提供可追溯性。

• 5.3.2.8 每个术语、首字母缩略词或缩写在每个文档中应具有相同的含义。如果由于历史原因无法做到这一点，则应列出不同的含义并给出参考文献。

• 5.3.2.9 除与原有软件有关的文档（见7.3.4.7）外，每份文档应按照以下规则编写：
• • 它应包含或实施与其具有继承关系的先前文档的所有适用条件和要求;
• • 它不得与前一份文档相抵触。
• 5.3.2.10 每个项目或概念应在每份文档中使用相同的名称或描述。

通用要求

• 6.5.4.14 在验证安全相关系统时，应将要求的可追溯性作为重要考虑因素，并应提供方法，以便在生命周期的所有阶段进行证明。

• 6.5.4.15 在本欧洲标准的背景下，并在适合指定软件安全完整性级别的程度上，可追溯性应特别解决
• a) 将需求追溯到设计或满足这些要求的其他对象
• b) 设计对象的可追溯性到实例化它们的实现对象
• c) 设计对象的可追溯性到实例化它们的实现对象

• 可追溯性应成为配置管理的主题

• 6.5.4.16 在特殊情况下，例如预先存在的软件或原型软件，可以在代码的实施和/或记录之后，但在验证/确认之前创建可追溯性。在这些情况下，应证明验证/确认与所有阶段的可追溯性一样有效。

• 6.5.4.17 无法充分追溯的要求、设计或实施对象应证明与系统的安全性或完整性无关。

验证

1. 软件架构、接口和设计规范的内部一致。 软件架构、接口和设计规范在一致性和完整性方面是否充分满足软件要求规范。
2. 规范与质量保证进程使用了相同的术语。对于规范这个文档使用了唯一的文件编号（文档编号: xxx，版本Vxxx），并具有与其他文档的定义和记录关系（规范中章节1.5. 与其它开发任务/文档的关系），以提供可追溯性。
3. 每个术语、首字母缩略词或缩写在每个文档中应具有相同的含义。见规范中章节1.6. 术语和缩写词。
4. 它应包含或实施与其具有继承关系的先前文档的所有适用条件和要求;也不与前一份文档抵触。
5. 每个项目或概念应在每份文档中使用相同的名称或描述。见规范中章节1.6. 术语和缩写词。
6. 在规范中，可追溯性得到满足。见规范中章节 6. 可追溯性分析。
7. 规范中没有已经预先存在的软件，所以不用为其创建可追溯性和验证其可追溯性。

验证报告要求

• 6.2.4.12 任何软件验证报告均应由验证员负责，根据输入的文档编写。为了清晰和方便起见，可以对这些报告进行分区，并应遵循软件验证计划。6.2.4.13 中的要求是指软件验证报告

• 6.2.4.13 每份软件验证报告应记录以下内容：
• a) 已验证项目的身份和配置，以及验证者名称
• b) 不符合规格要求的物品;
• c) 对问题适配的组件、数据、结构和算法。
• d) 检测到错误或缺陷;
• e) 软件验证计划的实现或偏离（如果出现偏差，验证报告应说明偏差是否严重）;
• f) 假设,如果有的话;
• g) 核查结果摘要

测试规范要求

• 6.1.4.4 每个测试规范应记录以下内容
• a) 测试目标
• b) 测试用例、测试数据和预期结果;
• c) 要执行的测试类型;
• d) 测试环境、工具、配置和进程
• e) 判断测试完成情况的测试标准;
• f) 要达到的测试覆盖率的标准和程度
• g) 参与测试过程的人员的角色和职责
• h) 测试规范涵盖的要求
• i) 软件测试设备的选择和使用;

测试报告要求

• 6.1.4.5 测试报告应按如下方式制作：
• a) 测试报告应当载明测试人员姓名，说明测试结果以及是否满足测试规范的测试目标和测试标准。故障应记录和总结;
• b) 测试用例及其结果应记录，最好以机器可读的形式记录，以供后续分析;
• c) 测试应是可重复的，并在可行的情况下通过自动方式进行;
• d) 应验证用于自动执行测试的测试脚本;
• e) 应记录所有涉及项目（使用的硬件、使用的软件、使用的设备、设备校准以及测试规范的版本信息）的身份和配置;
• f) 应提供对测试覆盖率和测试完成情况的评估，并注明任何偏差

确认报告

• 6.3.4.8 确认结果应记录在软件确认报告中。

• 6.3.4.9 确认者应检查验证过程是否完成。

• 6.3.4.10 软件确认报告应完整说明已验证的软件基线。

• 6.3.4.11 确认报告应明确指出软件中任何已知的缺陷,以及这些缺陷可能对软件使用产生的影响