已剪辑自: https://mp.weixin.qq.com/s?__biz=MzI5Njg3NTU3MQ==&mid=2247483842&idx=1&sn=086ca9bedd2a9011d727542e19f0b17b&chksm=ecbce29edbcb6b88bd8dc3db3162c428b6eea54397606d01e31de1d91c3a40539389a660d7fc&scene=178&cur_album_id=2786562064566943747#rd
AIR6110是ARP4754A的支撑材料，提供了一种比ARP4754A更具体的需求分类方法，更具有指导意义，但是仍然存在一些问题。
首先回顾下ARP4754A中需求的定义：
需求是功能规范的可识别要素，这种要素可以被确认，且其实现可被验证。
功能的定义如下：功能是产品的一种行为，这种行为基于一系列与实现无关的需求。
基于这个定义，得出以下结论：
在AIR6110中，并没有直接给出需求类型，通过对整个案例的需求样例进行分析，需求类型分为安全性、功能、取证、接口、衍生和设计决策6种类型。这种分类主要是按照需求来源的不同进行分类。
功能需求和安全性需求是重叠的，根据需求的定义，所有的需求都是功能需求，但是安全性需求作为一种特殊的功能需求，单独作为一种分类也是可以的。在这个前提下，功能需求是指非安全性的功能需求。
取证需求与功能需求和安全性需求是重叠的，因为取证需求来源于适航取证，其类型可能是功能需求或者安全性需求。设计决策与衍生需求是重叠的，因为设计决策本身也是衍生需求。
接口需求与功能需求是重叠的，因为接口需求也是功能需求的一种，不过接口需求和非接口需求很容易区分，所以问题也不大。
衍生安全性需求和安全性需求、衍生需求者重叠，安全性需求都是经过安全性分析得出来的，所以安全性需求本来都是衍生需求，所以这个分类没有必要。
如果需求类型是重叠，那么需求类型的属性取值是需要设置成多值的，否则需要使用多个属性进行类型标注。但是AIR6110案例的需求类型都是单值的，那么它的类型标识可能会存在不能准确描述需求类型的问题。
接口需求是与系统接口相关的需求，接口需求作为一种特殊的需求，单独形成一个文件，这个文件在其他流程通常叫接口控制文件，而在4754A里边叫接口需求。在4754A里边，接口分为接口需要和接口定义两个文件，而接口需求文件跟非接口需求文件的管理是不同的，主要有以下几点：
一．将接口需求单独成一个文件，而且使用ICD作为接口条目的标识，而其他需求使用R作为标识。
二.接口需求的追溯规则与非接口需求的追溯规则不同，接口需求不需要建立直接的条目之间的追溯，而是在接口相关的系统需求文档中引用该接口文档。
三．在确认矩阵和验证矩阵的示例中，也未见接口需求的示例。因为接口需求的定向过程本身就要求接口双方共同参与，不需要额外的确认。接口在集成和功能验证的过程中自然会进行验证，没有必要重复再提。
**
**
根据上述分析，将需求分类进行改进，将需求分为安全性、功能两种互斥的类型。更加细化的类型不再区分，而是通过文档的章节进行区分。单独设置是否衍生、是否假设和是否取证需求这几个标识属性。
将接口需求从需求文档中提取出来，形成单独的接口需求，也就是接口需求文档中全是接口需求，接口需求文档也就不需要需求类别这个属性了，或者直接使用功能需求这个分类。
AIR6110作为ARP4754A的支撑材料，在ARP4754A的基础上，把需求分为6种类型，更具有实操指导意义，但是仍然存在类型重叠和接口管理方面的问题。本文提供一种改进方案，可以解决AIR6110需求分类的问题，可以作为项目实践ARP4754A需求管理的参考。
AIR6110 Contiguous Aircraft/System Development Process Example 2020-02
ARP4754A的需求分类方法
什么是理想的需求分类方法 (zhihu.com)
