当开发人员做了一个已经被取消的功能,你能想想他有多沮丧;当测试人员按照老的测试案例去测试新的需求规格的开发结果时,他可能要抓狂。出现了这些情况,都是因为需求的版本控制出现了问题。
说到需求的版本管理,是不是就是需求文档放到配置库就可以了呢?答案是——不仅仅如此。因为需求有它的特殊性,有它分析和管理的特殊要求,所以在实际的工作中的需求版本我们考虑更多层次:
- 需求文档的版本
对整个文档进行版本的管理是最基础的。当谈及最新版本时,项目团队的成员“应该”都知道它指的是哪个版本的文档,比如说2.1版。应该上面加引号是有用意的,因为实际的情况是每个人往往都是指向自己的机器上的文档版本,以为是最新版本。
- 需求条目的版本
需求条目的版本是什么意思呢?需求条目的版本表示了对每个需求对象进行更细粒度的控制。需求文档里面有若干条需求组成,两个需求我嫩大版本之间可能是几个需求项发生了变化,有时候我们需要更清楚的知道某条关键的需求,何人何时创建,何人何时做出何种修改,并且能够知道修改的开始和结束的状态,并且显示出其中的差异,最好能可以自动的回退到某个历史状态。这些工作中的需求,实际上都体现了对需求条目层次上版本管理的要求。
- 需求体系的版本