一段需求里同时写着“审批通过后生成订单”“仅当库存充足才允许提交”“页面响应不超过2秒”“本期不含跨境结算”，读起来信息齐全，落到开发和测试却难以逐条确认。本文给出识别与拆分方法：先按“触发—动作—结果”把混杂描述切成可判断的片段，再逐片归入功能需求、业务规则、非功能需求或范围说明，最后按统一格式重写，使每条内容都能被单独管理、验证和追溯。
要点总览（TL;DR）
- 先按“触发—动作—结果”把混杂描述切成可独立判断的片段，再逐片判定归属，避免整段直接改写。
- 判定顺序：行为可被外部观察归功能需求；约束其他功能执行条件或计算口径归业务规则；描述性能、安全、可用性等质量属性归非功能需求；只交代背景或本期不做归范围说明。
- 重写时一条功能需求只保留一个主语、一个触发、一个可验证结果；业务规则单独编号，由功能需求引用而非复制。
- 非功能需求要写明质量属性、度量对象、带单位的指标与验证方式，指标口径由业务方与技术角色共同确认。
- 拆分完成后检查同一条件是否只在一处定义、规则与功能需求能否双向追溯、范围排除项是否残留为功能描述。
先判断一句话里混了哪几类内容
拆分的第一步是识别，先不急着改写。面对一段混杂描述，把它按句或按分句切开，每片只保留一个可以独立判断的陈述，再用“触发—动作—结果”骨架检查：这句话说的是谁在什么条件下做了什么、得到什么可观察的结果。骨架填不满的片段，往往就是规则、指标或背景混进来了。
切分之后，对每个片段依次问四个判定问句，第一个命中的即为归属：
- 行为是否可被外部观察？用户、外部系统或接口能感知到某个动作发生并产生结果，归功能需求。例如“提交申请后系统生成待审批记录”。
- 是否约束所有相关功能的执行条件或计算口径？它本身不产生新行为，但决定其他功能在什么条件下成立、金额怎么算、状态怎么流转，归业务规则。例如“仅当账户余额不低于订单金额时才允许下单”。
- 是否为质量属性？描述性能、安全、可用性、容量、兼容性等系统整体或某功能的质量水平，归非功能需求。例如“订单查询响应时间不超过2秒”。
- 是否只是背景或边界？既不改变系统行为，也不构成质量约束，只是交代来源、目的或本期不做的事，归范围说明或背景。
混杂句通常有明显信号词。“仅当……才……”“除非……否则……”多指向业务规则；“不超过”“不低于”“至少”“7×24”多指向非功能指标；“为了支持……”“本期暂不涉及……”多指向背景与范围。信号词只是提示，最终仍以判定问句的结论为准。下表可用于逐句切分：
| 句子片段 | 判定问句 | 初步归类 |
|---|---|---|
| 提交申请后系统生成待审批记录 | 行为可观察 | 功能需求 |
| 仅当申请人所属部门负责人已配置时才进入审批 | 约束功能执行条件 | 业务规则 |
| 审批列表加载时间不超过2秒 | 质量属性 | 非功能需求 |
| 本期先覆盖总部，分支机构后续纳入 | 背景与边界 | 范围说明 |
这一阶段只做识别与初步归类，产出一张切分判定表即可。结构化建模、正式评审与确认属于后续环节，不在拆分动作内展开。
按四类归属重写：功能需求、业务规则、非功能需求、范围说明
归类完成后，每一类按各自的格式重写，目标是让条目可以直接进入需求文档并被验证。重写的核心原则是：一条功能需求只保留一个主语、一个触发、一个可验证结果；业务规则单独编号，由功能需求引用，不复制进功能描述。
功能需求：角色、触发、动作、可验证结果
推荐句式：“当［触发条件］时，［角色］可以［动作］，系统［可验证结果］。”例如：“当审批人打开待办列表时，审批人可以对待审批申请执行通过或驳回，系统记录审批人、审批时间与审批意见。”结果部分要能被测试判断，避免“处理”“支持”这类无法验证的动词单独出现。
业务规则：条件与结论、计算口径、适用范围
业务规则写成“如果［条件］，则［结论］”，涉及计算的要写清口径与边界，并标注适用范围。每条规则给唯一编号，例如“BR-012：如果申请人所属部门负责人未配置，则申请不进入审批，状态置为待补充”。功能需求在需要时写“遵循 BR-012”，规则调整时只改规则条目，引用它的功能需求无需逐条修改。
非功能需求：质量属性、度量对象、指标与验证方式
一条非功能需求至少包含四项：质量属性（性能、安全、可用性等）、度量对象（哪个功能或哪条链路）、指标（含单位与统计口径）、验证方式（压测、渗透测试、监控采样等）。例如：“审批列表在1000条待办、50并发用户条件下，95分位响应时间不超过2秒，由性能测试报告验证。”指标口径需要业务方与技术角色共同确认，避免“响应快”“高可用”这类无法验收的表述。
范围说明与背景：明确不进入本期实现的内容
范围说明写成清单式排除项，并注明来源与决策时间。例如：“本期不包含分支机构审批流程配置，计划下一期评估。”背景只保留理解需求所必需的信息，不夹带行为描述或指标。
处理重复表述的方法：同一内容只在一个位置定义。判定条件写在业务规则里，功能需求引用编号；质量指标写在非功能需求里，功能需求只写“满足 NFR-03”。重写完成后通读一遍，凡是在两处出现相同条件或相同数字的，保留一处、另一处改为引用。
角色分工与拆分后的交付物
拆分不是需求分析人员独自完成的工作。规则口径需要业务方确认，指标可验证性需要技术角色把关，否则拆出来的条目仍然无法验收。下表给出常见分工，团队可按规模调整角色合并方式。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 需求提出方与业务方 | 确认业务规则的条件、结论与计算口径，确认范围排除项 | 规则口径确认记录、范围说明 |
| 需求分析人员 | 逐句切分、判定归类、按四类格式重写 | 需求条目、规则清单、非功能指标表、范围说明 |
| 技术角色（开发、测试、架构） | 确认非功能指标可测量、验证方式可执行，评估规则对实现的影响 | 指标与验证方式确认意见 |
| 需求分析人员与业务方 | 规则变更时同步更新规则条目，并检查引用它的功能需求 | 变更记录与受影响条目清单 |
拆分产物建议保持四种形态：功能需求条目（含编号与验收结果）、业务规则清单（编号、条件、结论、适用范围）、非功能指标表（属性、对象、指标、验证方式）、范围说明（排除项与原因）。规则变更时的同步责任落在需求分析人员身上：先改规则条目，再逐一核对引用关系，确认没有条目仍在描述旧口径。
当这些条目需要在同一体系中维护与追溯时，可以借助需求池、工单与任务看板统一承载。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，构建需求—任务—测试—缺陷的闭环；业务、产品经理与研发三类视角可以基于同一需求池和看板同步状态、追溯需求与问题。拆分出的功能需求、规则引用关系与验证任务可以在这样的结构中建立关联，规则调整时沿引用关系找到受影响的条目。ONES Assistant 可围绕 PRD 质量检查与需求智能生成提炼要点、待澄清问题与拆解建议，适合在拆分前辅助识别混杂内容，具体输出形态以实际产品版本为准。
一个混杂需求的拆分示例
以下为演示情景。原始描述来自一段采购申请需求：
“采购申请提交后进入审批，仅当申请金额超过5万元时才需要部门总监审批，审批通过后系统生成采购订单并通知申请人。审批页面在200人同时在线时响应时间不超过2秒。本期不包含供应商门户对接，供应商信息由采购员手工录入。”
逐句切分与归类：
| 片段 | 判定依据 | 归类 |
|---|---|---|
| 采购申请提交后进入审批 | 行为可观察 | 功能需求 |
| 仅当申请金额超过5万元时才需要部门总监审批 | 约束审批功能的触发条件 | 业务规则 |
| 审批通过后生成采购订单并通知申请人 | 行为可观察，但含两个结果，需再切 | 功能需求（两条） |
| 审批页面在200人同时在线时响应时间不超过2秒 | 质量属性，含度量对象与指标 | 非功能需求 |
| 本期不包含供应商门户对接 | 边界排除 | 范围说明 |
| 供应商信息由采购员手工录入 | 行为可观察 | 功能需求 |
重写后的条目：
- FR-01：当采购员提交采购申请时，系统生成待审批记录，状态为待审批。
- FR-02：当审批人打开待办列表时，审批人可以执行通过或驳回，系统记录审批人、时间与意见。
- FR-03：当采购申请审批通过时，系统生成采购订单，订单号与申请单号关联。
- FR-04：当采购订单生成时，系统向申请人发送通知，通知内容包含订单号。
- FR-05：当采购员录入供应商信息时，系统保存供应商名称与联系方式，必填项为空时不允许保存。
- BR-01：如果采购申请金额超过5万元，则审批链路包含部门总监节点；金额不超过5万元时，审批链路至部门经理结束。适用范围：总部采购申请。
- NFR-01：审批页面在200人同时在线条件下，95分位响应时间不超过2秒，由性能测试验证。
- 范围说明：本期不包含供应商门户对接，供应商信息由采购员手工录入；门户对接列入后续评估。
引用关系上，FR-02 的审批链路写“遵循 BR-01”，不再重复金额阈值；NFR-01 在验收标准中引用，FR-02 的功能描述不写响应时间。示例中的判定依据与第一部分的四个问句一一对应：可观察行为、执行条件、质量属性、边界排除。
拆分完成的检查项
拆分是否到位，可以按以下清单逐项核对。全部通过再进入评审环节。
- 每条功能需求只有一个主语、一个触发、一个可验证结果，结果部分能被测试判断为通过或不通过。
- 每条业务规则有唯一编号，写明条件、结论与适用范围；功能需求以编号引用，正文中不出现复制来的阈值或计算口径。
- 每条非功能需求包含质量属性、度量对象、带单位的指标与验证方式，指标口径已由业务方与技术角色确认。
- 全文检索关键数字与条件词，确认同一条件只在一处定义，不存在两条条目给出不同口径的情况。
- 范围说明列出本期排除项及原因，排除项没有以功能需求的形式残留在正文中。
- 规则清单与引用它的功能需求能双向找到：从规则能列出受影响条目，从条目能定位所引规则。
- 拆分产物四种形态齐全：需求条目、规则清单、非功能指标表、范围说明，且编号体系一致。
检查中发现条目仍含“同时”“并且”连接的两个结果，或规则条件散落在多条功能描述里，回到切分步骤重新处理，不必在重写阶段反复修补。
常见问题
业务规则和功能需求看起来都在描述“系统怎么处理”，怎么区分？
看它是否产生新的可观察行为。功能需求描述系统对外表现出的动作和结果，例如“提交申请后生成待审批记录”；业务规则本身不产生新行为，它约束其他功能在什么条件下成立、金额怎么算、状态怎么流转，例如“仅当金额超过5万元才需要总监审批”。
实操中可以这样判断：把这条内容删掉，如果某个功能仍然存在、只是触发条件或计算口径变了，它更可能是业务规则；如果删掉后某个动作或结果消失了，它更可能是功能需求。归类后让功能需求以编号引用规则，规则调整时只改一处。
非功能需求里的指标由谁定，需求分析人员能直接写吗？
指标口径需要业务方与技术角色共同确认。需求分析人员负责把质量属性、度量对象、指标和验证方式写完整，但“95分位响应时间不超过2秒”“200人同时在线”这类口径涉及业务期望和测试可行性，应由业务方确认期望水平，由开发、测试或架构角色确认可测量、验证方式可执行。
如果暂时无法确认具体数值，可以先记录待定项和确认责任人，避免用“响应快”“高可用”这类无法验收的表述占位后直接进入开发。
拆分后规则改了，怎么保证引用它的功能需求不出错？
关键是让规则只有一个定义位置，功能需求只写规则编号。规则变更时，先更新规则条目，再沿引用关系逐一核对受影响的功能需求，确认没有条目仍在描述旧口径。
拆分产物如果分散在文档、表格和任务系统里，建议在需求条目上保留规则编号字段，使“从规则找条目”和“从条目找规则”都能完成。变更记录中同时写明受影响的条目清单，便于评审时集中检查。
一段描述里同时出现两个结果，比如“审批通过后生成订单并通知申请人”，必须拆成两条吗？
建议拆开。一条功能需求只保留一个可验证结果，两个结果意味着两个验收点，合并后测试难以分别判断通过与否，后续某一部分调整也会牵连整条需求。
拆成“审批通过后生成采购订单”和“订单生成后向申请人发送通知”两条，各自有独立触发和结果，还能分别安排实现与验证。拆分时注意保留两者之间的先后关系，避免拆完后丢失业务上的依赖。
范围说明里写的排除项，后来又要做了，怎么处理？
把排除项从范围说明中移出，按功能需求或业务规则的格式重新编写，并注明来源与决策时间。范围说明保留“本期不做”的结论和原因，新增内容进入需求条目，两者不混写。
如果排除项涉及新的业务规则或质量指标，同步补充规则清单和非功能指标表，并检查是否与已有条目冲突。这样范围变化有记录可查，也不会让旧的范围说明与新需求同时存在、互相矛盾。
