功能安全标准第8部分的支持过程中，将需求的说明与管理单独作为一个章节提出来。标准将功能安全提出的需求说明与管理过程的目的，概括为如下两点；
一是， 从需求特征和属性两个方面保证安全需求的正确说明。 二是，保证安全需求在开发过程中的一致性管理。 说白了就是提出了对需求的具体表达与管理的要求。而ASPICE并没有在支持过程中单独提出需求的说明与管理过程，但是，却在系统和软件层面提出了很多具体的需求过程实践，来帮助我们进行需求的挖掘与分析。将两份标准结合在一起看，我们就会发现ASPICE指导我们怎么分析需求，而26262则约束我们如何把需求写好、管好。虽然26262强调的是安全相关需求的说明与管理，但是，这些内容同样也适合非安全需求的说明与管理。因此在建立需求的说明管理过程中，两者是互相补充的。 前面的文章（ASPICE 与 功能安全过程融合 | 单条需求的规范表达形式）介绍了单条需求的规范表达形式，我们接下来会介绍一下功能安全对需求分组表达与管理的要求。然后，我们结合ASPICE提出的基础实践来探索一下需求管理过程的建设。我们首先补充一下单条需求属性的说明内容，功能安全提出如下3点要求： a)在整个安全生命周期中保持不变的唯一标识 可以通过多种方式对需求进行唯一标识，例如 为单词“shall”的每个实例增加下标， 或对每个包含单词“shall”的句子进行连续编号，例如 “9782在...的情况下，系统应检查...”。 b) astatus; and 状态说明说明当前需求所处的状态，如 起草、接收、评审、发布、验证等
c) anASIL. ASIL等级说明 需求的属性仅仅只有上面的三点还是远远不够的，IEC2914-2018还推荐如下几个属性： d)需求优先级。最简单的优先级可以分高、中、低三个层次。提出需求优先级的概念并不是暗示低优先级的需求没有必要，而是在我们不得不对候选需求进行决策时，提供一个指导。所以优先级制定时需要考虑干系人的需要。比如，不同发布阶段，需要发布的功能不一样，存在完成的先后顺序，这个顺序就可以作为一个制定优先级的参考。 e)版本号。主要是保证需求实现的版本正确，需求的多次变更会增加项目的风险。 f)需求的类型。根据不同的目的和特性，需求会有很大变化。这个属性可以帮助我们进行需求的分类，如功能需求、过程需求等。 g)基本原理。主要为了说明这条需求导出的原因，提供分析、模拟、研究的依据。 h)难度。简单的难度分类，可以分为高中低三档。这个属性主要是提供需求可实现度的附加信息，来支持成本分析。上述需求属性基本上算是补充完了，我们再来看一下功能安全对需求如何组织的要求：
a)hierarchicalstructure; 分层结构，需求会根据开发阶段划分成几个连续的层次，每个阶段内部还可以继续分层。
b) organizationalstructure according to an appropriate grouping scheme;适当的需求分组方案
c)completeness; 完整性，完整性意味着一个级别的安全需求，完全实现上一个级别的所有安全需求。
d)external consistency; 外部一致性，需求之间不存在矛盾与冲突
e)no duplication of information within any level of the hierarchical structure;and在同一层次结构上的需求没有重复信息；单层信息不存在重复，跨层信息也不存在重复
f) maintainability. 维护性，维护性是需求可以修改或者扩展。
针对需求的追溯性还有如下要求：
a)eachsource of a safety requirement at the next upper hierarchical level;每层需求来自于上一层的需求。
b)each derived safety requirement at the next lower hierarchical level, or to itsrealisation inthe design; and在下一层次或者设计上实现本层次的需求。
c)the verification specification in accordance with 9.4.2.根据9.4.2进行验证
