基于需求工程的军品研制技术要求确认与传递

万会兵，刘 阳

(1.陆军装备部驻北京地区航空军事代表室，北京 100024；2.上海航空电器股份有限公司，上海 200233)

0 引言

航空产品研制一般以需求为根本出发点，是自顶向下逐层分解，自底向上集成验证的正向研发过程[1]。需求管理过程一般包括需求捕获、需求分析与定义、需求分解分配、需求验证策划、需求验证和确认、需求变更、需求追溯及需求验证跟踪管理等活动，覆盖了航空产品研制全过程[2]。目前在航空领域，研究者们针对需求工程已开展了不少相关研究工作。陈重阳等[3]讨论了海军装备发展作战需求生成流程和机制，王焕青[4]、周璇[5]等论述了飞机需求变更管理技术，但对于军品研制技术要求确认与传递方法研究较少。

当前，军品研制中还存在研制技术要求传递不准确、确认不规范、验证不充分等问题，导致出现了一系列质量问题。存在这些问题的主要原因，是研制技术要求还缺乏统一有效的收集、确认、传递、变更以及验证的流程和方法，从而导致技术要求承接、传递、跟踪、记录、确认和反馈存在问题，有时甚至出现一些技术要求不落实或未验证等现象。本文借鉴适航管理中研制要求管理的成熟经验，采用需求工程方法，结合军品研发管理体系要求，提出了一套基于需求工程的军品研制技术要求确认与传递方法。

1 研制技术要求应遵循的基本要求

对于军品研制技术要求，一般要做到满足三个方面的基本要求，一是确保要求是无二意的，正确的，一致的，可操作的，技术可行的，可验证的；二是要对产品全寿命周期明确要求内容，确保要求的完整性、可用性和寿命周期可追溯性；三是在定义要求时，每项要求的定义都须严肃慎重认真，以确保要求的制定是周密的、恰当的。

同时，基于需求工程的要求，军品研制技术要求确认与传递应遵循以下基本原则：

1)明确性：用简洁明了的语言来表述各项需求，对所有的需求都有清晰的解释。

2)完整性：不遗漏任何必要的需求信息，每项需求都必须描述清楚。

3)正确性：每项需求都必须准确地反映待开发系统的真实要求。

4)一致性：每项需求的描述不应存在表面的或隐含的矛盾。

5)层次性：每项需求应根据待开发系统的需要，确定需求的层次和优先级。

6)可实现性：每项需求都必须从现实条件出发，确保能够在一定时间内得到满足。

7)可追溯性：需求开发最终成果必须与用户原始需求建立可追溯的关联关系。

8)可验证性：每项需求可通过检查/评审、分析、试验/演示或使用/服役经验四种方法验证。

2 基于需求工程的军品研制技术要求管理流程

对于每一个军品系统/产品，其完整的研制过程包括系统/产品的定义、系统/产品的设计及实施、系统/产品的集成验证。需求管理作为研制的重要的活动，贯穿整个研制周期，它主要包括三个过程：需求的捕获、需求的确认以及需求的验证。此外，系统研制活动每一个环节均可能出现需求的变更情况，因此，需求变更与需求活动的每个环节都有联系。图1描述了军品系统/产品需求管理流程中的关键活动和环节(包括需求更改)之间的关系。

图1 需求管理过程

2.1 需求捕获

需求捕获的目的，是获得与系统/产品相关的功能需求、性能需求、接口需求、操作需求、物理和安装需求、安全性需求、维护性需求等，它们来源于利益攸关方(包括客户、主制造商、供应商、分包商等)和相关的设计准则及理念(包括行业技术标准、政策法规等)。另外还有一种需求成为衍生需求，主要来源于系统/产品方案设计或设计实现的选择(包括系统架构设计、安全性评估等)。

对于系统/产品供应商，其需求主要来源于主机单位之间的技术协议和顶层文件。通过符合性矩阵的方法，能够快速准确地捕获主机单位的需求。首先，对主机单位高层级需求内容条目化，并建立与需求相关的属性列；然后，逐条进行分析和评估，从而捕获其中有用的需求，形成系统/产品供应商低层级设计需求。图2所示为非衍生需求捕获过程模型。

图2 非衍生需求捕获过程模型

符合性矩阵方法的优势，是对需求内容进行结构化和多维度的管理，确保需求捕获的有效性和准确性。除了第一列编号和第二列内容之外，符合性矩阵共有5个属性列：“类型”、“符合状态”、“偏离及说明”、“偏离批准”以及“是否传递”，其中：

“类型”，用来识别技术协议或顶层文件内容的类型属性，共包括四个类型：标题、描述、技术需求、管理要求。

