利益相关方需求、系统需求、分系统需求与单机需求

在系统工程中，需求是驱动设计与开发的灵魂。然而，需求的层级性和复杂性常导致概念混淆。本文从**利益相关方需求**出发，逐层拆解至**系统需求**、**分系统需求**和**单机需求**，通过定义解析、实例分析和模型化表达（基于SysML），厘清四者的差异与关联，为需求工程提供清晰的实践框架。

需求层级金字塔：从抽象目标到具体实现

系统工程的需求管理遵循“自上而下”分解原则，形成典型的金字塔结构，高层需求驱动底层需求，底层需求支撑高层目标的实现。

各层级需求的定义与特征分析

利益相关方需求

定义：由利益相关方（用户、客户、监管机构等）提出的非技术性期望，反映业务目标或操作场景。  
特征：  
  - 抽象性（如“提高航班准点率”）；  
  - 多源性（来自不同角色的矛盾需求）；
  - 非结构化（自然语言描述为主）。
示例：  
   “乘客希望登机流程耗时不超过15分钟。”

系统需求

定义：对利益相关方需求的技术转化，定义系统整体需实现的功能、性能及约束。  
特征：  
  - 技术导向（如“系统需在10分钟内完成100名乘客登机”）；
  - 全面性（覆盖功能、接口、安全等维度）；
  - 可验证性（定义明确的验收标准）。
示例：  
  “登机系统需支持同时开放4个登机口，每个登机口平均处理速度为25人/分钟。”

分系统需求

定义：将系统需求分解至子系统（如动力、控制、通信子系统）的具体设计要求。  
特征：  
  模块化（按子系统职能划分）  
  接口明确（定义子系统间的交互协议）  
  协同性（多个子系统需求共同实现系统目标）  
示例：  
  “登机口控制子系统需在扫描登机牌后0.5秒内触发闸机开启。”

单机需求

定义：针对硬件/软件单元（如传感器、控制器、代码模块）的详细规格。  
特征：  
  - 高度具体化（如“电机扭矩≥5N·m”）  
  - 可测试性（可通过单元测试验证）  
  - 技术参数化（量化指标为主）  
示例：  
  “登机闸机电机需在0.3秒内响应开启指令，误差范围±0.05秒。”

需求层级间的关系与建模方法（基于SysML）

需求分解与追踪

通过SysML的«deriveReqt»（派生关系）和«containment»（包含关系）实现需求逐级分解。

需求可追踪性矩阵

通过矩阵视图确保需求覆盖完整性和一致性。

示例

关键差异总结