当开发人员做了一个已经被取消的功能，你能想想他有多沮丧；当测试人员按照老的测试案例去测试新的需求规格的开发结果时，他可能要抓狂。出现了这些情况，都是因为需求的版本控制出现了问题。
说到需求的版本管理，是不是就是需求文档放到配置库就可以了呢？答案是——不仅仅如此。因为需求有它的特殊性，有它分析和管理的特殊要求，所以在实际的工作中的需求版本我们考虑更多层次：
需求文档的版本
对整个文档进行版本的管理是最基础的。当谈及最新版本时，项目团队的成员“应该”都知道它指的是哪个版本的文档，比如说2.1版。应该上面加引号是有用意的，因为实际的情况是每个人往往都是指向自己的机器上的文档版本，以为是最新版本。
需求条目的版本
需求条目的版本是什么意思呢？需求条目的版本表示了对每个需求对象进行更细粒度的控制。需求文档里面有若干条需求组成，两个需求我嫩大版本之间可能是几个需求项发生了变化，有时候我们需要更清楚的知道某条关键的需求，何人何时创建，何人何时做出何种修改，并且能够知道修改的开始和结束的状态，并且显示出其中的差异，最好能可以自动的回退到某个历史状态。这些工作中的需求，实际上都体现了对需求条目层次上版本管理的要求。
需求体系的版本
今天，越来越多的公司采用迭代或增量开发模式。为了降低风险，将开发过程分为多个增量部分可以加快整个开发过程。那每个阶段结束后，是不是要将整个项目的文档做一个快照呢？通常是需要的，那此时的项目基线也就是我们这里说的需求体系的版本。需求体系的版本包含自需求而来的多个相关文档，此时的版本管理不仅应将这些文档打上统一的基线，并且将该组文档之间的追踪关系也进行基线化的管理。
对文档之间的追踪关系也进行基线化的管理意味着什么呢？项目的每一个阶段，需求文档会有不同，那需求文档之间追踪关系也会有不同。那当我们记录下项目每个阶段的需求文档及其追踪关系的版本后，在日后的工作中，我们可以回溯到以前的某个需求版本，并能够按照当时的项目追踪关系，追踪分析当时的分析设计结果，实现对整个需求体系的掌握，能够更好的理解，利用以至复用已完成的工作成果。
