软硬件系统需求分解要解决的是把业务与产品目标逐层落到可分配、可验证的软件、硬件与接口子需求上。判断分解是否到位，看两条主线：层级关系是否清楚，每条子需求是否可验证并能回溯到上层需求。下面按层级模型、拆分规则、操作步骤、角色分工、完整示例和完成检查依次展开。
要点总览（TL;DR）
- 软硬件系统需求分解按业务需求、产品需求、系统需求、子系统/组件需求、软硬件子需求五层组织，每条下层需求只归属一条直接父需求，软硬件边界在系统层与子系统层之间划分。
- 拆分一条系统需求时按功能、性能、接口、约束四类展开，接口需求单独成条并由软硬件双方共同确认，避免联调阶段责任悬空。
- 落地流程分五步：确认上层需求基线、识别功能与接口并划分边界、逐条拆分并分配责任角色、补验收条件与验证方式、评审与基线化。
- 合适的拆分粒度是每条子需求对应一个可独立验证的验收条件，并能分配给一个明确的责任角色；子需求过多且无法独立验证说明拆分过度，一条子需求包含多个指标说明拆分不足。
- 分解完成的判断标准是覆盖性、可验证性、分配完整性、父子关联完整性和版本一致性五项检查全部通过，任一项不通过按阻断项返工。
先定层级：软硬件系统需求分成哪几层
需求分解的骨架是一套稳定的层级模型。层级的作用是让每条需求都有明确的归属位置，父子关系不交叉、不悬空。软硬件系统通常分为五层：业务需求、产品需求、系统需求、子系统/组件需求、软硬件子需求。上层回答“为什么做、做什么”，下层回答“由谁实现、怎么验证”。
业务需求来自市场目标、客户合同、法规要求或内部规划，描述要达成的业务结果，粒度是目标级。产品需求把业务目标转成产品层面的功能与特性范围，明确产品形态、使用场景和主要能力。系统需求是分解工作的起点，把产品能力转成系统级的功能、性能、接口和约束，并在此层开始划分软件、硬件、结构、接口的边界。子系统/组件需求把系统需求分配到具体的子系统或组件，例如控制软件模块、电源板卡、传感器组件。软硬件子需求是最终可分配、可验证的条目，直接对应设计项和测试项。
父子关联按“一条上层需求对应多条下层需求”建立。每条下层需求只归属一条直接父需求，避免多父挂接导致回溯歧义；跨多个父需求的公共能力，单独成条并在说明中标注关联的上层需求。软硬件边界的划分位置在系统层与子系统层之间：系统层确定哪些功能由软件实现、哪些由硬件实现、哪些通过接口协作；子系统层把边界落到具体组件和接口条目上。
| 层级 | 对象 | 输入来源 | 输出 | 负责人 |
|---|---|---|---|---|
| 业务需求 | 业务目标、客户与法规要求 | 市场规划、合同、标准 | 业务需求条目 | 产品经理/业务负责人 |
| 产品需求 | 产品功能与特性范围 | 业务需求 | 产品需求条目、场景说明 | 产品经理 |
| 系统需求 | 系统功能、性能、接口、约束 | 产品需求 | 系统需求条目、边界初稿 | 系统工程师 |
| 子系统/组件需求 | 子系统与组件级要求 | 系统需求 | 分配后的组件需求 | 系统工程师与专业负责人 |
| 软硬件子需求 | 软件、硬件、结构、接口条目 | 子系统/组件需求 | 可验证的子需求 | 软件/硬件负责人 |
分解规则：一条需求怎么拆到可验证的子需求
拆分一条系统需求，先按功能、性能、接口、约束四类展开。功能类拆出系统要完成的动作和状态；性能类拆出响应时间、精度、吞吐、功耗、环境适应性等指标；接口类拆出与其他系统、子系统之间的信号、协议、时序和物理连接；约束类拆出尺寸、重量、成本、法规、安全等级等限制条件。四类拆完后，再判断软硬件归属。
软硬件分配遵循三条原则：能由软件实现的逻辑与算法优先归软件；涉及物理量采集、执行、供电、散热的归硬件；软硬件共同完成的功能，必须把交互部分单独成条接口需求，写清信号方向、数据格式、时序和异常处理。接口需求不并入软件或硬件任一侧，否则联调阶段容易出现双方都认为对方负责的情况。
覆盖判断用“一条上层需求对应一组子需求”的口径：把子需求逐条对照上层需求的每个可测点，确认功能、性能、接口、约束都有承接，没有遗漏，也没有超出上层范围的自行扩展。子需求的可验证性要求是每条都写清验收条件和测试方式，例如“在-20℃至70℃环境下连续运行8小时无复位，采用高低温试验验证”。验收条件要可测量、可复现。
过度拆分与拆分不足的判断可以看两个信号。过度拆分表现为子需求数量远超上层需求的可测点，出现大量只描述实现细节、无法独立验证的条目，评审时难以判断覆盖关系。拆分不足表现为一条子需求同时包含多个功能或多个指标，测试时无法用单一用例判定通过。合适的粒度是：一条子需求对应一个可独立验证的验收条件，并能分配给一个明确的责任角色。
| 拆分维度 | 拆分产出 | 软硬件归属判断 | 验证方式示例 |
|---|---|---|---|
| 功能 | 动作、状态、模式切换 | 逻辑与算法归软件，执行机构归硬件 | 功能测试用例 |
| 性能 | 响应时间、精度、功耗 | 按指标承载方分配，共同承担则拆接口 | 性能测试、台架试验 |
| 接口 | 信号、协议、时序、连接 | 单独成条，双方共同确认 | 联调测试、协议一致性测试 |
| 约束 | 尺寸、重量、成本、法规 | 按约束作用对象分配 | 检查、称重、合规审查 |
操作步骤：从系统需求到软硬件子需求的落地流程
分解按五个步骤推进，每步都有明确输入、动作、输出和完成标志。步骤顺序不宜颠倒，尤其要先确认基线再拆分，否则上层需求变动会让已拆分的子需求大面积返工。
步骤一：确认上层需求基线与范围。输入是已评审的产品需求与系统需求草案。动作是核对系统需求条目是否完整、编号是否唯一、范围是否与产品需求一致，冻结本轮分解的基线版本。输出是带版本号的系统需求基线。完成标志是基线经评审确认，后续拆分以该版本为准。
步骤二：识别系统功能与接口，划分软硬件边界。输入是系统需求基线。动作是逐条识别功能点、性能指标和对外接口，标注每项由软件、硬件还是接口协作实现，形成边界清单。输出是软硬件边界清单和接口清单。完成标志是每条系统需求都有明确的实现归属，接口项已单独列出。
步骤三：逐条拆分并分配责任角色。输入是边界清单和接口清单。动作是按功能、性能、接口、约束四类拆出子需求，为每条子需求指定责任角色和所属组件，建立父子关联。输出是子需求清单与父子关系。完成标志是每条系统需求至少有一条子需求承接，每条子需求都有责任角色。
步骤四：为子需求补验收条件与验证方式。输入是子需求清单。动作是为每条子需求写验收条件、测试方法和验证阶段，标注验证责任方。输出是带验收条件的子需求。完成标志是每条子需求都有可测量、可复现的验收条件。
步骤五：评审与基线化。输入是完整的子需求与父子关系。动作是组织系统、软件、硬件、测试角色联合评审，检查覆盖性、可验证性和分配完整性，处理评审意见后冻结版本。输出是基线化的需求分解结果。完成标志是评审通过、问题关闭、版本入库。
角色与交付物：谁拆、谁审、谁确认
分解过程涉及五类角色，职责按“谁拆、谁审、谁确认”分开，避免责任集中在单一角色身上。系统工程师主导系统层拆分和边界划分；软件负责人与硬件负责人承接各自领域的子需求拆分和验收条件编写；测试/验证角色负责验收条件的可测性审查和验证方式确认；需求管理角色维护层级结构、父子关联和版本基线。
| 角色 | 主要职责 | 关键交付物 | 评审与确认责任 |
|---|---|---|---|
| 系统工程师 | 系统需求拆分、软硬件边界划分、接口识别 | 系统需求基线、边界清单、接口清单 | 主持分解评审，确认覆盖性 |
| 软件负责人 | 软件子需求拆分与验收条件编写 | 软件子需求、软件验证方式 | 确认软件侧分配完整性 |
| 硬件负责人 | 硬件子需求拆分与验收条件编写 | 硬件子需求、硬件验证方式 | 确认硬件侧分配完整性 |
| 测试/验证角色 | 验收条件可测性审查、验证方式确认 | 验证方案、可测性审查意见 | 确认每条子需求可验证 |
| 需求管理角色 | 层级结构维护、父子关联、版本基线 | 需求库结构、基线记录、变更记录 | 确认关联完整与版本一致 |
评审与确认的责任归属是：系统工程师对覆盖性和边界划分负责，软件与硬件负责人对本侧子需求的完整性和可验证性负责，测试角色对验收条件的可测性负责，需求管理角色对结构一致性负责。需求变更时，变更提出方提交变更说明，系统工程师评估影响范围，软件与硬件负责人更新受影响子需求，测试角色复核验收条件，需求管理角色更新基线与父子关联，形成闭环。
当需求条目数量增多、父子关系和版本需要长期维护时，可以在需求管理工具中承载层级结构与评审基线。ONES 支持需求条目的层级组织、父子关联和评审流程管理，便于把上述边界清单、子需求和验收条件放在同一结构中维护，减少版本分散带来的回溯困难。
示例：一条车载控制器需求的分解过程
以下为演示情景，用于说明分解方法，不代表任何具体项目数据。上层系统需求描述为：“整车控制器应在检测到制动踏板信号后，于规定时间内输出制动指令，并在通信中断时进入安全状态。”
按功能、性能、接口拆出的子需求如下。功能类：软件子需求“识别制动踏板信号并生成制动指令”；硬件子需求“制动踏板信号采集电路在额定电压范围内输出有效电平”。性能类：软件子需求“从信号有效到指令输出的处理时延满足规定指标”；硬件子需求“采集电路响应时间满足规定指标”。接口类：接口需求“控制器与执行机构之间的指令报文格式、周期与超时判定”；接口需求“通信中断检测机制与安全状态切换条件”。约束类：硬件子需求“采集电路工作温度范围覆盖整车环境要求”。
软硬件分配结果为：信号识别与指令生成归软件，信号采集电路归硬件，报文格式与超时判定、通信中断切换作为接口需求单独成条，由软件与硬件双方共同确认。每条子需求的验收条件对应具体验证方式：软件功能用功能测试用例验证，时延指标用台架计时测试验证，采集电路用硬件测试与高低温试验验证，接口需求用联调测试和协议一致性测试验证。
父子关联的呈现方式是：上层系统需求编号下挂五条子需求，每条子需求标注类型（功能/性能/接口/约束）、分配对象（软件/硬件/接口）、责任角色和验收条件。评审时按上层需求逐条展开子需求，检查每个可测点是否都有承接，接口条目是否双方确认。
完成检查：分解结果是否可交付
分解是否完成，用一份检查清单逐项核对。全部通过才进入基线交付，任一项不通过即视为阻断项，需要返工后重新检查。
| 检查项 | 检查内容 | 通过标准 | 阻断与返工条件 |
|---|---|---|---|
| 覆盖性 | 每条上层需求是否有子需求承接 | 每条系统需求至少一条子需求，功能、性能、接口、约束均有对应 | 存在无承接的上层需求，返工补拆 |
| 可验证性 | 每条子需求是否有验收条件 | 验收条件可测量、可复现，测试方式明确 | 存在无验收条件或无法测量的子需求，返工补充 |
| 分配完整性 | 软硬件与接口是否都有归属 | 每条子需求有明确分配对象和责任角色，接口单独成条 | 存在归属不明或接口未单独列出的条目，返工调整 |
| 父子关联完整性 | 层级关系是否清晰可回溯 | 每条子需求可回溯到唯一直接父需求，无孤立条目 | 存在多父挂接或孤立子需求，返工修正关联 |
| 版本一致性 | 分解结果是否基于确认的基线 | 子需求与系统需求基线版本对应，变更已记录 | 版本不一致或变更未记录，返工同步基线 |
检查通过后，分解结果连同父子关联、验收条件和责任角色一并基线化，作为后续设计、测试和变更管理的输入。检查中发现的问题按阻断项处理，关闭后再提交评审确认，避免带着未闭环的问题进入下一阶段。
常见问题
系统需求在分解前还没有冻结基线，可以先拆子需求吗？
不建议先拆。上层需求未冻结时，拆分结果会随上层变动大面积返工，尤其是接口需求和性能指标这类跨软硬件条目。可行的做法是先冻结本轮分解范围的系统需求版本，对尚未确定的部分单独标注为待定项，暂不向下拆分，等基线确认后再补拆。这样既推进了已确定部分的分解，也避免把不确定内容固化到子需求里。
一条系统需求同时涉及软件和硬件，子需求应该挂在软件侧还是硬件侧？
按实现归属拆开挂接，不把整条需求挂到任一侧。软件承担的逻辑与算法拆成软件子需求，硬件承担的采集、执行、供电等拆成硬件子需求，双方交互的信号、协议、时序和异常处理单独成条接口需求，由软件与硬件负责人共同确认。接口需求不并入任一侧，是联调阶段责任清晰的前提。
子需求的验收条件写到什么程度才算可验证？
判断标准是可测量、可复现，并且能用单一测试用例判定通过与否。例如写明环境条件、指标数值、持续时间和验证方法，而不是只写“满足要求”“运行稳定”这类无法判定的表述。如果一条子需求需要多个独立用例才能判定，通常说明它应该继续拆分为多条子需求。
分解完成后上层需求发生变更，已经拆好的子需求怎么处理？
按变更影响范围处理，不做全量重拆。变更提出方提交变更说明，系统工程师评估受影响的系统需求条目和边界，软件与硬件负责人更新对应子需求，测试角色复核验收条件是否仍然可测，需求管理角色同步基线与父子关联。只影响部分子需求的变更，其余条目保持原基线，变更记录保留可追溯的版本对应关系。
需求条目多、父子关系和版本需要长期维护时，用什么方式承载比较合适？
当条目数量和变更频率超出表格维护能力时，可以在需求管理工具中承载层级结构、父子关联和评审基线。ONES 支持需求条目的层级组织、父子关联和评审流程管理，可以把边界清单、子需求和验收条件放在同一结构中维护，减少多份文档版本分散带来的回溯困难。工具承载的是结构和流程，分层规则与拆分判断仍由系统工程师和软硬件负责人确定。
