功能安全管理之需求管理（标准篇）

需求提清楚了，项目开发起来神清气爽。需求提不清楚，项目开发起来一团乱麻。可见需求不仅得定义好还得管理好。

ISO26262中有条很清晰的需求链条，从整车层面对应的概念阶段到相关项零部件系统层面，再到零部件开发的软、硬件层面都有对应的开发需求，并要形成对应需求规范，标准要求这些需求要具备可追溯性。

根据上方描述，安全相关需求的追溯链条为：SG->FSR->TSR->HSR/SSR，对应需求结构追溯示意图如下。

从上图我们进入到本篇的主题——需求管理。

上方安全需求结构可进一步简化如下。

Q: 单从安全需求的追溯链条来看，整个需求链条只关注需求本身自上而下的单向追溯，那大家经常听到的双向可追溯性是怎么一回事？

关于这个问题我们先看看标准中对需求管理有哪些要求。

The functional safety assessor considers if requirements management (see ISO 26262-8:2018, Clause 6), including bidirectional traceability, is adequately implemented. (refer ISO26262_part2, 6.4.12.7)

Jet Note: 当进行安全评估/审核时，评估师/审核员必然会关注被审组织是如何实施需求管理的，需求是否做到了可追溯，包括双向可追溯，这贯穿了审核的整个过程。

To achieve the characteristics of safety requirements listed in 6.4.2.4, safety requirements shall be specified by an appropriate combination of: (refer ISO26262_part8, 6.4.1)

a) natural language; and

b) methods listed in Table 1.

Jet Note: 描述需求的方式有自然语言和非自然语言两种，自然语言就是大家现在所看到的具备一定语法和语义的文字语言，非自然语言如上表中列出的几种，是一种用图形化、公式化的表达形式，比如流程图、算法模型、结构框图等，有时往往是多种描述相结合能使需求更清晰、易懂。

如下关于VCU快速上下电需求的描述，单看左边需求本身描述可能会比较吃力，但配上右边对应的状态转换图则犹如对需求解释的“神助攻”。

Safety requirements shall be unambiguously identifiable as safety requirements. (refer ISO26262_part8, 6.4.2.2)

Jet Note: 安全的需求只是项目开发过程中的一小部分需求，如何让这小部分需求在项目中能轻松识别，标准建议安全需求的文档单独输出、管理，这也是目前大部分公司的工作方式，功能安全由专人管理与项目经理对项目实施并行管理。但标准并不强制要求安全需求与常规项目需求分开不同文档输出，成熟度较高的组织可以将安全和非安全需求都体现在一份文档里，只要安全需求能被明显识别即可。

Safety requirements shall inherit the ASIL from the safety requirements from which they are derived, except if ASIL decomposition is applied in accordance with ISO 26262-9. (refer ISO26262_part8, 6.4.2.3)

Safety requirements shall be allocated to the item or element which implements them. (refer ISO26262_part8, 6.4.2.3)

Jet Note: 不管是安全需求还是非安全需求，需求最终都要分配到对应层级架构中不同的模块，被分配了需求的模块承担着对应需求功能的实现。

Safety requirements shall have the following characteristics: (refer ISO26262_part8, 6.4.2.4)

a) unambiguous;

b) comprehensible;

c) atomic (singular);

d) internally consistent;

... ...

Jet Note: 标准列的这些关于需求的属性非常全面以至于有点太过“科学”，实践过程中大家最关心的需求的两大问题是“颗粒度”和“完整性”。

Q: 需求写到什么程度才合适？写成这样可以吗？需求写多少或怎样写才算完整？目前写的这些需求够了吗？

关于颗粒度的问题，标准也只是说要与对应层级的架构相适应，即需求要和架构一样具有层次化。而完整性标准推荐通过分析来验证设计的完整性，但这些要求/解释并不足以很好地解答这两个问题，或者说这两个问题如何落地光看标准的解释难以下手。

其实颗粒度的问题没有标准答案，如果非要说有那标准的说法就可以说是标准答案。我个人实践过程中也是基于架构设计层次对需求进行层次化描述的，个人觉得需求如果能与架构对应实现层次化(hierarchy)，那就是最佳的表现形式。

如果从系统到软、硬件的详设需求都长一个样，光从内容来看不能说错但却不能很好地展现设计思路，即这条需求是如何分解出另外几条需求的这个思路体现不出来。

另外，软、硬件的需求如果只是系统需求的简单拆分，除非系统需求已经过全面的验证且写得非常细致，不然这样的软、硬件需求的完整性是有问题的。毕竟软、硬件层级的设计有其自己的一些设计考量，而且软、硬件层级的架构较系统架构也更加细化，需求描述中的主语应对应各自架构里的要素，所以其对应需求的颗粒度理应在系统需求的基础上更加细致且全面。

对于需求完整性(completeness)这个问题，也是很多人的困扰，你怎么知道需求写的够不够？

够不够的问题其实是一个需自我证明的问题，个人实践和培训过程中习惯用“输入-处理-输出”的方式来对某个功能进行需求编写，我称之为“需求编写三板斧”。