“符合状态”，用来记录对类型识别为技术需求或管理要求的条目符合状态初步判断的结果，共包括4个状态：符合、部分符合、不符合、不适用。“符合”表示系统/产品供应商能够满足该技术需求；“部分符合”表示系统/产品供应商只能满足该技术需求或管理要求的一部分；“不符合”表示系统/产品供应商不能满足该技术需求或管理要求；“不适用”表示该技术需求或管理要求对系统/产品供应商不适用。

“偏离及说明”，用来记录该技术需求或管理要求符合状态原因以及对于判断为部分符合、不符合和不适用技术需求或管理要求的偏离说明。

“偏离批准”，用来记录客户/主机单位对判断为部分符合、不符合和不适用技术需求或管理要求及其偏离说明的批准情况。“批准”表示客户/主机单位同意该技术需求或管理要求的符合状态及其偏离，“未批准”表示客户/主机单位不同意。

“是否传递”，用来记录技术需求或管理要求是否向下传递的状态。对于不适用的需求，标示为“否”，即不向下传递；对于其他适用的技术需求或管理要求则标识为“是”，即需要传递到系统/产品供应商的设计需求。

2.2 需求确认

需求捕获所形成的设计需求，是后续研制工作的设计输入。为了保证后续研制工作正确开展，需要对捕获的需求开展需求的确认工作，即通过确认来保证需求的“正确性”和“完整性”。“正确性”表示一种程度，意指需求个体是否是清楚的、可实现的、可验证的、与其它需求是相符合的，以及对需求集是必要的；“完整性”表示一种程度，意指对于给定的一组需求或需求集，所定义的系统功能或特性能够在所确定运行环境的寿命周期各个阶段的所有运行模式下满足所有利益攸关方的需求。需求确认过程模型见图3。

图3 需求确认过程模型

需求的确认方法包括：评审、分析、建模仿真、试验、追溯性。评审是邀请各专业专家对需求评审确认，在该过程中，依靠个人工程经验对需求完整性和准确性进行评估；分析是通过理论计算、逻辑推理对需求进行确认，如功能危害性分析、初步安全性分析、相似性分析等；建模仿真是通过建模仿真的手段对需求进行确认；实验是根据原型机、模拟器或实际实物模型，通过实验室测试、演示等方法确认所捕获的需求是否合理正确；追溯性是通过与上一层级已确认的需求(顶层需求)的追溯关系进行需求确认。

根据不同的需求特点，确定需求确认的方法，并根据确认方法开展相应的需求确认活动，最终形成需求确认矩阵。需求确认矩阵是在捕获的设计需求(设计任务书)的基础上形成的，除了包含设计任务书的内容和属性，还增加了四列属性：需求集、确认方法、确认状态、确认证据。其中“需求集”是为了确认需求的完整性，按照一定的原则划分的若干个需求的集合，通常按照系统/产品的功能特性或产品各专业领域来进行划分；“确认方法”用来记录开展相关确认活动的手段；“确认状态”用来记录需求确认结果的属性，共有两种状态：“已确认”表示该需求已完成相关确认工作并得到确认，“未确认”表示需求工作未开展或者确认结果不满足要求；“确认证据”用来记录已得到确认的需求的相关确认支撑材料，主要包括分析报告、评审记录、实验报告、检查单等。

2.3 需求验证

系统/产品设计实施完成后，需要对已完成的设计或实现的系统进行验证。其目的是表明系统/产品的设计或实施满足了已确认的需求，即实现的系统/产品是否达到了预期的功能、性能以及规定的工作环境等要求。需求验证过程模型见图4。

图4 需求验证过程模型

需求的验证方法包括：实验/演示、检查或评审、分析、使用/服役经验。实验是通过运行已实现的系统/产品，来评估系统/产品达到了预期的功能、性能以及规定的工作环境要求，以此表明需求得到满足；检查或评审是通过对过程文件、图纸、硬件或软件的检查，以验证需求是否得到了满足，通常使用检查单或类似的支持工作来进行，检查系统是否符合已确立的实施过程和工艺是一种典型的检查/评审方式；分析是对系统进行理论计算、逻辑推理(如建模仿真分析、安全性分析等)，并以此来表明系统/产品的设计或实现满足预期的目标；使用/服役经验，相似性和服役经验是以其它军品上相同系统或相似系统的合格服役经验来表明实现的系统/产品满足需求的验证方法。

