很多团队刚开始用ALM做需求管控时，都会把基线理解成一把总开关，觉得只要点了发布，后面的内容就应该一动不动。可真到项目里，往往会出现两种情况，一种是根本没找到正确的建基线路径，另一种是基线发了，当前需求还是有人在改，最后审计、回溯、签审都变得很被动。按OpenText ALM现有文档的定义来看，baseline更像某个时间点的快照，真正要把它用稳，还得把Library、权限和版本控制一起配起来；另外，Libraries模块并不是所有版本都有完整能力，这一点也要先确认。

　　一、ALM需求基线怎么建

　　很多人会直接在【Requirements】里找基线按钮，找不到就以为功能没开。其实在ALM里，需求基线不是从需求树直接生成的，而是先把需求纳入Library，再从Library创建Baseline，这个顺序别走反了。

　　1、先把本轮要冻结的需求收口

　　不要一边还在补需求字段，一边就急着出基线。用户指南里写得很清楚，需求经过评审后再建立baseline更合适，因为它本来就是拿来做阶段签收和后续比较的。实操时先把本轮范围内的需求状态、层级、负责人和关键属性整理好，后面比差异时才不会一堆噪音。

　　2、到【Management】下打开【Libraries】建目录

　　具体操作可以按这个顺序走，先进入【Management】下的【Libraries】，再在根目录上右击新建文件夹，需要分层管理的话继续在文件夹下建子文件夹。ALM用户指南给的标准路径也是先建library tree，再把library放进对应目录里，这一步其实就是给后面的需求基线准备容器。

　　3、在目标文件夹里新建Library并装入需求

　　在目标文件夹上右击【Create Library】，先把名称和说明填清楚，再切到【Content】页选入本次需求。这里别只会手工点树，官方文档提到Library的内容可以结合过滤条件来选，这对版本范围大、需求条目多的项目很实用，你可以按模块、优先级、负责人或某次发布范围把需求装进去。

　　4、对Library执行【Create Baseline】

　　Library准备好以后，右击这个Library，执行【Create Baseline】。系统会在后台跑任务，官方建议在【Details】页先点【View Log】看创建过程，等任务结束后再刷新，因为一旦刷新过头，刚才那个日志入口就没了。这个细节很小，但真到排查失败原因时特别有用。

　　5、创建完先做两件检查

　　第一件事是到工具栏或顶部菜单看任务有没有跑完，官方给的查看入口是【Tools】下的【Task Manager】。第二件事是拿新基线去做一次对比，右击baseline后用【Compare To】去比另一个baseline，或者直接比当前实体，这样你能马上确认这份快照到底抓到了哪些需求。后面如果想从需求侧回看，也可以在实体历史里查看baseline记录。

　　二、ALM基线发布后如何防止被改

　　这里最容易混淆的一点，是基线本身和当前需求并不是一回事。基线是快照，当前需求是活数据。你真正要防的，不只是baseline记录被人改，还包括需求树、Library同步动作和编辑流程被人随手碰了。管理员如果只发基线，不收权限，后面还是会乱。

　　1、先把需求编辑权限收紧

　　最直接的做法，是进【Project Customization】里的【Groups and Permissions】，选中对应用户组后，把【Requirements】页签下的【Requirement>Update】和【Requirement>Delete】收紧。管理员指南明确写了，这两项都可以按字段控制，还可以设成【By Owner Only】。换句话说，哪怕有人能看到需求，也不一定要给他改需求的权利。

　　2、把基线相关权限单独锁住

　　很多项目把需求改不了，却忘了把baseline权限收掉，这样还是会留下口子。官方权限表里把这块拆得很细，至少要检查【Baseline>Update】、【Baseline>Delete】、【Library>Update】、【Library>Synchronize library to baseline】这几项。常见做法是只给少数配置管理员保留，普通需求人员和测试人员不放开。

　　3、能用【By Owner Only】就不要全员放开

　　管理员指南反复提到一个思路，就是很多更新、删除、同步动作都能设成【By Owner Only】。这不是装饰项，是真能挡住误操作。项目里最怕的不是恶意修改，而是别人觉得自己只是顺手调一下描述、同步一下library，结果把原来签过字的基准面搞乱了。把高风险动作缩到所有者级别，成本不高，效果很直接。

　　4、把版本控制也一起打开

　　如果项目里需求还在继续演进，单靠权限不够稳，最好再把版本控制开起来。管理员指南给出的开启路径是【Site Administration】里的【Site Projects】，选中项目后执行【Enable Versioning】。版本控制开好后，需求在修改前要先检出，别人会看到锁定状态；用户指南里甚至直接举了需求分析师检出一组requirement，避免别人同时改动的例子。这一步对多人并行维护特别重要。

　　5、把“改需求”和“发基线”拆成两种角色

　　这条不是界面按钮，但很实用。需求维护人负责日常更新，配置管理员或项目负责人负责基线捕获和发布，别让同一批人大范围同时持有【Requirement>Update】和【Baseline>Capture baseline】加上同步权限。ALM的权限模型本来就是按用户组分开的，角色拆开以后，流程会顺很多。这个做法是基于权限设计逻辑做出的配置建议。

　　三、ALM基线发布后为什么看起来还在变

　　项目里最容易引发误会的，不是别人真把基线改了，而是大家看到当前需求变了，就以为之前的baseline也失效了。其实很多所谓“基线被改”，本质上是把快照和现行数据混到一起看了。

　　1、先分清baseline和current entities

　　官方在比较功能里写得很明白，baseline可以拿去跟另一个baseline比，也可以跟current entities比。既然存在这个比较入口，就说明baseline天生就是一个参照面，而不是当前树的实时镜像。所以你看到当前需求内容变了，不等于老baseline被覆盖了。

　　2、Library被同步了不等于旧基线没了

　　ALM允许对library做同步，这意味着当前library内容可以继续向前走，但先前已经捕获的baseline仍然是历史快照。真正需要防的是有人拿着同步权限去推动library变化，却没人意识到这会影响后续比较结果。这个风险点在权限表里已经单独列出来了。

　　3、看起来被改也可能只是字段还能编辑

　　管理员指南里明确写了【Baseline>Update】是可以配置到字段级的。如果这项权限没关干净，别人不一定能删baseline，但可能还能改它的某些属性字段。项目里一旦出现“名字改了”“说明变了”“所有者变了”，大家就会误以为整份基线都被动过。所以权限检查时不要只看删除权限。

　　4、最终判断不要靠感觉要靠历史和对比

　　最稳的办法不是在群里问谁改了，而是直接回到baseline history和compare结果里看。ALM本身就提供了基线历史和比较能力，用它来核对差异，比单看当前需求页要靠谱得多。只要基线创建时内容抓对了，后面谁改了当前需求，差异都会留下可查的痕迹。

　　总结

　　ALM需求基线怎么建，ALM基线发布后如何防止被改，真正的关键不是把【Create Baseline】点出来，而是先把需求装进正确的Library，再把权限、同步和版本控制一起管住。这样做完以后，基线负责留住历史，当前需求负责继续演进，二者各走各的线，项目在审计、追溯和变更评审时才不会越看越乱。