需求层级命名规范示例通常按“主题—特性—需求项—验收条件”四层展开，每层名称同时交代层级身份、业务对象和范围边界。本文给出一套可直接对照填写的演示样例，逐段解释编号、前缀、限定语的作用，并说明换到其他业务域时如何替换成分、哪些情况需要调整层级深度。示例为演示情景，不涉及真实客户数据。
要点总览（TL;DR）
- 需求层级命名规范示例按“主题—特性—需求项—验收条件”四层组织，每层名称同时交代层级身份、业务对象和范围边界。
- 编号采用“层级前缀+业务域码+流水号”，前缀固定标识层级，业务域码区分领域，流水号保证唯一，名称修改时编号保持稳定。
- 业务对象用名词短语，需求项动词限定在具体操作，验收条件写成含触发条件、操作和预期结果的可判定表述，限定语放在名称末尾收口范围。
- 迁移到其他业务域时按前缀、业务域码、限定语三类成分分别替换，先选十条已有需求试填再推广。
- 层级过浅或过深、多团队共用规范、业务域新增等情况下需要调整样例，并配合评审与定期维护动作。
示例目标：这套命名样例要解决什么问题
这套样例面向正在建立需求池、准备把零散需求整理成层级结构的团队，适用于产品经理、业务分析师和研发负责人共同维护需求清单的场景。样例以“企业采购系统”为演示背景，所有名称、编号、负责人均为虚构，用于展示填写方式，不代表任何真实项目。
命名规范要解决的第一类问题是层级混淆。团队把主题、特性、需求项混在同一列表里时，读者无法从名称判断某条记录属于哪一层，评审时容易把特性当成需求项讨论。第二类问题是同名歧义。“审批流程优化”这样的名称可能同时出现在采购、报销、合同三个业务域，缺少限定语时无法区分对象。第三类问题是跨层追溯困难。名称中不带层级标识和业务对象，从需求项回溯到所属特性、再回溯到主题时只能依赖人工记忆。
本示例覆盖从主题到验收条件的四层命名，包括编号规则、名称结构、上级字段和状态字段的填写方式。任务拆解与组织、跨研发对象的追溯与覆盖管理属于其他主题，本文只在边界处提示，不展开具体做法。样例要达成的可观察结果是：同一需求在需求列表、看板卡片和追溯关系中显示的名称完全一致，任何人看到名称即可判断层级和所属业务范围。
完整示例：四层需求层级命名样例
四层结构自上而下为：主题（Theme）表示一段时间的业务方向，特性（Feature）表示可独立交付的能力集合，需求项（Story）表示可在一个迭代内完成的功能单元，验收条件（AC）表示需求项完成时可判定的结果。编号采用“层级前缀+两位业务域码+三位流水号”，名称采用“业务对象名词短语+限定语”的结构。
| 层级 | 编号 | 名称 | 上级 | 负责人 | 状态 |
|---|---|---|---|---|---|
| 主题 | TH-PR-001 | 采购申请线上化 | — | 产品负责人A | 进行中 |
| 特性 | FT-PR-001 | 采购申请单创建与提交 | TH-PR-001 | 产品经理B | 进行中 |
| 需求项 | ST-PR-001 | 采购申请单草稿保存（含明细行） | FT-PR-001 | 产品经理B | 待开发 |
| 验收条件 | AC-PR-001 | 草稿保存后重新打开，明细行数量与金额与保存前一致 | ST-PR-001 | 测试负责人C | 待验证 |
| 需求项 | ST-PR-002 | 采购申请单提交校验（必填项与预算上限） | FT-PR-001 | 产品经理B | 待开发 |
| 验收条件 | AC-PR-002 | 必填项为空或金额超过预算上限时，提交按钮不可用并提示具体字段 | ST-PR-002 | 测试负责人C | 待验证 |
| 特性 | FT-PR-002 | 采购申请审批流转 | TH-PR-001 | 产品经理D | 规划中 |
| 需求项 | ST-PR-003 | 采购申请单按金额区间自动选择审批人 | FT-PR-002 | 产品经理D | 规划中 |
填写时，上级字段只填编号，不重复填写名称，避免名称修改后上级信息不同步。状态字段按团队工作流取值，示例中的“待开发、待验证、规划中”仅示意。同一需求项在需求列表、看板卡片和追溯关系中均使用“ST-PR-001 采购申请单草稿保存（含明细行）”这一完整标识，列表可只显示名称，但编号始终保留在名称前或独立列中，保证复制到其他位置时不丢失层级信息。
逐项解释：每个命名片段为什么这样写
编号前缀固定为TH、FT、ST、AC，作用是在任何列表、导出文件或聊天记录中一眼识别层级。前缀后接两位业务域码（示例中PR代表采购），再接三位流水号。业务域码让不同业务域的需求共用一套编号体系而不冲突，流水号保证同一层级内唯一。前缀和编号不随名称修改而变化，名称可以迭代，编号保持稳定，追溯关系才不会断。
业务对象使用名词短语，例如“采购申请单”“审批流转”，让读者知道这条需求作用于什么对象。需求项名称中出现的动词限定在“保存、提交、选择”这类具体操作上，避免使用“优化、完善、提升”这类无法判断完成状态的词。验收条件写成可判定表述，包含触发条件、操作和预期结果三要素，例如“必填项为空或金额超过预算上限时，提交按钮不可用并提示具体字段”，测试人员据此可以直接设计用例。
限定语放在名称末尾的括号或介词短语中，用于收口范围。“（含明细行）”说明草稿保存覆盖明细行数据，“（必填项与预算上限）”说明提交校验的范围。限定语回答“这条需求管到哪为止”，减少同名歧义。上级字段与命名配合的方式是：名称本身不重复上级信息，上级关系由上级字段承载，两者结合才能从需求项一路回溯到主题。
| 命名成分 | 示例写法 | 作用 | 常见错误写法 |
|---|---|---|---|
| 层级前缀 | ST-PR-001 | 标识层级与业务域，保证唯一 | 直接写“需求1”，无层级信息 |
| 业务对象 | 采购申请单草稿保存 | 说明作用于什么对象、做什么操作 | “优化采购功能”，对象和动作都不具体 |
| 限定语 | （含明细行） | 收口范围，区分同名需求 | 名称后无任何范围说明 |
| 验收条件表述 | 提交按钮不可用并提示具体字段 | 可判定，能直接设计测试用例 | “提交体验良好”，无法判定 |
| 上级字段 | FT-PR-001 | 承载层级关系，支撑追溯 | 在名称里手写上級名称，易不同步 |
可迁移规律：换到其他业务域怎么套用
层级数量与命名结构存在对应关系：每增加一层，就增加一个层级前缀，名称结构保持“对象+限定语”不变。四层结构适合需求需要区分方向、能力、功能单元和验收结果的团队；如果团队只管理到功能单元，可以去掉验收条件层，把验收条件写入需求项的描述字段，编号体系相应减少一个前缀。
迁移时按三类成分分别替换。前缀替换为团队约定的层级缩写，保持全组织统一；业务域码替换为目标领域的缩写，例如客服域用CS、财务域用FN；限定语替换为该业务域中真正会造成歧义的范围词，例如渠道、角色、数据范围。替换后先选十条已有需求试填，检查名称是否能在不看上级字段的情况下判断层级，再批量推广。
规范落地需要两个动作配合。评审动作：需求进入评审前，由需求负责人检查名称是否包含层级前缀、业务对象和限定语，不符合的退回修改。维护动作：每季度抽查一次名称与上级字段的一致性，发现名称修改后编号未同步、或限定语已失效的记录及时修正。在工具层面，ONES 支持利用子工作项对功能复杂的需求进行拆解，并关联研发和测试任务；团队可以把主题、特性、需求项、验收条件映射到相应的工作项层级，用编号和名称字段承载上述规范，使列表、看板和追溯关系引用同一对象。具体层级数量上限和字段配置方式需按团队实际使用的工具版本核验。
适用边界：哪些情况需要调整这套样例
层级深度较浅时，例如只有主题和需求项两层，应去掉特性层的前缀，把特性信息并入主题名称的限定语，避免出现大量只有一个子项的中间层。层级更深时，例如需要在需求项下再分场景，可以增加场景层前缀，但每增加一层都要确认该层有独立的负责人和状态，否则层级只增加管理成本。
需求与任务拆解的边界需要分清：需求项描述“做什么、做到什么程度”，任务描述“谁在什么时间完成哪一步”。本样例的名称结构适用于需求侧，任务名称可以沿用编号前缀思路，但任务拆解与组织属于其他主题，不在本文展开。跨研发对象的需求追溯与覆盖管理同样归其他主题，本文只说明名称一致性对追溯的支撑作用。
多团队共用命名规范时，冲突通常出现在业务域码和限定语上。处理方式是建立一份共享的业务域码表，新增域码需登记；限定语按“范围词+取值”的格式书写，例如“（渠道：线上）”，减少各团队自造缩写。规范需要维护的触发条件包括：新增业务域、组织调整导致负责人变化、需求层级增减、评审中连续出现同类命名错误。出现任一情况时，更新规范文档并通知相关团队，避免规范与实际填写脱节。
常见问题
团队只有两层需求层级，这套四层样例还能用吗？
可以按比例缩减。去掉特性层后，把原本写在特性名称里的能力范围并入主题名称的限定语，编号体系相应减少一个前缀。保留主题和需求项两层时，需求项名称仍按“业务对象+限定语”书写，验收条件写入需求项的描述字段。缩减的前提是确认被去掉的层没有独立的负责人和状态，否则合并后会出现责任不清。
名称修改后编号要不要跟着改？
编号保持稳定，名称可以迭代。编号承载的是层级身份和唯一性，一旦被追溯关系、测试用例或聊天记录引用，改动编号会让这些引用失效。名称修改时同步检查上级字段是否仍指向正确的记录，限定语是否仍然准确描述当前范围。若业务对象本身发生变化，例如需求从采购申请单改为采购订单，更适合新建一条需求并关闭原需求，保留历史可追溯。
多个团队共用一套命名规范，业务域码冲突怎么处理？
建立一份共享的业务域码表，新增域码需要登记并由规范维护人确认，避免两个团队各自使用同一缩写。限定语按“范围词+取值”的格式书写，例如“（渠道：线上）”，减少各团队自造缩写造成的歧义。规范文档放在团队都能访问的位置，评审时以文档为准，发现未登记的域码先补登记再使用。
命名规范在工具里怎么落地，需要人工逐条检查吗？
落地方式取决于团队使用的工具。ONES 支持利用子工作项对功能复杂的需求进行拆解，并关联研发和测试任务，团队可以把主题、特性、需求项、验收条件映射到相应的工作项层级，用编号和名称字段承载命名规范，使列表、看板和追溯关系引用同一对象。名称是否符合规范仍需在评审环节由需求负责人检查，工具层面是否提供命名校验能力需按实际使用的版本核验。
规范执行一段时间后，什么情况下需要修订？
常见触发条件包括新增业务域、组织调整导致负责人变化、需求层级增减，以及评审中连续出现同类命名错误。出现任一情况时更新规范文档并通知相关团队。日常维护可以按季度抽查名称与上级字段的一致性，重点看名称修改后编号是否稳定、限定语是否已经失效。