基于需求验证方法开展相应的验证活动，记录并更新验证状态和验证证据，形成验证矩阵。需求验证矩阵和需求确认矩阵合并在一起，最终形成需求确认与验证矩阵。需求验证矩阵主要包含三列属性：验证方法、验证状态、验证证据。其中“验证方法”用来记录每一条需求的验证方法，共有前面提到的四种常见的验证方法；“验证状态”用来记录需求验证结果的属性，共有两种状态，“通过”表示该需求验证工作已经完成且需求已得到满足，“未通过”表示需求验证工作未开展或者验证结果表明系统/产品的实现未满足预期需求；“验证证据”用来记录需求验证结果的相关支撑材料，主要包括分析报告、评审记录、检查单和实验报告等。

2.4 需求更改

需求基线首次建立或需求文件首次发布后，需求更改还可能发生在系统/产品研制过程中任何一个阶段，它会影响到需求过程的任何一个环节，因此，需求更改需要在整个系统/产品生命周期进行管理和控制，以评估需求更改的必要性、可行性以及更改的影响，并记录需求更改评估及实施的整个过程。需求更改过程流程见图5。

图5 需求更改过程流程

需求更改的来源有两个：内部更改和外部更改。内部更改是系统/产品研制方内部需求确认、需求验证或设计实现过程引起的需求变更；外部更改是上级主机单位或者下级次级供应商的外部需求变更，一般采用技术协调单的形式通知系统/研制方。

需求更改的管理和控制属于构型管理的范畴，其更改评估及实施过程与一般构型控制过程一致，即通过更改申请单(ECR)和更改建议(ECP)实现。无论更改来自内部还是外部，都要发起更改申请单以评估需求更改的必要性。若需求更改ECR不通过，则需求更改终止；若ECR通过，则回到需求捕获环节并进行需求的确认，以评估需求更改后的正确性和完整性，然后发起ECP以评估需求更改的可行性及其影响，并将需求确认的正确性和完整性作为需求更改可行性评估的依据。若ECP批准不通过，则重新进行需求捕获与需求确认环节，并重新进行ECP评估，直到ECP评估通过，最后执行需求的更改，发布新的需求基线。

3 需求管理实践

此处用一个军工产品的真实范例说明需求管理过程的实践流程(图6)。

图6 需求管理实践活动流程图

3.1 活动F0—技术协议、顶层文件可达性论证分析

技术协议、顶层文件可达性论证分析，主要是收集与系统研制相关的顾客需求(如军品通用技术规范、技术协议、产品顶层需求、接口文件等)，行业标准(如GJB、HB、MIL标准)，法律法规要求等，通过具体开展F0.1-F0.8的活动，将其按照符合性矩阵的方法进行标记分析，输出顶层文件的符合性矩阵(见表1)。

完成需求符合性矩阵后，要对F0.1-F0.6开展符合性矩阵检查，对技术协议、顶层文件中的所有需求以符合性矩阵检查单形式进行检查，确认是否满足如下要求：

1)符合性矩阵中是否包含源文件的所有需求？

2)所有需求是否与源文件一致？

3)所有偏离的需求是否定义了审批状态？

4)是否所有产品相关需求都在“向下传递”属性中标记了“是”？

5)所有在“向下传递”属性中标记为“是”的需求是否都是产品相关需求？

根据检查并回答以上问题的最终结果，结合开展F0.1-F0.7活动的具体信息，整理发布最终技术协议、顶层文件需求的符合性矩阵(VCM)，并根据军品研制的要求，形成可达性论证分析报告。

表1 技术协议、顶层文件可达性论证分析符合性矩阵表

3.2 活动F1—需求捕获

需求捕获的主要目的，是根据技术协议、顶层文件需求的符合性矩阵，通过开展F1.1-F1.4活动，捕获顶层非衍生需求，如表2-非衍生需求和衍生需求捕获矩阵表中编号SYRD-7的源自技术协议等项层文件的技术需求，以及技术协议、顶层文件没有提出但研制系统不可缺少的衍生需求，如表2中编号SYRD-22、 SYRD-23的技术需求，源自过往系统研制经验和用户好的体验，然后后输出需求捕获文件。

表2 非衍生需求和衍生需求捕获矩阵表

在这里，表2中根据工程经验对已经条目化的需求进行需求判断，将条目表中的文字分为需求、标题和描述三类，并做标记。其中，“标题”指文件中的标题、抬头；“描述”指帮助理解需求撰写的一些辅助信息，但不是对系统/设备研制做出的要求；“需求”指本系统/设备研制要求。同时，需求类型分为“技术需求”和“管理要求”，在需求传递过程中，仅对技术需求确认，而管理要求传递至设计任务书。

根据F1.1-F1.3捕获的非衍生需求和衍生需求编写设计任务书。捕获的需求中需求不明确或者顾客对所有供应商提出的通用需求，可以改写成意思明确、适用于本研制系统/设备的需求，同时根据捕获的系统/设备需求在设计任务书中加入系统/设备描述(非必须)，帮助设计任务书阅读者理解该研制系统/设备的需求。

