父需求、子需求和验收条件混在一起，常见结果是父需求写成了功能清单，子需求看不出服务哪个目标，验收条件散落在讨论记录里。用一张分层条目模板可以把三者分开：父需求只写目标、范围边界和成功度量；子需求挂在父需求下，写可独立交付的功能切片并保留父需求编号；验收条件作为子需求（必要时父需求）的附属字段，用可观察、可判定的语句逐条列出。下面给出字段分工、搭建步骤、角色安排、来源追踪方式、填写示例和自检清单，可直接照着建立模板。
要点总览（TL;DR）
- 父需求只写目标、范围边界、成功度量、优先级和状态，功能步骤与技术方案放到子需求或设计材料里。
- 子需求是父需求下可独立交付、独立验证的功能切片，用“父需求编号加序号”的编号规则保证可追溯。
- 验收条件不单独成层，作为所属条目的附属字段，一条只写一个可判定结果，并包含前置条件、预期结果和验证方式。
- 来源信息独立成字段组，记录提出人、原始材料出处、整理人和整理时间；追踪关系只记编号，不复制被指向条目的内容。
- 模板落地前用自检清单核对：父需求无实现细节、子需求唯一归属、验收条件可独立验证、编号连续无歧义。
模板先定三层：父需求、子需求、验收条件各写什么
三层分工的核心原则是：同一信息只在一个层级填写，其他层级通过编号引用。父需求回答“为什么做、做到什么范围算完成”，子需求回答“分几块交付、每块由谁负责”，验收条件回答“凭什么判定这一条已经满足”。
| 层级 | 必填字段 | 选填字段 | 不写什么 |
|---|---|---|---|
| 父需求 | 父需求编号、目标、范围边界（含不做什么）、成功度量、优先级、状态 | 关联目标或业务背景、目标版本 | 具体功能步骤、界面细节、技术实现方案 |
| 子需求 | 子需求编号、父需求编号、功能切片描述、依赖、负责人、状态 | 预估工作量、计划交付时间 | 重复父需求的目标与范围、完整验收清单 |
| 验收条件 | 所属条目编号、判定语句、前置条件、预期结果、验证方式 | 验证人、验证环境 | 新的需求内容、模糊的“体验良好”类表述 |
父需求的“范围边界”要同时写清包含什么和不包含什么，这是后续判断子需求是否越界的主要依据。成功度量用可比较的指标或可观察的状态描述，例如“订单导出在约定数据量下完成且结果与页面筛选一致”，避免只写“提升效率”。
子需求是父需求下可独立安排、独立验证的功能切片。一个子需求应能单独交付并单独判断完成，拆分粒度以“一个负责人能在一段计划周期内完成”为参考。子需求描述聚焦本切片的行为和范围，父需求的目标通过编号关联，不在子需求里重复叙述。
验收条件不单独成层，作为附属字段挂在所属条目下。每条验收条件只对应一个可判定结果，写清前置条件、操作或输入、预期结果和验证方式。父需求层面的验收条件用于判断整体目标是否达成，子需求层面的验收条件用于判断切片是否完成，两者都引用所属条目编号，不另建编号体系。
按步骤搭建模板：从字段定义到层级编号
搭建模板按以下四步推进，每步都有明确产出，完成标志是下一步的输入已经具备。
第一步：确定编号规则。输入是团队现有的需求来源和项目划分方式；动作是约定“前缀加序号”的格式，父需求与子需求使用可区分的前缀，例如父需求用 PR-001，其下子需求用 PR-001-01、PR-001-02；输出是一页编号规则说明；完成标志是任意一条子需求仅凭编号就能看出归属的父需求。编号一经分配不重复使用，需求关闭后编号保留，便于历史记录回溯。
第二步：定义必填与选填字段。输入是第一步的编号规则和上一节的三层字段表；动作是逐字段标注必填或选填，必填字段控制在能支撑判断的最小集合，选填字段按团队实际需要保留；输出是带必填标记的模板；完成标志是用一条真实需求试填，不需要额外解释就能填完必填项。模板过重会让人绕开它，宁可先少几个字段，运行一段时间后再补充。
第三步：设定验收条件的书写规则。输入是子需求的切片描述；动作是把每条验收条件改写成“前置条件—操作或输入—预期结果—验证方式”的结构，一条只写一个结果；输出是验收条件书写规范和正反例；完成标志是任意一条验收条件都能由另一名成员按描述独立验证，并给出一致的通过或不通过结论。
第四步：把来源信息拆成独立字段组。输入是需求提出时的原始材料，包括会议记录、用户反馈、工单等；动作是在模板中单设来源字段组，与需求正文分区存放；输出是带来源字段组的完整模板；完成标志是每条需求都能从来源字段找到原始出处，且正文中不夹杂引用原文。
角色与交付物：谁填父需求、谁写子需求、谁确认验收条件
字段有人负责，模板才能持续运行。下表给出常见分工，团队规模较小时可由一人兼任多个角色，但每个字段仍需明确到角色而非“大家共同维护”。
| 角色 | 负责字段 | 交付物 | 交接时点 |
|---|---|---|---|
| 需求提出方 | 目标、业务背景、来源信息 | 需求来源说明与原始材料 | 需求进入整理前 |
| 产品角色 | 父需求的目标、范围边界、成功度量、优先级、状态 | 填写完整的父需求条目 | 拆分启动前 |
| 研发或业务分析角色 | 子需求的功能切片描述、依赖、负责人 | 子需求条目及编号 | 开发排期前 |
| 测试或验收方 | 验收条件的判定语句、前置条件、预期结果、验证方式 | 逐条可验证的验收条件 | 子需求进入开发前或开发中同步完成 |
| 评审参与者 | 层级归属确认 | 评审结论与修改记录 | 父需求与子需求拆分完成后 |
评审环节重点确认三件事：每条子需求是否只归属一个父需求；子需求是否都在父需求的范围边界内；验收条件是否覆盖子需求描述的行为。评审发现层级归属错误时，修改编号和归属字段，并在变更记录中留下原因，不直接删除原条目。
来源信息与追踪关系怎么记
来源信息与需求正文分开存放，原因是两者的用途不同：正文用于判断做什么和怎么验收，来源用于回溯“这条需求从哪来、谁提出的、依据什么材料”。混在一起会让正文变长，也会让后续变更难以区分是需求内容变化还是来源补充。
来源字段组建议包含：提出人、原始材料出处（会议、反馈渠道、工单编号等）、整理人、整理时间。原始材料出处写到可定位的程度，例如某次会议记录的名称和日期，便于他人复核。
追踪关系通过编号字段建立：子需求的“父需求编号”字段指向唯一父需求；验收条件的“所属条目编号”字段指向所属子需求或父需求。追踪关系只记录编号，不复制被指向条目的内容，避免同一信息在多处修改后不一致。
变更记录字段包含修改内容、修改人、修改原因和修改时间。范围边界调整、成功度量变更、子需求重新归属这类修改必须记录原因；文字措辞的微调可合并记录。变更记录按条目追加，不覆盖历史记录。
在工具中落地时，可以把父需求与子需求建成有父子关系的工作项，验收条件作为子工作项下的检查项或独立条目维护，来源字段组放在描述区的固定位置。ONES 支持工作项、迭代与 Wiki 页面等上下文的管理，ONES Assistant 可围绕需求澄清提炼要点、待澄清问题与拆解建议，帮助团队更快完成需求整理和录入；具体字段结构以团队模板为准。
示例：一条父需求拆成子需求并配验收条件
以下为演示情景，用于展示模板填写形态。
父需求 PR-001：目标为支持运营人员在后台按条件筛选订单并导出结果文件。范围边界包含按时间、状态、渠道筛选和导出当前筛选结果；不包含导出任务排队调度和跨系统数据同步。成功度量为运营人员使用该功能完成一次筛选导出，结果条数与页面筛选结果一致。优先级为高，状态为已拆分。
子需求 PR-001-01：实现订单列表的时间、状态、渠道三个筛选条件组合查询。依赖为订单查询接口可用，负责人为研发甲，状态为开发中。
子需求 PR-001-02：实现按当前筛选条件导出结果文件。依赖 PR-001-01 完成，负责人为研发乙，状态为待开发。
子需求 PR-001-03：在导出入口展示当前筛选条件摘要，便于操作前确认。依赖 PR-001-01 完成，负责人为研发甲，状态为待开发。
PR-001-02 的验收条件示例：前置条件为已登录且有导出权限，操作选择时间范围与状态后点击导出，预期结果为生成的文件仅包含符合筛选条件的订单且条数与列表一致，验证方式为测试环境比对列表与文件条数。PR-001-01 的验收条件示例：分别选择单一条件和组合条件查询，预期结果为列表仅展示符合全部所选条件的订单，验证方式为按条件构造测试数据逐项核对。PR-001-03 的验收条件示例：修改筛选条件后进入导出入口，预期结果为摘要与当前筛选条件一致，验证方式为人工核对。
来源字段组记录：提出人为运营负责人，原始材料出处为某次运营例会记录及对应反馈工单，整理人为产品角色，整理时间为需求录入当天。追踪关系上，三条子需求的父需求编号均为 PR-001，各验收条件的所属条目编号分别指向对应子需求。
完成检查：模板是否真的区分清楚了三层
模板投入使用前，用以下清单逐项核对，每项都能给出明确的是或否。
- 父需求条目中只出现目标、范围边界、成功度量、优先级和状态，没有功能步骤或技术实现细节。
- 每条子需求都有父需求编号，且只指向一个父需求；不存在无归属的子需求。
- 子需求描述落在父需求的范围边界内，边界外内容已单独提出或明确排除。
- 每条验收条件只描述一个可判定结果，包含前置条件、预期结果和验证方式，没有“体验良好”“尽量快”这类无法判定的表述。
- 每条验收条件都能由未参与编写的成员独立验证，并得出一致结论。
- 来源字段组完整记录提出人、原始材料出处、整理人和整理时间，正文中没有夹杂原始材料摘录。
- 变更记录包含修改内容、修改人、修改原因，历史记录未被覆盖。
- 父需求与子需求编号连续、前缀可区分，任意编号都能判断其层级和归属。
清单中出现“否”的条目，回到对应步骤修正字段或规则，再重新核对。模板运行一段时间后，可结合评审中反复出现的问题调整必填字段，保持模板与团队实际填写能力匹配。
常见问题
父需求的范围边界应该写到什么程度，才够用来判断子需求是否越界？
范围边界要写到能直接对照判断的程度：既列出包含的内容，也列出明确不做的内容。判断标准是，拿一条子需求来对照，团队成员能得出一致结论，不需要再回去问提出人。如果边界只写“订单相关功能”，子需求是否包含导出、是否包含跨系统同步就无法判断；写成“包含按时间、状态、渠道筛选和导出当前筛选结果，不包含导出任务排队调度和跨系统数据同步”，归属判断就有依据。范围边界调整时同步更新变更记录，避免子需求拆分依据失效。
一个子需求能不能对应多条父需求，或者一条验收条件覆盖多个子需求？
建议保持单一归属：每条子需求只指向一个父需求，每条验收条件只挂在所属的一个条目下。一条子需求同时服务两个父需求时，通常说明父需求的划分本身有重叠，或者这条子需求承担了跨目标的职责，应回到父需求层面重新划分范围。验收条件覆盖多个子需求，会导致某条子需求完成而另一条未完成时无法判断整体是否通过。确有共用逻辑时，可以拆成各自归属的子需求，在依赖字段中互相引用，不靠共享条目解决。
团队规模小、角色由一人兼任时，这套角色分工还需要保留吗？
需要保留字段责任，角色可以合并。模板运行的关键是每个字段都有明确的责任人，而不是必须由不同的人填写。一人兼任产品与研发分析角色时，父需求与子需求仍分条目填写，验收条件仍按可判定规则书写，评审环节可以邀请未参与编写的同事做一次独立核对。这样做的目的是让层级和验收标准经得起他人复核，兼任本身不影响模板结构。团队扩大后再按角色拆分职责，字段和编号规则不需要重做。
需求在开发过程中范围发生变化，模板里的哪些字段要改、怎么留痕？
范围变化先改父需求的范围边界和成功度量，再检查受影响子需求的归属与描述，最后同步调整对应验收条件。三类修改都要写入变更记录，记录修改内容、修改人、修改原因和修改时间，按条目追加，不覆盖历史记录。新增子需求沿用原父需求编号续号，已关闭的子需求编号保留不复用。如果变化大到原父需求的目标已不成立，应新建父需求并说明与原条目的关系，避免在原条目上反复改写导致历史无法回溯。
把模板放进工具管理时，父需求、子需求和验收条件分别对应什么形态？
常见做法是把父需求与子需求建成有父子关系的工作项，验收条件作为子工作项下的检查项或独立条目维护，来源字段组放在描述区的固定位置。ONES 支持工作项、迭代与 Wiki 页面等上下文的管理，ONES Assistant 可围绕需求澄清提炼要点、待澄清问题与拆解建议，帮助团队更快完成需求整理和录入；具体字段结构以团队模板为准。工具形态服务于模板规则，编号与归属关系仍需在字段中显式记录，不能只依赖界面层级。
