3、需求标识与编号：唯一标识符设计、编号规则、版本控制基础

好，咱们今天聊聊需求追踪里最基础、但也最容易翻车的一个环节——需求标识与编号。

你可能觉得，不就是给每个需求起个名字、编个号嘛，有什么难的？

嗯，我当年也是这么想的。直到有一次，我在一个车载项目里，面对一份3000多条的需求文档，发现里面居然有十几个“REQ-001”……那场面，简直是灾难。从那以后，我对编号规则这件事，就再也不敢马虎了。

3.1 唯一标识符设计：给每个需求一个“身份证”

说白了，唯一标识符就是需求的“身份证号”。它必须保证在整个项目生命周期里，一个ID只对应一个需求，哪怕这个需求后来被删了，这个ID也不能再给别人用。

我个人习惯用“前缀 + 序号”的结构。前缀用来区分需求来源或类型，序号保证唯一性。

举个例子：

REQ-SYS-00123
│    │    └── 序号（5位，自动递增）
│    └── 子系统缩写（SYS=系统级，UI=用户界面，CTRL=控制）
└── 固定前缀（REQ=需求）

这里有几个设计要点，我踩过的坑都列出来了：

• 前缀要有意义：别用A、B、C这种无意义的字母。我见过有人用“R1”、“R2”来区分版本，结果三个月后自己都分不清了。
• 序号要固定长度：比如都用5位数字，从00001开始。这样排序时不会乱。我曾经用自然数编号，结果“REQ-10”排在了“REQ-9”前面，被客户当场指出……
• 避免使用特殊字符：下划线、斜杠、空格，这些在工具链里容易出问题。我建议只用字母和数字。

3.2 编号规则：让编号自己会“说话”

编号规则，就是一套大家都得遵守的“命名法”。好的规则，能让团队成员看到编号就大概知道这个需求属于哪个模块、什么类型、什么优先级。

我常用的规则是“三段式”：

段位	含义	示例
第一段	项目/产品代号	PJ-A（项目A）
第二段	需求类型	FUNC（功能）、PERF（性能）、SAFE（安全）
第三段	层级+序号	L2-00123（第2层，序号123）

完整的编号看起来像这样：

PJ-A-FUNC-L2-00123

你想想看，拿到这个编号，你就能知道：这是项目A的一个功能需求，属于第二层分解，序号是123。是不是清晰多了？

这里有个避坑指南：层级不要超过3层。我见过有人搞到L5、L6，结果编号比需求内容还长，维护起来简直要命。

3.3 版本控制基础：需求也是会“长大”的

需求不是写出来就完事了。它会变，会细化，甚至会消失。所以，版本控制是必须的。

嗯，这里要注意：版本控制不是简单的“另存为”。我见过有人把需求文档命名为“需求_V1”、“需求_V2”、“需求_最终版”、“需求_最终版2”……最后自己都搞不清哪个是最新的。

我建议用“主版本号.次版本号.修订号”的格式：

• 主版本号：需求基线发生重大变更时增加（比如从V1.0.0到V2.0.0）
• 次版本号：新增或修改需求时增加（比如从V1.0.0到V1.1.0）
• 修订号：修正文字错误、格式调整时增加（比如从V1.0.0到V1.0.1）

举个例子：

REQ-SYS-00123  V1.0.0  →  初始创建
REQ-SYS-00123  V1.1.0  →  增加了响应时间要求
REQ-SYS-00123  V2.0.0  →  需求被重新分解，范围变化

3.4 实践建议：从第一天就建立规矩

我个人经验是，编号规则和版本控制，最好在项目启动的第一天就定下来。哪怕你觉得项目小、需求少，也别偷懒。因为需求一多起来，再回头补编号，那工作量是几何级增长的。

这里给你几个可操作的建议：

1. 用工具自动生成编号：别手动输入。Excel、Jira、Doors这些工具都能自动递增序号，减少人为错误。
2. 建立编号规则文档：写清楚规则，放在项目共享目录里，让所有人都能查到。
3. 定期审计：每个月花半小时，抽查一些编号，看看有没有重复、有没有遗漏。
4. 版本变更要有记录：每次修改需求，都要在变更日志里写明：谁、什么时候、改了哪里、为什么改。

说白了，需求标识和编号这件事，看起来是“体力活”，但它是整个需求追踪体系的基石。基石不稳，后面的一切追溯、验证、测试，都会跟着出问题。

好，这一节就到这里。下一节咱们聊聊需求属性管理——怎么给需求打标签、设优先级、关联风险。这些东西，在实际项目中特别实用。