3.3 活动F2—需求确认

需求确认主要是在需求捕获的基础上，通过F2.1-F2.7活动，确认需求的正确性和完整性，最终输出需求确认矩阵(见表3)。

确认需求的“正确性”，意指需求个体是否是清楚的、可验证的、与其他需求是相符合的，以及对需求集是必要的；“完整性”，意指当一个系统满足了一组正确的需求时，这组需求是否在所确定运行环境的寿命周期各个阶段满足顾客、用户、维修人员以及军品、系统、项目开发人员等方面的需求。

在需求确认矩阵增加了“需求集”信息。定义需求集的目的在于方便硬件工程师、软件工程师、结构工程师等有针对性地确认与本专业相关的需求，提升确认效率。系统工程师、六性工程师和验证工程师要对所有需求进行确认，需求集标注的需求条目须经除上述三类工程人员之外的相应工程人员确认。

表3 需求确认矩阵表

需求确认检查单要回答以下两个方面的问题：

一是需求的正确性：

1)是否是一条需求？

2)是否与上层需求一致？

3)确认方法是否有具体的支撑数据？

4)本条需求是否清晰？

5)本条需求是否可验证？

6)是否存在必要的验收标准？

7)本条需求是否可实现？

8)如果是一条衍生需求，是否有原理支撑？

9)保持本条需求是否比将其分成几条好？

10)是否与父需求建立链接关系？

二是需求的完整性：

1)本条需求对需求集的完整性是否必须？

2)本需求集单独存在是否比与其他需求集合并更好？

3)在本需求集中本条需求是否与其他需求一致？

4)软件的需求能否按符合预期功能被开发？

5)本需求集是否包含了所有可靠性需求？

6)本需求集是否覆盖了所有预期功能和模式？

7)本需求集是否覆盖了所有适用的接口？

8)本需求集是否包含所有PSSA需求？

9)本需求集是否声明了所有失效条件和禁止行为？

10)本需求集是否覆盖了所有操作场景/模式？

11)需求和确认的属性是否都已填写完成？

根据需求确认检查单的最终结果，结合F2.1-F2.6活动的具体信息，整理发布最终系统需求确认矩阵(活动F2.6是对F2.1-F2.5输出结果的纠正和调整)。

3.4 活动F3—设计实现

设计实现主要是根据需求确认矩阵，按照军品研发体系要求进行的设备架构、技术方案设计、生产制造等活动，使系统/设备功能、性能得以正确实现。

3.5 活动F4—需求验证

需求验证是在设计实现的基础上进行需求的验证，以验证功能、性能需求都已经正确地得以实现。针对需求的不同，可以选择不同的方法进行确认。需求确认的方法主要有以下四种：“检查/评审”—通过检查或评审设计方案、图纸及相关设计资料，验证所实施的设计已满足了确认的需求；“分析”—通过对设计进行详细的理论分析计算或者采用相似性分析来评估正常和非正常状态下功能性能是否满足预期目标；“实验/演示”—通过实验或者演示以验证需求得以满足的方式；“使用/服役经验”—通过其它具有相同或相似设计的合格服役经验，以及系统/设备在顾客的交付使用评估结论等，表明需求得以满足的方式(见表4)。

在这里，要根据确定的需求验证方法，编写需求验证程序，其主要内容包括所需要的资料及信息、环境条件,具体的验证活动步骤，以及如何记录验证结果和验证证据；要基于需求验证程序，开展相应的验证活动，并记录相应的验证结果、证据，更新验证矩阵；要根据需求确认矩阵和需求验证矩阵，形成需求确认与验证矩阵。

表4 需求验证矩阵表

续表4

对于采用实验/演示验证方法的需求，要根据实验大纲，对系统/设备进行验证，并记录相关实验结果和现象；对于采用检查/评审验证方法的需求，要按照检查/评审过程文件的要求，组织相关人员对设计方案、图纸等相关设计资料进行仔细的检查，确认设计实施是否满足要求；对于采用分析验证方法的需求，要通过对设计进行详细的理论分析计算及相似性分析来评估正常和非正常状态下系统/设备功能性能是否满足预期目标。

4 结束语

采用基于需求工程的军品研制技术要求确认与传递方法，能够保证研制技术要求有效地收集、确认、传递、变更以及验证，从根本上克服技术要求出现遗漏、识别不全面或得不到充分验证等问题。这套方法尽管会在一定程度上增加需求工作的工作量和成本，但由于设计需求更加明确，可以让承制方从中获得更高的型号研制工作效益，比如减少设计迭代，改善配置管理，降低人为失误等等。