制定需求层级命名规范，核心是先定层级结构，再定每层的命名格式与必填字段，最后用评审和示例库把规则固定下来。层级数量、各层职责边界和命名模板三者需要一起设计，否则规范容易停留在文档里、难以执行。本文按层级划分、模板设计、制定步骤、角色分工、完整示例和验收清单展开，适用于正在梳理需求池、准备统一需求命名口径的产品与研发团队。
要点总览（TL;DR）
- 先定层级再定命名：明确业务需求、用户需求、系统需求各层的职责边界与上下级关系，命名规则才有稳定的挂靠对象。
- 命名模板按“前缀+层级标识+编号+主题+限定词”设计，同时规定必填字段、标题长度、禁用词与编号复用规则。
- 制定流程分六步：收集样本归类、起草规则、样本试填、评审定稿、发布宣贯、纳入准入检查与定期复审。
- 规范发布前用验收清单核对层级完整性、模板覆盖率、试填合格率与维护责任人，通过后再宣贯执行。
先定层级：需求层级怎么划分才支撑命名
命名规范的对象是“层级”，层级没定清楚，命名规则就缺少稳定的挂靠点。划分层级时先回答三个问题：团队从哪一层开始接收需求、哪一层开始进入研发排期、哪一层对应可独立验收的交付物。答案确定后，层级数量和职责边界随之清晰。
常见做法是三层：业务需求描述业务目标与价值，用户需求描述特定角色在场景中的诉求，系统需求或子需求描述可开发、可测试的功能点。层级再往下通常进入任务拆解范畴，不再作为需求命名规范覆盖的对象。层级过浅会导致一条需求承载过多内容、命名被迫塞进多个主题；层级过深则让编号冗长、维护成本上升。判断标准可以看两点：每层是否有独立的评审责任人，每层是否对应不同的交付节奏。
层级编码与层级名称要一一对应，建议用固定字母前缀标识层级，例如业务需求用 BR、用户需求用 UR、系统需求用 SR，编码只表示层级归属，不承担排序含义。下表可作为层级定义表的起点，团队按实际情况增删。
| 层级名称 | 职责 | 典型示例 | 上下级关系 |
|---|---|---|---|
| 业务需求（BR） | 描述业务目标、价值与范围 | 缩短新客户开户时长 | 向下分解为用户需求 |
| 用户需求（UR） | 描述特定角色在场景中的诉求 | 客户经理可在线预填开户资料 | 上承业务需求，下分解为系统需求 |
| 系统需求（SR） | 描述可开发、可测试的功能点 | 开户表单支持资料暂存与续填 | 上承用户需求，向下关联研发与测试任务 |
层级与分解粒度的关系需要在规范中写明：一条上级需求分解出的下级需求数量不设硬性上限，但每条下级需求应能独立评审、独立验收。若一条系统需求无法单独验收，说明粒度仍偏粗，应继续拆分或回到用户需求层重新界定。
命名模板设计：每层需求的命名格式与字段
命名模板的作用是让同一层级的需求在标题上就能被识别、检索和排序。推荐结构为“前缀+层级标识+编号+主题+限定词”，其中前缀与层级标识合并书写，编号按层级独立递增，主题用动宾短语概括核心动作与对象，限定词补充场景、渠道或版本等区分信息。
| 层级 | 命名模板 | 示例 |
|---|---|---|
| 业务需求 | BR-编号 主题（业务目标） | BR-012 缩短新客户开户时长 |
| 用户需求 | UR-编号 主题（角色+场景） | UR-045 客户经理在线预填开户资料 |
| 系统需求 | SR-编号 主题（功能点+限定词） | SR-108 开户表单资料暂存与续填（移动端） |
字段规则需要同时规定必填与选填。标题中的前缀、层级标识、编号、主题为必填；限定词按需填写，但同一层级内使用口径要统一，例如渠道类限定词统一放在末尾括号内。标题之外，需求条目还应设置业务价值、目标角色、验收标准、优先级、来源等字段，其中业务价值、验收标准、优先级建议设为必填，来源与关联文档可设为选填。
字符与用词规则直接影响可读性：标题长度建议控制在30个汉字以内，超出时优先精简主题而非堆叠限定词；统一使用中文全角标点，编号与主题之间用空格分隔；禁用“优化一下”“相关功能”“其他”等无法指向具体对象的词，避免“系统”“平台”单独作为主题；同层级内不得出现仅编号不同的重名标题。编号规则按层级独立连续编号，作废需求保留编号并标记状态，不复用编号；新增需求取当前最大编号加一，跨层级引用时写全前缀，例如“见 SR-108”。
制定流程：从草案到发布的六个步骤
规范制定本身是一个小项目，按六个步骤推进可以让规则在发布前就经过真实数据检验。每步都明确输入、动作、输出和完成标志，避免讨论停留在原则层面。
- 收集现有需求样本并归类。输入为近三到六个月的需求清单与工单记录；动作为按业务、用户、系统三个视角归类，标记无法归类的条目；输出为样本归类表；完成标志是样本覆盖主要需求来源，且无法归类的条目已记录原因。
- 起草层级与命名规则。输入为样本归类表与本文的层级定义表；动作为确定层级数量、各层职责、命名模板与字段清单；输出为规范草案；完成标志是草案覆盖全部层级，且每条规则都有对应示例。
- 选取样本试填并修正。输入为规范草案与不少于20条真实需求；动作为由不同角色按模板试填，统计一次填写合格率；输出为试填记录与问题清单；完成标志是合格率达到团队约定阈值，典型歧义已有明确处理规则。
- 组织评审与定稿。输入为草案、试填记录与问题清单；动作为产品、研发、测试共同评审层级边界与字段必要性，逐条关闭争议；输出为定稿版本与评审记录；完成标志是各方对层级定义和命名模板无遗留异议。
- 发布与宣贯。输入为定稿规范；动作为发布文档、组织一次集中讲解、建立示例库；输出为规范文档、示例库与宣贯记录；完成标志是新进需求开始按新规则命名。
- 纳入需求准入检查与定期复审。输入为规范与需求池；动作为在需求评审或入库环节检查命名与字段完整性，按季度复审规则适用性；输出为检查记录与复审结论；完成标志是准入检查有明确执行人，复审周期与维护责任人已写入规范。
角色与交付物：谁定规则、谁执行、谁把关
规范能否执行，取决于职责是否落到具体角色。需求管理负责人或产品负责人通常承担规则制定与维护，研发与测试在评审中校验可开发性与可测试性，评审与准入检查由固定角色把关，避免规则只写在文档里。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 需求管理负责人/产品负责人 | 起草层级定义与命名模板，维护示例库，组织复审 | 规范文档、示例库、复审记录 | 草案完成后提交评审，复审后更新版本 |
| 研发负责人 | 校验系统需求粒度的可开发性，反馈命名歧义 | 评审意见、粒度调整建议 | 评审会前提交意见，评审会上确认 |
| 测试负责人 | 校验系统需求是否可独立验收，补充验收标准字段要求 | 验收标准检查意见 | 评审阶段与需求入库前 |
| 评审与准入检查角色 | 在需求评审或入库环节检查命名与必填字段 | 准入检查记录、退回修改清单 | 每次需求评审与入库时 |
交接时点需要写进流程：产品负责人完成草案后交评审，研发与测试在评审前给出书面意见，准入检查角色在需求进入排期前完成检查。规则变更同样走这条路径，由需求管理负责人发起，经评审后更新示例库，避免新旧规则并行造成混乱。
规范落地需要工作项字段与评审流程承载。ONES 提供业务需求池、产品需求池与工单系统，可将业务反馈与产品开发联动起来；对于功能复杂的需求，可用子工作项进行拆解并关联研发和测试任务；团队也可根据实际场景自定义工作流，让需求按规范流转。命名与字段的强制校验方式需在实施时结合具体配置确认。
示例：一条需求从命名到入库的完整示范
假设某团队收到反馈：客户经理在移动端为客户开户时，资料填写常被中断，需要重新录入。按规范，这条反馈先归入业务需求层，再逐层分解。
业务需求命名为“BR-012 缩短新客户开户时长”，主题为动宾结构，指向业务目标。分解出的用户需求为“UR-045 客户经理在线预填开户资料”，主题包含角色与场景。继续分解的系统需求为“SR-108 开户表单资料暂存与续填（移动端）”，限定词标明渠道。字段填写上，业务价值写“减少重复录入导致的客户等待”，验收标准写“中断后再次进入可恢复已填内容”，优先级按业务方评估填写，来源关联原始工单编号。
| 常见错误写法 | 问题 | 按规范修正 |
|---|---|---|
| 优化开户流程 | 主题空泛，无法判断层级与对象 | BR-012 缩短新客户开户时长 |
| SR-108 表单 | 缺少动作与限定词，无法验收 | SR-108 开户表单资料暂存与续填（移动端） |
| UR-045 客户经理预填资料相关功能 | 含禁用词“相关功能” | UR-045 客户经理在线预填开户资料 |
评审时，测试角色针对 SR-108 提出补充“断网场景下暂存是否保留”的验收条件，命名本身不变，验收标准字段更新。后续若需求范围扩大到网页端，处理方式是新增一条系统需求并写明渠道限定词，原需求保留编号与状态，避免在标题上叠加多个渠道导致含义模糊。
完成检查：规范可用的验收清单
规范发布前，用以下清单逐项核对，全部通过再进入宣贯与执行阶段。
- 层级定义完整：每个层级都有职责说明、典型示例和上下级关系，层级之间无职责重叠。
- 命名模板覆盖全部层级：每层都有可套用的模板和至少两个示例，前缀与编号规则无冲突。
- 字段规则明确：必填与选填字段已列出，长度、字符集、禁用词和重名处理规则可查。
- 样本试填通过：不少于20条真实需求完成试填，一次合格率达到团队约定阈值，歧义条目已有处理结论。
- 评审与准入机制落地：评审角色、准入检查角色和执行时点已写入流程，检查记录有存放位置。
- 维护机制明确：复审周期、维护责任人和规则变更路径已确定，示例库有更新责任人。
清单通过后，规范即可发布执行；后续每次复审重点检查新增需求中不符合命名的比例，比例上升说明规则需要调整或宣贯需要加强。
常见问题
团队需求数量少，是否也需要完整的三层结构和编号规则？
需求数量少时，可以先把层级压缩到两层，例如只保留用户需求与系统需求，业务目标写在用户需求的业务价值字段里。编号规则仍建议保留，因为编号是后续引用和检索的锚点，取消编号会让跨需求引用只能靠标题描述。等需求池增长、出现跨角色协作时，再补上业务需求层并迁移已有条目，迁移时保留原编号并标注层级变更记录。
已有大量历史需求命名混乱，规范发布后要一次性全部改名吗？
不建议一次性全量改名。更稳妥的做法是设定一个时间切点：切点之后新进需求按新规范命名，切点之前的历史需求在下次被引用、变更或重新评审时顺带修正。这样既控制了一次性改名的成本，也避免新旧规则长期并行。对于仍在活跃迭代的历史需求，可以优先修正，因为它们被检索和引用的频率更高。
命名规范里的字段要求，如何在需求评审时真正被检查？
关键是把检查动作嵌入已有的评审环节，而不是另设一道流程。可以在需求进入排期前的评审会上，由固定角色对照必填字段清单逐项确认，缺项直接退回补充。检查记录需要有存放位置，便于复审时统计不符合比例。若团队使用 ONES，可借助工单收集反馈并转化为需求、整理产品 Backlog，并通过自定义工作流承载需求流转；字段强制校验的具体配置方式需在实施时结合实际情况确认。
限定词应该放在标题里还是放到独立字段？
判断依据是这个信息是否影响需求本身的识别。渠道、端类型这类会改变验收范围的限定词，建议放在标题末尾括号内，让同一主题在不同渠道下的需求能被区分；版本号、计划批次这类随排期变化的信息，更适合放在独立字段，避免标题随计划调整反复修改。无论选择哪种方式，同一层级内的口径要统一，并在规范中写明示例。
规范执行一段时间后不符合命名的需求变多，应该怎么处理？
先区分原因再决定动作。如果是不符合比例集中在某一层级，通常说明该层模板与实际工作不匹配，需要调整模板；如果是新成员提交的条目居多，说明宣贯和示例库覆盖不足，应补充培训与示例。复审时可以统计新增需求中不符合命名的比例，比例上升即触发规则调整或宣贯加强，并把结论写入复审记录，作为下一版规范的修订依据。