理清楚功能的输入输出关系，结合功能自身目的来写需求基本能保证所编写需求的完整性，由于输入和输出会与其他功能部分重叠，在整体需求完善之后有个整理的过程，尤其是任务分工时最终进行需求汇总时都会有个整理的过程，再结合分析、评审等手段对需求的完整性进行验证，经过分析及内部/外部多层次的审核对当前需求都没有提出新的意见，那当前基线的需求就可以自证是完整的。

Safety requirements shall have the following attributes: (refer ISO26262_part8, 6.4.2.5)

• a unique identification remaining unchanged throughout the safety lifecycle;
• a status; and
• an ASIL.

Jet Note: 需求要ID化并唯一，需求的状态可以有多种表现形式，如“reserved(预留的)”、“assumed(假设的)、“draft(草稿)”、“reviewed(评审过的)”等，安全需求要有对应的ASIL等级标识这是基本的要求，这也是用于区分安全和非安全需求的一个方式。

The set of safety requirements for an item, an element, which are derived from one or more safety goals shall have the following properties: (refer ISO26262_part8, 6.4.3.1)

• hierarchical structure;
• organizational structure according to an appropriate grouping scheme;
• completeness;
• external consistency;
• no duplication of information within any level of the hierarchical structure; and
• maintainability

Jet Note：需求要层次化、唯一化、类别化，并保证完整性、外部一致性及可维护性，这些都是标准非常概括性的要求，这些特性要求在实践过程中本身并不是什么难事，比如用excel表格管理和编写需求时，上游需求下面紧接着写下游需求就能体现层次结构且具备可维护性。同样用Excel对需求基于功能进行分类编写，如电源管理的需求单独一页，并在ID中带电源管理的标识就能体现类别化。编写需求最大的问题还是上面提到的“颗粒度”和“完整性”这两项，如何比较完美地做好这两项见上文提示。

Safety requirements shall be traceable with a reference being made to: (refer ISO26262_part8, 6.4.3.2)

• each source of a safety requirement at the next upper hierarchical level;
• each derived safety requirement at the next lower hierarchical level, or to its realisation in the design; and
• the verification specification in accordance with 9.4.2.

Jet Note: 从标准的这几条要求来看，需求的可追溯体现在需求的上、下游追溯，注意上面第二项关于需求下游追溯中描述到“realisation in the design”，即需求到设计实现层面的追溯，比如需求到架构、需求到图纸、需求到代码都得可追溯，说到这那上面提到的“bidirectional traceability”是不是得到了体现。再看上面第三项，可追溯还要求需求和验证规范之间要建立可追溯，即需求到测试用例，用例到测试结果之间是要可追溯的，这也是需求的“bidirectional traceability”的体现。另外，可追溯性做好了，需求间的一致性(consistency)也会得到保障。

An appropriate combination of the verification methods listed in Table 2 shall be applied to verify that the safety requirements comply with the requirements in this clause and that they comply with the specific requirements on the verification of safety requirements within the respective parts of the ISO 26262 series of standards where safety requirements are derived. (refer ISO26262_part8, 6.4.3.3)

Jet Note: 上表中提到的走查（walk-through）和检查（inspection）两种验证方式我们在《ISO26262的功能安全管理（二）》ISO 26262的功能安全管理（二）-CSDN博客一文中有详细的介绍。这里我们讲讲标准另外两种需求验证方式，半形式化验证和形式化验证。

这两种验证方式都可以用可执行的模型来实现，实际过程中如何落地呢？比如搭建的仿真电路模型来验证硬件设计的某条需求。基于模型的测试，如通过MIL测试来验证模型与算法的一致性和正确性，当然也就验证了模型开发的需求。用公式、定理来证明设计的正确性也是一种典型的形式化验证方式，这个在代码验证中比较常用，用做证明题的方式证明设计满足对应的公式、定理，从而证明其满足对应的需求。

Safety requirements shall be placed under configuration management in accordance with Clause 7 to maintain consistency throughout the safety lifecycle. (refer ISO26262_part8, 6.4.3.4)

Jet Note: 需求的管理包括配置管理和变更管理，这些都要为保证需求在整个生命周期的一致性服务，这个不难理解，比如产品A样到B样功能发生了些变更，那涉及的变更的功能对应需求也会发生变更，这时从A样转到B样时要同步配置为变更后的需求，如果往下释放的需求文件还是A样的，那自然就导致了B样阶段需求的不一致，这是需求基线没管理好导致的，所以变更管理和配置管理往往是实行联动管理。

以上就是标准对于需求管理的要求，正如上文所述个人觉得需求的编写和创建过程中“颗粒度”和“完整性”是困扰大家的两大问题，如果能把需求的这两个问题“完美地”处理好，那需求的其他属性/特性的满足及实现都是水到渠成的事。

参考：

[1] ISO 26262-2:2018, Management of functional safety

[2] ISO 26262-8:2018, Supporting processes

---

  更多精彩内容欢迎关注微信公众号：功能安全落地漫谈