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