识别高质量需求验证的一个重要部分是设计的鲁棒性- 254。
可以理解的是,硬件设计一架飞机,甚至任何安全关键应用程序,必须强大。我也相信所有的工程师希望验证他们的设计尽可能彻底。然而,有限制因素;最显著的高复杂性的设计。因为我们无法发现和验证设计对所有异常情况,主要问题是:鲁棒性验证真正完整是什么时候?
随机鲁棒性的本质
对鲁棒性验证测试场景总是包含许多输入稳定问题,如错误的价值观,缺乏或失去价值,意想不到的时间和出乎意料的切换。当然有一个重要的随机因素,但它不应该让我们粗略的说这部分验证通过应用少或更高级的随机化方法。任何设计的鲁棒性,特别是对于人类生命在哪里潜在风险的项目,不能通过检查的结果随机生成的场景。它必须是原始设计的一部分。
RTCA / - 254
机载电子硬件”的“设计保证指导文档并没有明确解决鲁棒性测试。然而,两种补充剂——“8110.105 FAA秩序”和“EASA认证的备忘录”——明确演示的鲁棒性,申请人还应定义基于需求的测试。换句话说,预计不正常操作条件被捕获和记录作为派生需求。
我们需要多少“健壮性要求”?
有额外要求的鲁棒性验证并不能解决上述问题,所以真正的问题是:有多少“健壮性要求”就够了吗?
捕获需求,必须分析系统规范。我们需要更深入地观察非功能性,质量和性能的要求。第二个“健壮性要求”的重要来源是任何出乎意料的行为的系统设计应考虑可能导致功能退化和记录作为派生需求。
从鲁棒性测试用例到更高质量的要求
鲁棒性验证测试用例将不是来自“健壮性要求”。他们也需要来自常规功能需求;这种组合,可以揭示不足的功能规范。这是其中的一个情况下我真的欣赏RTCA /做- 254指导和定义的流程,因为产品不能安全没有最高质量的要求。
鲁棒性硬件验证
做- 254要求硬件需求验证在实际硬件和应该做的操作环境(例如LRU, CCA)。然而,它可能是非常困难甚至无法核实一些鲁棒性测试用例的操作环境。
幸运的是,我们可以简化这个任务通过使用独立的测试设备- 254 / CTS吗。该设备使我们能够验证所有功能需求(包括鲁棒性)在目标设备和真实速度。所有可没有在测试程序通过重用长椅准备模拟测试。此外,- 254 / CTS吗提供的功能来执行验证正常和不正常供电和时间条件。
|
|
|
|
|
|
|
|
|
留下一个回复