4.3 系统需求定义过程
4.3.1 目的
如ISO/IEC/IEEE 15288所述：
系统需求定义过程的目的是将面向相关方、用户视角所需的能力转换成一个技术视角的、可以满足用户业务需求的解决方案。
4.3.2 概述
如图4-14所示，系统需求定义过程是在方案域的顶层，从技术的视角描述系统需要具备哪些功能与性能以满足相关方需求，系统需求只描述抽象的功能，不涉及如何实现内容。
系统需求是系统定义的基础，系统需求是架构、设计、集成、验证的基础。
图4-14 系统需求描述抽象方案（来源：IBM最佳实践）
每一项需求都会带来成本。因此，系统需求是一个完整的、必不可少的、建立在项目生存周期早期所定义的相关方需求的最低限度的需求集，不要过分承诺（No Gold Plating∗）。在开发周期后期的需求变更都会显著影响项目成本，甚至可能导致项目被取消。
系统需求定义过程从供方角度出发，利用相关方需求，以反映用户观点为基础，产生一组系统需求。因此，系统需求定义是一个从问题域需求向方案域需求转换的过程。从相关方需求转换为系统需求，通常包含三种类型：
1）分解型需求。将高层需求分解为更低层次需求。
2）预算分配型需求。将一个总的值分配到不同的子系统中。
3）直接分配型需求。继承上一层需求，如标准规范。
其中，分解型需求是最复杂一种类型，需要从工作原理、运行过程以及完备性法则等方面开展需求分解，图4-15所示为一个分解型需求的示例。
图4-15 分解型需求示例
系统需求详细地描述了满足相关方需求的系统的特性、属性、功能和性能。
4.3.3 活动描述
图4-16所示为根据《INCOSE系统工程手册》系统需求定义过程IPO图改编的系统需求定义过程。
根据ISO/IEC/IEEE 15288：2015，相关方需要与需求定义过程包括以下活动：
图4-16 系统需求定义过程
1.准备系统需求定义
1）为定义系统需求建立方法。
2）与架构定义过程协同，确定系统的边界，包括接口、反映运行场景和预期的系统行为。
3）系统与系统外部之间预期的相互作用，已协商的接口控制文件（ICD）作为定义的系统（控制）边界。
2.定义系统需求
1）识别和定义所需的系统功能。
2）识别相关方的需求或强加给系统的不可避免的组织约束，并捕捉那些约束。
3）识别与系统相关的关键质量特性，如安全、保密、可靠性与可支持性。
4）识别需要在系统需求中解释的技术风险。
5）详细描述系统需求。
3.分析系统需求
1）分析系统需求的完整性，确保每条需求或一组需求具有完整性。
2）提供分析结果给合适的相关方，确保所描述的系统需求充分反映相关方的需求。
3）协商修改解决在需求中发现的问题。
4）定义验证准则——进行技术成果评价的关键性能度量。
4.管理系统需求
1）确保关键相关方之间的一致，需求充分反映相关方的意图。
2）建立和维护系统需求和系统定义的相关要素之间的可追溯性。
3）在整个系统生存周期维护系统需求以及相关的原理、决策和假设。
4）为技术状态管理提供基础信息。
4.3.4 关键要素解析
1.系统需求分解与定义
前面的章节中提到了需求的转换主要有三种类型：分解型需求，将高层需求分解为更低层次需求；预算分配型需求，将一个总的值分配到不同的子系统中，如图4-17所示，将系统总功耗分配到不同的子系统上；直接分配型需求，继承上一层需求，如标准规范。
图4-17 预算分配型需求
需求分解与定义是非常复杂的活动，本质上是利用解析法完成一个问题的求解，通过不断对研究对象进行分析，恢复其最原始的状态；“化繁为简”，通过一定程度的简化，由整体到部分，由连续到离散。
在前面的系统需求定义活动描述中，给出了六个活动步骤完成系统需求定义：
1）确定系统边界和预期行为。
2）定义、派生并细化功能/性能需求。
3）定义其他非功能性需求。
4）识别技术风险。
5）功能整合。
6）根据模板形成SyRS。
在这六个活动中，以“定义、派生并细化功能/性能需求”最为复杂，我们可以把这个活动进一步分解为四个活动：
1）定义系统状态和模式。
2）定义系统功能。
3）定义功能接口。
4）定义各项功能的性能与技术参数。
而这四个活动中，“定义系统功能”又最为复杂。定义系统功能需要考虑三方面的要素：
（1）该功能的基本原理 例如，我们要定义飞机“飞行”这一功能，首先要掌握飞机的飞行原理，这是定义功能的出发点，基于这一基本原理，才能确定所要定义的功能的基本输入/输出与环境条件，如图4-18所示。
图4-18 飞机飞行原理示意
（2）运行概念 在功能定义过程中，要参考运行概念，从运行概念文档中可以派生出更多细节的功能。例如，飞机“飞行”功能在整个运行过程的不同运行阶段都存在，但不同阶段存在不同的功能细节。同样，不同运行阶段的运行环境不一样，也会派生出更多新的功能。飞机顶层运行概念如图4-19所示。
图4-19 飞机顶层运行概念
（3）完备性法则 在功能定义活动中，同样需要考虑完备性法则（图4-20）。完备性法则可以帮助我们将功能定义得更全面。
完备性法则是由Г·С·阿奇舒勒在他的第一部有关技术系统进化法则的著作中提出的。技术系统的建立是为实现一定的功能，只有当技术系统的每一个部分均达到最低工作能力且所有部分共同形成的统一系统的最低工作能力得到保障时，该技术系统才有生命力。为此，系统必须具备能够实现其功能的最基本要素：执行装置、传动装置、动力装置、控制装置，且各要素之间必须存在的物质、能量、信息和职能联系。图4-20中箭头方向表示系统中能量传递的路径。
完备性法则可以简单描述为：
系统为实现功能，必须具备保障最低工作能力的基本组成要素和基本联系。我们将其应用到功能分解中，将一项功能分解成能使其完成的基本功能要素和联系。
图4-20 完备性法则
在具体的功能分解与定义过程中，需要从基本原理、运行概念和完备性法则三方面考虑，并将三方面融合在一起，这样才能分解出比较完整、科学的功能需求。在创新型的设计过程中，对于新功能的定义与分解需要利用上述三方面来完成，但在大多数的产品研发与设计过程中，多数功能的定义与分解都是可以借鉴原有研发与设计成果来完成。
2.系统需求规格（SyRS）说明书
系统需求规格说明（System Requirements Specification，SyRS）确定所选择的SOI的技术需求以及设想的人机集成可用性。它从方案域以系统的视角定义系统高层次需求，以及关于系统总体目标、目标环境、以及约束和假设的声明等相关背景信息。
系统需求规格说明描述系统将做什么，系统的交互或与外部环境的接口。SyRS需要完整描述所有的输入、输出以及输入输出之间的关系。其范例轮廓见表4-8。
表4-8 ISO/IEC/IEEE 29148：2018标准中的SyRS范例轮廓
（续）
关于系统需求规格说明（SyRS）各信息项的具体内容，请参考附录D.4。
4.3.5 案例——导弹系统需求定义
本节以某导弹系统的系统需求定义过程作为案例。按照系统需求定义过程对导弹系统需求进行分解与定义，当然，书中仅对导弹系统需求定义过程进行解析，不对导弹具体分解的需求结果做详细描述。
1.完成导弹系统需求定义准备
在此步骤中，需要完成三方面工作：
1）为定义系统需求建立方法。首先需要确定系统需求在系统块中的位置，确定抽象的层次——方案域顶层，确定系统需求类型。
2）确定需求分析工具。在本案例中，可能应用到的需求定义与分析工具包括N2图、IDEF、FFBD（功能流块图）、权衡分析、成本效益分析、Context Diagram、MBSE建模、OCD（运行概念文档）、追溯矩阵等。
3）确定需求定义使能工具软件。
2.定义导弹系统需求
这一步骤是最为复杂的，图4-21用IDEF0描述导弹系统需求定义过程，给出了导弹系统需求定义框图。
图4-21 导弹系统需求定义框图
导弹系统需求定义的输入包括相关方需求、功能清单、导弹运行概念文档（OCD）、设计与物理约束、相关的规范与标准。
导弹系统需求定义的活动，可以进一步把它分解成六个活动来完成系统需求定义：
1）确定导弹系统边界和预期行为。
2）定义、派生并细化导弹系统的功能/性能需求。
3）定义导弹系统其他非功能性需求。
4）识别导弹系统技术风险。
5）完成导弹系统功能整合。
6）根据模板形成导弹系统需求规格（SyRS）文档。
下面针对上述六项活动进行展开。
①第一项活动是确定导弹系统边界和预期行为。可以使用Context Diagram来描述系统边界，如图4-22所示。
图4-22 使用Context Diagram定义导弹系统边界
椭圆形圈内的是目标系统，圈外的都是与目标系统有交互的外部系统。然后，通过运行概念文档确定导弹系统的预期行为，分别确定系统的通用场景：
· 发射场景。
· 制导飞行场景。
· 寻的攻击场景。
关键场景：
· 场景1：目标系统接收导航卫星制导信息自主飞行。
· 场景2：目标系统接收无人机导航自主飞行。
· 场景3：目标系统正常攻击。
· 场景4：目标系统受到电磁干扰。
· 场景5：目标系统受到敌方防空系统攻击。
· 场景6：敌方目标已被摧毁。
· 场景7：……
②第二项活动是定义、派生并细化功能/性能需求，该项活动包含四项任务：
· 任务1：定义系统状态或模式。
· 任务2：定义系统功能。
· 任务3：定义功能接口。
· 任务4：定义各项功能的性能与技术参数。
模式是系统特征或一系列功能的集合［IEEE 1363：1998］。在本案例中，导弹系统的模式可能包括了规定的正常模式、维修模式、训练模式、紧急模式、战备模式、作战模式、存储模式等。每一种模式都涵盖了导弹系统的一系列特性与功能的集合，这些功能集合，共同构成了导弹系统的系统需求。
定义系统的功能，首先要确定导弹系统的顶层功能，表4-9第二列是识别到的导弹系统顶层功能。然后，根据导弹系统各项功能所涉及的基本原理、导弹运行概念和系统完备性法则三方面考虑，完成导弹系统功能的分解与派生，见表4-9第三列。
表4-9 确定导弹系统顶层功能及由此分解与派生的二级功能（示例）
（续）
对导弹系统功能分解完成后，还需要对系统的各项功能做到多好进行定量描述，形成各种性能度量指标（MoP），比如雷达反射面积RCS值，信号发送、接收频段，信号延迟时间，数据链路，毁伤半径等量化指标。通常一个性能度量指标由名称、值、量纲、公差等四部分，例如，毁伤半径（50±5）m。
对于功能接口可以使用N2来表达，对确定的导弹系统功能接口的描述如图4-23所示。
③第三项活动是定义导弹系统其他非功能性需求。包括导弹可用性需求、可靠性需求、人机集成接口和可维护性需求等六项需求。例如，针对发动机点火功能可靠性需求：导弹发动机点火功能可靠性不低于99.99%（示例）。
④第四项活动是识别导弹系统技术风险。将导弹在运行过程中可能出现的各种技术风险识别出来，并针对这些技术风险制定相应措施。表4-10列举了导弹系统可能存在的技术风险与影响。
图4-23 导弹系统功能接口N2图
表4-10 导弹系统可能存在的技术风险与影响
注：还存在其他可能，本表未列全。
风险识别过程可能派生出新的需求，如为了降低某一技术的风险，可能需要增加新的方案或设备以降低风险，从而派生出新的功能。例如：在民用飞机上，为了降低发动机空中停车造成机毁人亡，通过双发备份方案来降低风险，从而改变飞机气动布局。
在基于模型的系统工程（MBSE）实践中，除了要完成各种正常情况的建模，还需要识别各种RainingDay并建模。RainingDay建模与技术风险识别类似，这需要经过长时间积累和运行实践，才能积累足够丰富的技术风险或RainingDay，在系统定义的早期过程中，要尽量将这些技术风险或RainingDay考虑得更完善，避免将可能出现的问题带到后期阶段造成项目延期或成本增加。
⑤第五项活动是完成导弹系统功能整合。在定义导弹系统需求的过程中，根据顶层功能清单分解和派生出的功能需求，相互之间会有交叉，需要对这些相互交叉的功能进行整合。在功能整合过程中，一些交叉的子功能具体应该归入哪一项功能中，一方面要遵行相关产品或行业的标准，也可以参照一些约定俗成的设计习惯；另一方面要考虑功能的独立性原则。
⑥第六项活动是根据模板形成导弹系统需求规格文档。系统需求规格（SyRS）文档模板请参考附录D.2，编写系统需求规格文档的过程中，需要遵循需求编写相关规范，利用需求管理工具进行需求的条目化与结构化管理，并建立需求关联与追溯。
3.完成系统需求分析
该步骤主要包括需求的完整性分析、性能分析、权衡研究、约束评估、成本效益分析、需求协商以及定义系统需求验证准则。
例如，最初要求战斗装药不小于50kg，经过对弹体结构进行优化后，可以在总重不变的情况下增加10kg战斗装药。
再比如概念文档中的无人机搭载投放模式。通过权衡研究，当前大多数无人机有效载荷性能不足，在系统需求中放弃这一模式。
在系统需求规格文档模板中，每一条需求都有对应的验证，其中包含了验证方法、验证方案、验证使能设施设备要求以及达标准则。
4.管理系统需求
该步骤利用需求管理工具软件完成需求属性定义与管理、需求关联与追溯、需求版本与发布管理、需求变更管理、需求基线管理。
导弹系统需求定义过程的输出包括九项内容：
1）导弹系统需求定义策略。
2）导弹系统功能定义——FBS（功能定义）。
3）导弹系统需求（SyRS）。
4）导弹系统功能接口识别。
5）导弹系统需求验证准则。
6）导弹系统MoP需要与MoP数据。
7）导弹系统需求追溯。
8）导弹系统更新的RVTM。
9）导弹系统需求定义记录。
在实际工程实践中，上述九项输出文档可能合并成一份文档或者合并进不同的文档中。第1）项输出——导弹系统需求定义策略文档会合并到项目管理的文档中，第2）~5）项输出会合并形成导弹系统需求规格说明书，第6）~9）项输出会通过需求管理系统完成。
在传统的基于文档的系统工程过程中，系统需求定义需要基于文档并结合多种图形进行描述。新的基于模型的系统工程（MBSE）范式，大多数方法论会在系统需求定义过程中开展建模。图4-24和图4-25分别展示了导弹系统的发射用例的黑盒模型和系统用例模型。关于MBSE的内容，可以参考本书第12章内容。
图4-24 导弹系统发射用例黑盒模型（图片来源：索为公司）
图4-25 导弹系统用例模型（图片来源：索为公司）
系统需求定义过程需要完成以下五件事情：
1）功能清单与功能分解结构（FBS）。
2）功能需求定义与非功能需求定义。
3）接口需求定义。
4）识别风险。
5）量化指标。