需求评审结束之后，如果还是允许所有人随时去改动的话，后面就很难说得清楚哪些内容是已经确认好的，哪些又是后来新增或者调整过的。要把ALM Soft里面的需求基线管理好，以及基线变更的时候怎么留下可靠的痕迹，关键的一点，就是把“单条需求的版本记录”和“某个阶段的整体快照”这两种东西分开来处理。不同ALM平台的菜单名称会有些差别，下面就以OpenText ALM里常见的操作逻辑来举例。OpenText ALM的Requirements模块可以持续去管理和跟踪需求，基线的作用则是保存某一个时间点上的项目内容。

　　一、ALM Soft需求基线怎么管理

　　需求基线适合在评审通过、版本冻结、测试启动和发布确认这样的节点上面去建立，而不是每改完一条需求就去建一次基线。如果基线数量太多，后面再想去做对比反而会变得很不方便。

　　1、先把需求的目录整理好

　　进入【Requirements】之后，我们可以按照系统、模块或者版本来把需求树建好。每一条需求都得把编号、名称、当前状态、负责人、优先级和目标版本这些信息给补齐，如果目录本身是乱的，就算把基线建出来，后面核对的时候也会非常吃力。

　　2、接着创建对应的需求库

　　进入【Libraries】这个功能，新建一个Library，然后在内容选择界面上，把需要纳入到这次基线里的需求目录，或者某几条具体的需求给勾上。OpenText ALM不仅能支持把需求放进去，还可以把测试、资源这些内容一块儿放进Library，而且在需求页面上也可以按单条需求去单独挑选。

　　3、然后去生成阶段性的基线

　　选中建好的Library，再去创建Baseline，起名字的时候最好能把版本和节点都写清楚，比如“V1.2需求评审通过”或者“V1.2测试启动”这样的。基线的创建过程会在后台自己跑，等到跑完了可以查看日志，确认一下有没有什么内容被漏掉，或者处理的时候有没有出错。

　　4、基线建成之后就不要再覆盖了

　　基线本质上就是某一个时点的快照，主要用来把当时确认过的那些内容给保留下来。后面需求要是再有什么变化，应该去建立新的版本或者新的基线，不要直接把旧基线当成一份可以随时编辑的文档来用。

　　二、ALM Soft需求基线变更怎么留痕

　　在需求变更这件事情上，留痕绝对不能只是简单地在备注里写上“已修改”。真正有用的记录，是能让人看出来到底谁改了什么东西、为什么要改，以及这次变更影响了哪些测试和交付的内容。

　　1、先把版本控制功能给启用起来

　　在支持版本控制的项目里，去修改某条需求之前，先要执行一次【Check Out】把它签出来，等编辑完了再执行【Check In】把它签回去，并且要把变更说明给填上。OpenText ALM的版本控制会把每个实体各自的历史版本都保留住，很适合去查看某一个字段具体是怎么改的，或者需要回退到旧版本的时候也会很方便。

　　2、同步去建立变更单并关联起来

　　需求一旦发生变更，最好同步建一张变更单，在里面写清楚变更的原因、申请人是谁、影响了哪些模块、优先级怎么样、评审的结论是什么，还有计划在哪个版本里去做。需求正文里管的是“改成了什么样子”，而变更单这一边，要解决的是“为什么非得这样改”。

　　3、拿来跟之前的基线做一做差异对比

　　进到Library以后，可以选择两条不同的Baseline来做比较，也可以拿某一条Baseline去跟当前的内容比较。OpenText ALM支持按模块去看哪些内容是新增的、哪些被删掉了、哪些又做了修改，并且能把对比的结果导出成CSV格式的文件来用。

　　4、把需求和测试之间的追踪关系也保留住

　　一条基线保存下来的，可不单单是需求本身，它还会把需求和测试之间的那些追踪、覆盖关系也一起留下来。OpenText ALM的文档里也特别强调，针对单个实体的版本控制，是存不住这些关系数据的，只有基线才适合用来做这种阶段性的完整留档。

　　三、ALM Soft需求变更后怎么复核

　　等需求的留痕工作做完以后，还得再去检查一下，看看这次的变更是不是已经传递到了测试、设计和交付计划这些相关联的地方。如果只是留下了一条历史记录，可是其他关联的内容却没有跟着一起更新，那整个项目还是会脱节。

　　1、去检查一下变更到底影响了哪些范围

　　拿当前的需求去和上一条基线做个对比，确认每一项新增、删除和修改，都有对应的变更单。如果发现有修改是没有任何说明的，那就得退回让人把原因给补上。

　　2、再检查一下测试覆盖的情况

　　需求的内容被改动过之后，就要去看一看原来的那些测试用例是不是还适用。如果输入的条件、验收的标准，或者业务的流程已经跟着变了，那测试用例和它们之间的覆盖关系也应该同步去调整才行。

　　3、确认好各个版本的关键节点

　　每次经过正式评审并且通过了以后，都应当再去建一条新的基线。基线的名称、创建的时间、对应的评审会议，还有发布版本，这些信息要能互相衔接得上，不要只是写一个类似“baseline1”“baseline2”这样模糊的名字。

　　4、去查看单条需求的历史记录

　　如果后面需要回过头来追查某一条具体的需求，就可以选中那个实体，然后进到【History】→【Baselines】里面，去看一看它在不同基线版本里面都是什么样子。OpenText ALM在Requirements模块里，也是支持查看单条实体的基线历史的。

　　总结

　　需求基线管理的作用，就是把那些已经确认过的内容固定下来，让后面发生的每一次修改都有记录、有原因，也能分析出影响来。想把ALM Soft需求基线管好，以及在基线变更的时候留好痕迹，实际的做法就是用Library确定范围，用Baseline保存阶段性的快照，通过版本控制记录每一条需求的单独修改，再靠着基线对比和测试覆盖检查，确认每一次变更是不是都已经完整地传递到位了。这样一来，在需求被调整以后，项目团队才能快速说清到底什么地方改了，也才能及时把受影响的测试和交付内容给补上。