需求层级命名规范要解决的是“同一类需求在不同层级上怎么写名字、填哪些字段、由谁校验”。制定时先固定业务需求、产品需求、系统需求、子需求四层结构，再为每层设计命名模板和字段表，最后用真实需求试填并组织评审。本文给出可直接套用的层级定义表、命名模板、字段规则、角色分工和验收清单。
要点总览（TL;DR）
- 命名规范建立在层级体系之上：先固定业务需求、产品需求、系统需求、子需求四层，明确每层的判定问题、责任角色和父子约束，再设计命名模板。
- 每层给一个固定模板，由层级标识、业务域或模块、对象、动作或结果四段组成；编号与标题分开管理，编号不随标题修改而变化。
- 把规范落成字段表，层级、编号、标题、父级、业务域、状态、负责人设为必填，并写明唯一性、父子一致性、同层重名检测的校验口径。
- 规范由起草人编写、产品研发测试组成评审组、维护人统一处理变更；检查动作放在需求提交环节，评审会只讨论内容和优先级。
- 用3至5条真实需求试填并保留记录，按验收清单逐项核对后发布；业务域新增、同类命名问题重复出现、层级调整或字段配置变更时触发复审。
先定层级，再定名字：命名规范的前置结构
命名规则依附于层级体系。层级没有定清楚，标题里就会出现“产品需求写着系统改造内容”“子需求标题与父级重复”这类问题。制定规范的第一步，是把团队使用的需求层级、每层的判定问题和责任角色写成一张表，让命名有稳定的挂靠对象。
常见的四层划分如下。判定问题时按从上到下的顺序提问，一个问题只归入一层，避免同一条内容被两层同时认领。
| 层级名称 | 判定问题 | 责任角色 | 典型粒度 | 父子关系 |
|---|---|---|---|---|
| 业务需求 | 这项需求要解决哪个业务问题、服务哪类用户或场景？ | 业务负责人、产品负责人 | 一个业务目标或用户场景，可跨多个产品模块 | 顶层，通常无父级 |
| 产品需求 | 为支撑该业务需求，产品要提供什么能力或体验？ | 产品经理 | 一个可独立验收的产品能力或功能范围 | 父级为业务需求，可一对多 |
| 系统需求 | 产品能力落到哪个系统、接口或数据对象上实现？ | 系统分析师、研发负责人 | 一个系统行为、接口或数据处理要求 | 父级为产品需求，可一对多 |
| 子需求 | 系统需求还需要拆成哪些可分配、可验证的细项？ | 研发、测试 | 一个可分配给单人或小组的细项 | 父级为系统需求 |
父子关联需要遵守几条基本约束：每条需求只有一个直接父级；父级关闭前，子级的状态变化要在评审中说明；跨层引用用关联关系表达，不用复制标题的方式代替。层级表还要写清与任务拆解的边界——需求层级描述“要做什么、做到什么程度”，任务拆解描述“谁在什么时间做哪些执行动作”，两者分开管理，命名规范只约束需求侧。
这张层级定义表是后续命名模板和字段表的依据。层级名称一旦确定，命名模板中的层级前缀、字段表中的层级枚举值都从这里取值，避免各团队自行发明层级叫法。
命名模板怎么设计：层级前缀、业务域与标题结构
每层需求给一个固定模板，模板由四段组成：层级标识、业务域或模块、对象、动作或结果。四段用统一分隔符连接，团队内只使用一种写法。层级标识让读者一眼看出这是哪一层需求；业务域或模块限定范围；对象说明作用于什么；动作或结果说明要达成什么状态。
标题长度建议控制在20至40个汉字，超过时优先检查是否把实现方案写进了标题。标题中避免“优化一下”“相关功能”“若干问题”这类模糊词，也避免出现具体技术方案、页面布局或代码类名——这些内容放在描述字段里，标题只保留可识别的对象和结果。
编号与标题分开管理。编号用于唯一识别和排序，建议采用“层级缩写-业务域缩写-四位流水号”的结构，例如业务需求用BR、产品需求用PR、系统需求用SR、子需求用SUB。编号一经分配不随标题修改而变化，标题调整时保留原编号，便于评审记录和关联引用保持连续。
四层模板的差异主要体现在对象和动作的抽象程度上：越靠上的层级，对象越偏业务概念；越靠下的层级，对象越偏系统行为或数据。参考示例如下。
| 层级 | 命名模板 | 合规示例 | 不合规示例与问题 |
|---|---|---|---|
| 业务需求 | [BR] 业务域-对象-业务结果 | [BR] 订单-退换货-缩短售后处理周期 | “把退货页面改版”——写成了方案，缺少业务结果 |
| 产品需求 | [PR] 模块-对象-产品能力 | [PR] 售后-退货申请-支持线上提交与进度查询 | “退货功能优化”——对象和结果都不明确 |
| 系统需求 | [SR] 系统-对象-系统行为 | [SR] 订单服务-退货单-生成并同步状态 | “退货相关接口调整”——对象模糊，无法验证 |
| 子需求 | [SUB] 模块-细项-可验证结果 | [SUB] 退货申请-表单校验-必填项拦截提示 | “开发退货表单”——描述动作而非可验证结果 |
模板确定后，先让产品经理按模板改写3至5条存量需求，观察是否出现同一对象多种叫法、动作词不统一的情况。把高频用词整理成简短的术语对照，附在模板说明后面，比在规范里写大段措辞要求更容易执行。
字段表与填写规则：必填项、选填项和校验口径
命名规范要落成字段表，才能被系统录入和评审引用。字段表列出每个字段的名称、是否必填、格式约束、填写人和校验方式，命名模板中的各段对应到具体字段，标题不再是一段自由文本。
| 字段 | 必填 | 格式约束 | 填写人 | 校验方式 |
|---|---|---|---|---|
| 层级 | 必填 | 枚举：业务需求/产品需求/系统需求/子需求 | 需求提出人或产品经理 | 创建时下拉选择，与父级层级匹配校验 |
| 编号 | 必填 | 层级缩写-业务域缩写-四位流水号，全局唯一 | 系统生成或产品经理分配 | 唯一性校验，禁止手工复用 |
| 标题 | 必填 | 按层级模板填写，20至40个汉字 | 需求提出人 | 长度检查、模糊词检查、同层重名检测 |
| 父级 | 必填（业务需求除外） | 引用已有需求编号，层级为上一级 | 产品经理或系统分析师 | 父子层级一致性校验，禁止跨级挂接 |
| 业务域 | 必填 | 取自团队维护的业务域清单 | 需求提出人 | 枚举校验，新增业务域需登记 |
| 状态 | 必填 | 草稿/评审中/已确认/已关闭 | 需求负责人 | 状态流转规则校验 |
| 负责人 | 必填 | 单个责任人 | 产品经理 | 人员有效性校验 |
| 验收说明 | 选填 | 自由文本，建议写可观察结果 | 需求负责人 | 评审时人工检查 |
必填与选填的划分依据是“缺了它就无法判断层级归属或无法追溯”。层级、编号、标题、父级、业务域、状态、负责人这七项缺任何一项，需求都无法进入评审，因此设为必填；验收说明在草稿阶段可以留空，进入评审前补齐即可。
校验口径要写具体：编号唯一性由系统保证，人工只负责分配规则；父子一致性检查父级层级是否为当前层级的上一级，以及父级状态是否允许新增子级；命名重复检测在同一父级下比对标题，发现相似标题时提示合并或说明差异。字段变更由规范维护人统一处理，业务域清单的新增由产品负责人提出、维护人登记后生效，避免各团队自行扩展枚举值。
当团队使用需求管理工作项承载这些字段时，可以把层级、业务域设为单选字段，父级用工作项关联表达，标题长度和必填项通过字段配置约束。ONES 支持在工作项类型中配置字段与必填规则，并可通过工作项关联建立父子关系，规范中的字段表可以直接对应到这类配置，减少人工检查。具体配置方式以团队实际使用的版本为准。
角色分工与落地流程：从起草到纳入日常
规范由谁写、谁审、谁维护，需要在发布前定下来，否则试填阶段收集的意见无人裁决，规范发布后也容易失效。建议设置三个角色：规范起草人、评审组、规范维护人。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 规范起草人 | 编写层级定义表、命名模板、字段表，组织试填 | 规范初稿与试填记录 |
| 评审组 | 产品、研发、测试各派代表，检查模板可写性、字段可填性、校验可执行性 | 评审意见与通过结论 |
| 规范维护人 | 发布规范、登记业务域、处理字段变更、组织复审 | 规范正式版与变更记录 |
落地流程按以下步骤推进：
- 起草人完成初稿，附四层模板和字段表，选定3至5条真实需求试填，形成试填记录。
- 评审组按通过标准逐项检查：每条试填需求能按模板写出标题、字段无空缺、父子关系可建立、校验规则能被执行。三项以上不满足则退回修改。
- 分歧处理以试填结果为依据，由评审组多数意见决定；涉及层级划分的争议，由产品负责人裁定并记录理由。
- 规范发布到团队文档的固定位置，与需求创建入口放在一起，新成员入职培训时用一条真实需求演示填写。
- 需求创建时执行检查动作：层级与父级是否匹配、标题是否符合模板、必填字段是否齐全；不符合的退回草稿，紧急需求可先创建后在一个工作日内补齐，补齐记录由维护人抽查。
规范嵌入日常的关键是把检查动作放在需求评审之前，而不是评审会上临时纠正命名。评审会只讨论需求内容和优先级，命名问题在提交环节解决。
试填示例：三条真实需求走完命名与评审
以下示例为演示情景，用于说明模板如何被使用，不代表任何具体企业的真实项目。
背景：某电商团队的售后模块计划改善退货体验。选取一条业务需求、一条产品需求和一条子需求试填，系统需求层因涉及接口细节，由研发在评审时补充。
| 层级 | 试填名称 | 关键字段 | 评审发现的问题 | 修正后 |
|---|---|---|---|---|
| 业务需求 | [BR] 售后-退货-降低退货处理时长 | 业务域：售后；负责人：业务负责人；父级：无 | “降低”缺少目标口径，评审要求补充衡量方式到验收说明 | 标题保留，验收说明补充“以退货单平均处理时长衡量” |
| 产品需求 | [PR] 售后-退货申请-支持线上提交与进度查询 | 业务域：售后；父级：BR-售后-0001；负责人：产品经理 | 初稿写作“退货页面改版”，被指出把方案写进标题 | 改为描述产品能力，方案细节移入描述字段 |
| 子需求 | [SUB] 退货申请-表单校验-必填项拦截提示 | 业务域：售后；父级：SR-订单服务-0003；负责人：研发 | 初稿父级挂到了产品需求，跨级挂接被校验拦截 | 改挂系统需求，父子层级一致 |
评审中出现的典型问题集中在三类：标题写成实现方案、父级跨级挂接、动作词不统一（“支持”“实现”“完成”混用）。修正方式分别是把方案移入描述、按层级表重新挂接、在术语对照中固定每层的动作词。这组示例可迁移的规律是：先确认层级和父级，再写标题；标题只写对象和结果；字段空缺在提交前补齐，不带到评审会上。
完成检查：规范可用性的验收清单
规范制定完成后，用下面的清单逐项核对。全部通过即可发布；存在未通过项时，先补齐再进入日常使用。
- 层级定义表覆盖四层，每层有判定问题、责任角色、典型粒度和父子约束，且四层之间没有重叠认领。
- 四层命名模板齐全，每层至少有一个合规示例和一个不合规示例，示例覆盖不同业务域。
- 字段表列出全部字段的必填性、格式、填写人和校验方式，必填项能对应到层级归属或追溯需要。
- 编号规则写明唯一性由谁保证，标题修改后编号保持不变。
- 校验规则可执行：唯一性、父子一致性、同层重名检测都有明确执行环节。
- 起草人、评审组、维护人三个角色已指定到人，评审通过标准和分歧处理方式已写入规范。
- 规范发布位置与需求创建入口相邻，新成员培训包含一次真实需求填写演示。
- 试填记录保留，至少3条需求完成从填写到评审修正的完整过程。
规范进入使用后，出现以下情况时触发复审：业务域清单新增超过约定数量、同一类命名问题在评审中重复出现三次以上、团队调整需求层级或引入新的需求类型、工具中的字段配置发生变更。复审由维护人发起，改动范围限于受影响的部分，并在变更记录中说明原因和生效时间。
常见问题
团队规模较小，四层需求都要用吗？
层级数量按实际管理需要确定，不必机械套用四层。判断标准是：每一层是否有独立的判定问题和责任角色，以及是否有人真正在该层做决策。小团队可以先用业务需求、产品需求、子需求三层，把系统需求的内容并入产品需求的描述字段；当系统改造增多、需要研发单独承接时再拆出系统需求层。
无论用几层，命名模板、字段表和校验口径都要随层级同步调整，避免模板里出现已停用的层级前缀。
存量需求的标题不符合新模板，需要全部改吗？
不需要一次性全量改写。建议按状态分批处理：处于草稿和评审中的需求在提交前按新模板修正；已确认并进入开发的需求保留原编号，在下次变更时顺带调整标题；已关闭的需求不做追溯修改，仅在关联引用时说明。
分批处理期间，规范维护人记录高频不符合项，作为术语对照和模板说明的补充材料。存量改写的工作量应纳入规范落地计划，避免只发布不执行。
标题长度限制在20至40个汉字，遇到复杂需求写不下怎么办？
标题写不下通常说明这条需求承载了多个对象或多个结果，可以先检查是否需要拆成两条需求，或下沉到子需求层。标题只保留最核心的对象和结果，范围限定、实现方式、验收细节放入描述和验收说明字段。
如果确实需要在标题中体现范围，优先压缩业务域和对象段的用词，统一使用术语对照中的简称，而不是放宽长度限制。长度上限一旦放开，同层重名检测和列表展示都会受影响。
父子层级一致性校验会不会阻碍需求调整？
校验的目的是防止跨级挂接，不限制正常的层级调整。当需求内容变化导致层级归属改变时，按变更流程处理：先由负责人提出层级调整，维护人或产品负责人确认新的父级，再修改层级字段和父级引用，变更记录中保留原层级和调整理由。
紧急情况下可以先调整后补记录，但需在一个工作日内完成补齐，由维护人抽查。校验规则本身不拦截合规的层级变更，只拦截父级层级与当前层级不匹配的挂接。
规范发布后如何判断它真的在被使用？
可以观察几个可检查的信号：需求提交时因命名或字段不全被退回的比例、评审会上临时纠正命名问题的次数、同一父级下出现相似标题的情况、业务域枚举被自行扩展的次数。这些信号持续下降，说明规范进入了日常流程。
如果退回比例长期为零而评审会上命名问题频发，通常说明检查动作没有真正执行，需要回到提交环节核对检查项是否被跳过。维护人可按季度汇总这些信号，作为复审依据。
