ISO 26262软件安全需求，它处于技术安全设计与软件开发中间的位置，需要将分配给软件的那些安全职责，转变成能够去实现、测试和追踪的具体要求。这些需求既不能仅仅是“保证安全”“及时处理故障”这种模糊的说法，也不应该太早去限定函数和代码的结构。在编写的时候，需要将触发条件、预期行为、时间限制、异常处理和验证依据都写明白。

　　一、ISO 26262软件安全需求怎么编写

　　软件安全需求，通常是从技术安全要求、系统架构，以及软硬件接口要求里面派生出来的。每一条需求都需要有明确的来源，并且要分配到具体的软件组件上去，不能仅仅根据开发过程中的经验，临时去增加安全方面的功能。

　　1、记录需求来源和基本属性

　　在【软件安全需求规范】中记录需求编号、ASIL等级、上层来源、分配对象和验证方法。

　　一项技术安全要求，有时候需要拆分成好几条软件需求，比如信号监控、故障确认、降级控制，还有状态上报这些。拆分完之后，还是要保留它们共同的来源，这样才能避免软件只做了故障检测，却把故障响应或者诊断信息的输出给漏掉了。

　　2、把软件行为写得可验证

　　需求里面应该写清楚，在什么条件下会被触发，软件要去执行什么样的动作，允许多长的响应时间，以及从外部能够看到什么样的结果。举个例子，不能只写一句“软件应检测通信故障”，还要把超时的时间、连续丢帧的次数、故障确认的条件，还有确认之后的输出状态都写进去。像阈值、次数、精度和时间这些，应当尽可能地用数字明确下来，少用“适当的”“尽快的”“在必要时”这一类很难形成通过准则的词语。

　　3、覆盖异常和边界条件

　　除了正常的输入情况之外，还需要把信号超出了边界、数据僵住不再变化、通信断掉、初始化没有成功、任务执行超时，以及存储的数据遭到损坏这些情况都考虑进去。在需求里面，应当说明软件会怎么去识别异常、在什么时候确认故障、随后进入到哪一种状态，还有当故障消失以后，是不是允许自己恢复回来。如果安全机制本身也失效了，那么也要有相应的处理要求。

　　二、ISO 26262软件安全需求怎么验证完整性

　　验证完整性这件事情，并不是去检查需求的数量够不够多，而是要去确认上层的要求有没有被遗漏、运行的各种场景是不是都被覆盖到了，而且需求与需求之间，不能有互相矛盾、重复，或者根本无法去验证的问题。

　　1、建立双向追踪关系

　　在【需求追踪矩阵】中关联技术安全要求、软件安全需求、软件架构要素和验证用例。

　　所谓向下追踪，是用来确认每一条上层的安全要求，都已经被软件给承接住了；而向上追踪，则是用来把那些找不到安全来源的设计功能给找出来。如果某一条软件安全需求，找不到与之对应的实现组件，也找不到验证用例，那就说明这条需求的链路，还没有完全闭合。

　　2、按照运行场景检查覆盖

　　在做评审的时候，需要分别对上电初始化、正常运行、降级、故障恢复、关机，还有诊断这些模式进行检查。如果只是按照需求的编号，从头到尾地读一遍，是很容易把模式切换，还有好几个异常同时发生的情况给漏掉的。另外，还可以围绕输入、输出、内部状态、外部接口，以及安全机制这些方面反过来查一遍，去确认那些关键的对象，在正常状态和异常状态下面，是不是都有明确的行为描述。

　　3、检查需求之间是否一致

　　同一个故障，不可以在一条需求里面要求马上进入到安全状态，而在另外一条需求里面，又允许它继续运行一段比较长的时间。故障确认的时间、状态的优先级，还有恢复的条件，这几样也都要保持一致。如果一条需求里面同时包含了监控、记录、报警，还有降级等好几种行为，那么最好把它拆分成几个互相关联的独立需求，这样更容易分别去实现和验证。

　　三、软件安全需求验证怎么落实

　　需求在评审通过了以后，还需要提前把验证的层级、验证的环境，还有通过的准则，都确定下来。如果一直等到软件集成那个阶段，才去考虑要怎么验证，那就很可能会发现，故障根本注入不进去、内部的状态也观察不到，或者是测试所需要的接口，事先并没有预留出来。

　　1、为需求选择验证方法

　　在【需求属性】中注明采用评审、分析、静态检查、单元测试、软件集成测试或软硬件集成测试进行验证。

　　像接口的格式和设计上的一些约束，是可以通过评审或者静态检查去确认的；而状态的转换、响应的快慢，还有故障的处理，这些一般就需要用动态的测试来验证。验证的方法，应当和需求里面所描述的内容对应起来，不能把所有的需求，全都不加区分地标记成用测试来验证。

　　2、同步处理需求变更

　　需求在被修改了之后，需要重新去检查软件的架构、接口、代码、安全分析，还有测试用例。如果只修改了需求的正文，却不把下游的那些工作产品同步更新过来，就会造成追踪关系从表面上看是完整的，但实际的内容已经对不上了。变更的记录里面，还应当写清楚修改的原因、影响的范围，以及重新验证之后的结果。

　　3、保留完整验证证据

　　验证的记录里面，应当包含需求的编号、软件的版本、测试的条件、输入进去的数据、预先期望得到的结果，还有实际跑出来的结果。在评审当中发现的参数缺失、接口上还有争议的地方，以及那些还没有确认下来的假设，这些也都要记录下由谁来负责，以及关闭的条件，不能因为文档已经发布了，就自动把它们当成已经解决了的问题。

　　总结

　　ISO 26262软件安全需求的编写，重点在于要把上层传递下来的安全职责，转化成明确的、能够去实现的、也可以进行验证的软件行为。在验证完整性的时候，需要把双向的追踪、场景的覆盖、需求之间的一致性，还有验证的证据这几样结合起来进行检查。只有当每一条需求，都能找得到它的来源、在什么地方被实现了、用什么方法来验证，以及验证的结果记录，这样一整套软件安全需求的链路，才能算是完整的。