一条需求里同时出现操作动作、判断条件和“响应快、稳定、安全”等质量要求，是需求分析中常见的情况。拆分的做法是先按“谁在什么条件下做什么、得到什么结果”识别功能需求，再把判断条件、计算口径和例外抽成业务规则，最后把性能、安全、可用性、兼容性等质量约束单列为非功能需求。拆分后每条只表达一类内容，并补上来源、责任人和验收口径，后续设计与测试才有明确的依据。
要点总览（TL;DR）
- 先按“谁在什么条件下做什么、得到什么结果”识别功能需求，再把判断条件、计算口径和例外抽成业务规则，最后把性能、安全、可用性、兼容性等质量约束单列为非功能需求。
- 拆分按四步执行：逐句标注类型、抽取业务规则并挂到触发条件、剥离非功能需求并写明度量口径、回填来源与验收口径，每步都有输入、输出和完成标志。
- 业务方确认规则来源与例外，需求分析人员负责拆分与编号，架构与测试角色校验非功能需求的可度量性，交接物统一为一份拆分结果清单。
- 拆分到位的判断标准是每条只表达一类内容、规则有触发条件与例外、非功能需求可验证、条目间无重复冲突、来源与责任人可追溯。
先判断一句话里混了哪几类内容
拆分的第一步是分类，不需要改写原文，先对现有条目逐句判断每句话在回答什么问题。三类内容各有自己的判断问题，用同一个问题去问一句话，通常能较快区分。
| 类型 | 判断问题 | 典型内容 | 验收关注点 |
|---|---|---|---|
| 功能需求 | 谁在什么条件下做什么，得到什么结果 | 角色、触发动作、系统响应、结果状态 | 操作完成后结果是否符合描述 |
| 业务规则 | 在什么条件下如何判断、如何计算、有哪些例外 | 阈值、审批条件、计算口径、优先级、例外处理 | 条件成立与不成立时结果是否都正确 |
| 非功能需求 | 需要达到什么质量水平 | 响应时间、并发量、可用性、安全要求、兼容范围 | 能否用指标或测试方法验证 |
混写句式通常有可辨认的特征：一句话里同时出现动作、判断条件和质量形容词。例如“用户提交订单时，若金额超过500元需审批，且页面响应不超过2秒”，前半句是功能动作，中间是业务规则，末尾是非功能要求。再如“管理员可以导出报表，导出文件需脱敏，十万条数据在1分钟内完成”，动作、安全要求和性能指标挤在同一句里。看到“若……则……”“超过……需……”“不低于……”“支持……并发”这类结构，就要留意是否混入了规则或质量约束。
还有一类内容容易被忽略：范围边界。例如“本期只覆盖华东区域”“暂不支持跨境订单”，这类表述说明的是适用范围和边界，既不是功能动作，也不是质量指标。建议单独标记为范围说明，挂在相关需求条目下，避免被误写成功能需求或规则条件。
拆分操作步骤：从一条混写需求到多条可执行条目
分类完成后进入改写。四步流程按顺序执行，每一步都有明确的输入、动作、输出和完成标志，便于多人协作时对齐进度。
第一步：逐句标注类型
输入是原始需求条目，动作是对每句话标注功能、规则、非功能或范围说明，输出是带类型标注的原文。完成标志是原文每一句都有类型归属，没有“说不清”的句子；遇到说不清的句子，先记录待澄清问题，不强行归类。
第二步：抽取业务规则并挂到触发条件
输入是标注为规则的句子，动作是把判断条件、计算口径和例外单独成条，并写明它在哪个功能动作的哪个节点生效。输出是独立的规则条目，每条包含触发条件、判断逻辑、结果和例外。完成标志是每条规则都能回答“什么时候生效、满足什么条件、产生什么结果、例外怎么处理”，并且不再夹带操作动作描述。
第三步：剥离非功能需求并写明度量口径
输入是标注为非功能的句子，动作是把质量形容词换成可验证的指标，写明度量对象、指标值、测量条件和验证方式。输出是独立的非功能需求条目。完成标志是每条都能被测试或评审验证，例如“报表导出在十万条数据、单用户操作条件下，95%的请求在60秒内完成”，而不是“导出要快”。
第四步：回填来源与验收口径
输入是拆分后的全部条目，动作是为每条补上来源（谁提出、依据哪份材料或哪次沟通）、关联对象（属于哪个功能或流程节点）和验收口径（怎么判断做对了）。输出是可进入后续设计与测试的需求清单。完成标志是任意一条需求都能追溯到提出方，并且验收口径具体到可操作的程度。
角色分工与各环节交付物
拆分不是需求分析人员单独完成的文字工作，规则来源需要业务方确认，质量约束需要技术和测试角色把关。明确分工可以减少拆分后反复返工。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 业务方 | 确认业务规则的来源、判断条件和例外情况，说明规则的业务背景 | 规则确认意见、例外场景说明 |
| 需求分析人员 | 执行逐句分类与拆分，统一编号，维护条目之间的关联 | 带类型标注的原始条目、拆分后的需求清单 |
| 架构角色 | 校验非功能需求的技术可行性，补充遗漏的质量约束 | 非功能需求评审意见、指标调整建议 |
| 测试角色 | 校验非功能需求是否可度量、验收口径是否可执行 | 可验证性反馈、验收口径补充 |
交接物建议统一为一份拆分结果清单，包含条目编号、类型、描述、来源、关联对象、验收口径和责任人。评审时按类型分批过：功能需求确认动作与结果，业务规则确认条件与例外，非功能需求确认指标与测量条件。评审结论回写到清单中，形成可追溯的记录。
当拆分后的条目数量增多，分类管理和来源追溯会成为新的负担。ONES 提供统一的需求池与工单体系，业务、产品经理和研发团队可以在同一套工作项中查看需求状态与来源，需求—任务—测试—缺陷形成闭环，便于在拆分后持续跟踪每条条目的处理进度。对于需要借助工具辅助识别待澄清问题的团队，ONES Assistant 可围绕 PRD 质量检查和需求智能生成提炼要点与拆解建议，具体可用范围以实际部署与配置为准。
示例：一条混写需求如何拆成功能、规则与非功能
以下为演示情景，用于说明拆分方法，不代表真实项目。
拆分前的混写原文：“客户在商城提交退货申请时，若订单金额超过1000元或购买超过30天，需要客服主管审批，审批页面要在2秒内打开，并且退货数据要加密存储。”
这句话里包含一个操作动作、两组判断条件、一个性能指标和一个安全要求。按四步流程拆分后得到以下条目。
| 类型 | 拆分后条目 | 说明 |
|---|---|---|
| 功能需求 | 客户在商城对已支付订单提交退货申请，系统生成退货申请单并进入待处理状态 | 只描述角色、动作和结果 |
| 功能需求 | 客服主管在审批页面查看待审批的退货申请，执行通过或驳回操作，系统记录审批结果与审批人 | 审批动作单独成条 |
| 业务规则 | 订单金额超过1000元，或购买时间超过30天，退货申请需经客服主管审批；两个条件满足其一即触发 | 触发条件与逻辑关系写明 |
| 业务规则 | 不满足上述条件的退货申请，由客服专员直接处理，无需主管审批 | 补充例外路径 |
| 非功能需求 | 审批页面在常规网络条件下，95%的请求在2秒内完成加载 | 把“2秒内打开”补成可测量口径 |
| 非功能需求 | 退货相关数据在存储环节采用加密方式，加密范围覆盖申请单中的客户信息与订单信息 | 明确加密对象与环节 |
拆分后可以看到，原文中的“或”被明确为两个条件满足其一，“审批页面2秒”被限定为加载指标并补充了测量条件，加密要求落到具体数据对象上。每条条目只回答一个问题，测试人员可以分别设计功能用例、规则用例和质量验证方案。
拆分完成检查：怎么判断已经拆清楚了
拆分是否到位，可以用一份清单逐项核对。清单不通过时，回到对应步骤修正，不带着混写条目进入后续设计。
- 每条需求只表达一类内容：功能条目里没有判断条件和质量形容词，规则条目里没有操作动作描述，非功能条目里没有功能流程。
- 业务规则有明确的触发条件与例外：能回答条件成立、条件不成立、多个条件并存时分别怎么处理。
- 非功能需求有可验证的度量口径：写明指标、对象、测量条件和验证方式，测试角色能够据此设计验证方案。
- 条目之间无重复与冲突：同一规则不在多个功能条目中重复出现，不同条目对同一条件的判断保持一致。
- 来源与责任人可追溯：每条需求都能找到提出方和确认人，规则变更时有记录可查。
- 范围说明单独标记：适用范围和边界条件挂在相关条目下，没有被写成功能动作或规则条件。
清单全部通过后，拆分结果可以作为需求基线进入设计与测试环节。后续如果业务规则调整，只需修改对应规则条目并同步关联的功能需求，不必重新梳理整条混写需求。
常见问题
一条需求里既有操作动作又有判断条件，拆分时先拆哪部分？
先拆功能动作。功能需求回答“谁做什么、得到什么结果”，是整条需求的骨架；判断条件、计算口径和例外属于业务规则，需要挂到具体功能动作的某个节点上才说得清生效时机。如果先抽规则，容易出现规则找不到归属动作、拆分后条目之间对不上的情况。实际操作中可以先标出动作和结果，再把条件类表述移到规则条目，并注明它作用于哪个功能动作的哪个环节。
业务规则拆分后，例外情况很多，是否需要每条都单独成条？
按例外的影响范围决定。影响审批路径、金额计算、权限判断的例外，建议单独成条，写明触发条件和处理结果，便于测试分别设计用例；仅影响提示文案或展示顺序的例外，可以合并到同一规则条目的例外说明中。判断标准是这条例外是否需要独立的验收口径：需要就单独成条，不需要就作为附属说明。例外较多的规则，建议由业务方一次性确认完整清单，避免拆分过程中陆续补充导致条目反复变更。
非功能需求写不出具体指标，只有“要快、要稳定”这类描述，怎么办？
先把形容词换成可观察的对象和条件，再逐步补数值。可以问三个问题：在什么操作、多大数据量、什么网络或部署条件下要快；稳定指多长时间内可用、故障后多久恢复；安全指哪些数据、在传输还是存储环节、防什么风险。回答后形成“度量对象＋条件＋指标值＋验证方式”的结构。指标值暂时无法确定的，先标注待定并写明由谁在什么阶段确认，不把模糊描述直接带入设计与测试。
拆分后的条目数量明显变多，怎么管理才不混乱？
关键是统一编号和分类，并保留条目之间的关联。每条需求标注类型（功能、规则、非功能、范围说明）、来源、关联对象和责任人，规则条目注明作用于哪个功能动作。条目增多后，可以借助工作项体系分类管理：ONES 提供统一的需求池与工单体系，业务、产品经理和研发团队可以在同一套工作项中查看需求状态与来源，需求—任务—测试—缺陷形成闭环，便于跟踪每条条目的处理进度（具体配置以实际部署为准）。分类清晰后，规则调整只需修改对应条目并同步关联功能需求。
拆分完成后业务规则又发生变化，前面的拆分是否要重做？
通常不需要重做，只需定位受影响的规则条目及其关联的功能需求和非功能需求。拆分后的条目各自独立，规则变更时修改规则条目，检查关联功能需求的描述是否仍然成立，再确认验收口径是否同步更新。为支持这种变更，拆分阶段就要记录每条规则的来源和关联对象，并在变更时保留修改记录。如果变更涉及范围边界调整，同步更新范围说明，避免旧边界继续挂在需求下造成误解。
