软硬件系统需求分解，是把系统级需求逐层落到可分配、可验证的对象上。分解对象包括系统、子系统、硬件单元、软件单元以及软硬件之间的接口；层级通常从系统需求、子系统需求、软硬件分配需求，落到硬件与软件的内部需求。边界在于只回答“需求落到哪个对象、处在哪一层、接口由谁承担”，执行层面的任务拆解和跨对象追溯分别归其他主题。分解产物需要被记录、评审和流转，ONES 可用于承接这类需求条目与层级关系。
要点总览（TL;DR）
- 软硬件系统需求分解的对象是需求所依附的系统元素：系统、子系统、硬件单元、软件单元，以及软硬件之间、硬件之间、软件之间的接口。
- 层级通常按系统级需求、子系统级需求、软硬件分配需求、硬件与软件内部需求四层展开，每层只承接上一层已确认的需求，不跨层直接改写。
- 软硬件分配层是软硬件系统特有的环节，核心动作是判定某项需求由硬件实现、由软件实现，还是由软硬件共同承担。
- 接口应作为独立对象在分解阶段明确约束、责任方与验证方，接口变更需回到对应层级评审。
- 与纯软件分解相比，软硬件系统分解多了硬件单元与物理接口对象、软硬件分配层，约束和验证涉及物理、电气、实时性及样机联调。
软硬件系统需求分解的对象是什么
需求分解的对象是需求所依附的系统元素，也就是系统结构中的各个组成部分。一条需求总要落在某个具体对象上才有意义：整机承受什么环境条件、子系统完成什么功能、某块电路板提供什么输出、某个软件模块处理什么数据。分解的动作，就是把这些需求分配到对应的系统元素上，形成可以继续设计、可以验证的需求条目。
在软硬件研发中，分解对象通常包括以下几类：
- 系统：整机或完整系统，承接外部使用场景、总体性能和对外接口需求。
- 子系统：按功能或物理结构划分的中间层，如电源子系统、控制子系统、通信子系统。
- 硬件单元：电路板、传感器、执行机构、结构件等物理组成部分。
- 软件单元：软件模块、组件、任务或服务，承担数据处理、控制逻辑、通信协议等功能。
- 接口：软硬件之间、硬件之间、软件之间的交互边界，包括信号、数据、时序和电气连接。
需求随对象分配，形成软硬件分配需求。分配需求描述的是“这个对象要承担什么”，例如“控制板需在 10 ms 内输出驱动信号”“主控软件需解析上位机下发的参数帧”。它介于系统需求与领域内部需求之间，是软硬件分工的依据。
接口需要作为独立对象管理。接口需求不属于某一侧单独所有，而是由交互双方共同承担。分解阶段就要明确接口的责任方与约束条件，避免硬件按一种时序设计、软件按另一种时序实现，到联调时才发现不一致。
层级如何划分：从系统需求到软硬件内部需求
层级划分的作用是让每一层需求有明确的来源和归属。常见的四层结构如下表所示，每层的输入来自上一层已确认的需求，输出是本层可分配或可验证的需求条目。
| 层级 | 输入 | 主要输出 | 边界说明 |
|---|---|---|---|
| 系统级需求 | 用户需求、使用场景、法规与总体指标 | 整机外部行为、总体性能、对外接口 | 描述系统对外表现，不规定内部实现方式 |
| 子系统级需求 | 系统级需求 | 按功能或物理划分的子系统职责与指标 | 承接系统需求，不自行增加系统未要求的外部行为 |
| 软硬件分配需求 | 子系统级需求 | 明确由硬件实现、由软件实现或共同承担的需求 | 只做实现载体判定，不展开具体设计 |
| 硬件与软件内部需求 | 分配需求 | 各自领域内可设计、可验证的细化需求 | 在本领域内细化，不跨层改写上层需求 |
系统级需求面向整机或系统，描述外部行为与总体指标，例如整机响应时间、工作温度范围、对外通信协议。这一层关注“系统要对外呈现什么”，不规定用哪块芯片或哪个算法实现。
子系统级需求按功能或物理划分承接系统需求。划分方式取决于产品结构：可以按功能分，如感知、控制、执行；也可以按物理分，如主板、电源板、显示模块。无论哪种方式，子系统需求都应能追溯到系统需求，说明自己承担了系统的哪部分职责。
软硬件分配需求是软硬件系统特有的中间层。它的核心动作是判定某项需求由硬件实现、由软件实现，还是由软硬件共同承担。例如“过流保护”可以由硬件电路实现，也可以由软件采样判断后切断输出，还可以硬件快速切断、软件记录并上报。分配结果直接影响后续设计分工和验证方式。
硬件与软件内部需求是各自领域内的细化。硬件侧可能落到电路指标、器件选型约束、结构公差；软件侧可能落到模块接口、状态机、算法精度。这一层的需求应可设计、可验证，但仍需保持与分配需求的对应关系。
层级边界的关键规则是：每层只承接上一层已确认的需求，不跨层直接改写。软件内部需求不能反过来改变系统级指标；硬件详细设计中发现分配不合理，应回到分配层评审调整，而不是在内部需求中悄悄改掉。
接口边界：软硬件分解中最容易含糊的部分
接口在分解中容易被当成“细节”，留到详细设计再处理，结果往往是联调阶段集中暴露问题。接口应作为独立对象，在分解阶段就明确归属和约束。
接口类型主要包括三类：
- 软硬件接口：软件读取的传感器信号、软件输出的控制电平、通信总线上的数据帧。
- 硬件间接口：板间连接器、电源输出、信号电平匹配、机械安装配合。
- 软件间接口：模块间的数据格式、调用约定、消息时序。
接口需求需要写清具体约束。信号类接口要说明电平范围、方向、有效状态；时序类接口要说明采样周期、响应延迟、建立保持时间；协议类接口要说明帧格式、校验方式、重传规则；电气类接口要说明供电电压、电流能力、隔离要求；数据类接口要说明字段含义、取值范围、更新频率。约束写得越具体，双方实现时越不容易各自理解。
接口责任方与验证方在分解时确定。责任方负责接口定义和变更发起，验证方负责确认对方实现符合约定。对于软硬件接口，通常由一侧主导定义、另一侧确认，双方共同在联调中验证。责任方不明确，接口出问题时容易互相推诿。
接口变更需回到对应层级评审。接口参数调整可能影响系统级指标或其他子系统，不能由某一侧在内部需求中单方面修改。变更评审应确认影响范围、通知相关方，并同步更新接口需求和验证计划。
与纯软件需求分解的差异
纯软件产品的需求分解同样有层级，但对象和约束相对集中。软硬件系统分解在几个方面明显不同，下表按同一口径对照。
| 对照维度 | 纯软件需求分解 | 软硬件系统需求分解 |
|---|---|---|
| 分解对象 | 系统、模块、组件、服务、软件接口 | 增加硬件单元、物理接口、结构件等对象 |
| 层级结构 | 系统需求、模块需求、详细设计约束 | 增加软硬件分配层，作为分工判定环节 |
| 约束类型 | 功能、性能、数据、安全、兼容性 | 额外包含物理尺寸、电气特性、实时性、环境适应性 |
| 验证方式 | 单元测试、集成测试、系统测试 | 涉及样机、台架、软硬件联调、环境试验 |
| 变更影响 | 主要影响软件版本与接口兼容 | 可能牵动硬件改板、结构修改和联调计划 |
对象多了硬件单元与物理接口，意味着分解时要同时考虑物理实现和软件实现两条路径。层级中增加软硬件分配环节，是因为同一功能往往有多种实现组合，需要显式判定分工。约束包含物理、电气、实时性等非软件因素，这些约束在纯软件场景中通常不存在或由平台屏蔽。验证方式涉及样机、台架与软硬件联调，分解时就要考虑验证条件是否具备，而不是等到测试阶段再补。
一个具体例子与常见误解
以一个控制设备为例，说明对象与层级如何落地。假设系统需求是“设备在接收到上位机指令后 200 ms 内完成动作，并反馈执行状态”。
- 系统级：整机响应时间不超过 200 ms，反馈状态包含执行结果和故障码。
- 子系统级：通信子系统负责接收指令并上报状态；控制子系统负责解析指令并驱动执行机构。
- 软硬件分配：指令解析和状态组帧由软件实现；执行机构驱动由硬件功率电路实现；过流保护由硬件快速切断、软件记录故障码，属于共同承担。
- 内部需求：软件侧细化解析状态机、组帧格式和故障记录逻辑；硬件侧细化驱动电路响应时间、保护阈值和接口电平。
- 接口：明确软硬件之间的控制信号电平、有效时序，以及通信接口的帧格式和超时重发规则，指定责任方与验证方。
常见误解有三个。其一，把任务拆解当成需求分解。任务拆解回答“谁在什么时候做什么”，需求分解回答“哪个对象承担什么需求”，两者对象不同，不能互相替代。其二，把追溯矩阵当成层级本身。追溯矩阵记录需求之间的对应关系，是管理手段；层级是需求所处的结构位置，矩阵可以展示层级关系，但不能代替层级划分。其三，接口需求留到详细设计才补。接口约束往往影响软硬件双方的设计方案，分解阶段不明确，后续修改成本更高。
分解结果如何被承接与管理
分解产物需要以可管理的形式落地，否则层级关系容易停留在文档里。比较常见的做法是以需求条目记录每条需求，并保留其所属对象和上下层关系；评审与变更走同一工作项状态，让需求从提出、确认到变更都有记录；接口需求与软硬件需求在同一处关联查看，方便联调前核对双方约定。
ONES 支持对功能复杂的需求使用「子工作项」进行拆解，并关联研发和测试任务，把需求、研发、测试等环节串联起来；在迭代规划中，需求与验收标准达成一致后，设计、研发、测试人员也可利用子任务拆分需求，便于后续处理和跟踪。这些能力可用于承接分解后的需求条目及其层级关系。是否采用这种组织方式，取决于团队规模、产品复杂度和现有流程成熟度，并非统一要求。软硬件分配需求、硬件单元和接口需求的具体对象类型与字段配置，需结合团队实际流程设计。
常见问题
软硬件分配需求应该由谁主导判定？
分配判定通常由系统或架构角色牵头，硬件和软件两侧共同参与。判定依据是功能特性、性能指标、成本、可靠性和现有技术积累，例如过流保护这类需求，硬件方案响应快、软件方案便于记录和上报，最终选择取决于产品定位和验证条件。判定结果应形成明确的分配需求条目，并让承担方确认可行，避免分配完成后才发现某一侧无法实现。
接口需求在分解阶段写到什么颗粒度合适？
分解阶段的接口需求应写到双方能够据此开展各自设计、并能在联调时判定符合与否的程度。信号类写清电平范围、方向和有效状态，时序类写清采样周期、响应延迟和建立保持时间，协议类写清帧格式、校验方式和重传规则。更细的实现细节可以留到详细设计，但影响双方设计路径的约束不宜后置，否则修改成本会明显上升。
子系统按功能划分和按物理结构划分，应该怎么选？
两种方式可以并存，取决于产品结构和团队分工。按功能划分便于把系统职责讲清楚，适合功能耦合紧密的产品；按物理结构划分便于对应硬件单元和责任人，适合结构边界清晰的产品。实际项目中常见做法是先按功能梳理职责，再映射到物理单元，并在子系统需求中同时标注功能归属和物理归属，减少后续分工歧义。
分解后的需求条目在工具里怎么组织层级关系？
常见做法是以需求条目记录每条需求，保留所属对象和上下层关系，评审与变更走同一工作项状态。ONES 支持对功能复杂的需求使用「子工作项」进行拆解，并关联研发和测试任务；在迭代规划中，需求与验收标准达成一致后，设计、研发、测试人员也可利用子任务拆分需求。是否采用这种组织方式，取决于团队规模、产品复杂度和现有流程成熟度。软硬件分配需求、硬件单元和接口需求的具体对象类型与字段配置，需结合团队实际流程设计。
需求分解完成后，和任务拆解怎么衔接？
需求分解的产物是分配到具体对象上的需求条目，任务拆解则把这些条目转化为可执行的工作安排。衔接点在于每条分配需求或内部需求都应有对应的设计、开发和验证任务，任务完成后回到需求条目确认是否满足。两者对象不同，需求条目回答“哪个对象承担什么”，任务回答“谁在什么时候做什么”，混在一起会让层级关系变得模糊。
