产品线运行久了之后，同一批法规要求、平台公共能力还有接口需求，往往会反复出现在好几个不同的项目里面；于是大家就会关心，在Polarion里面到底要怎么管理需求的复用，以及复用之后产生的版本差异又该怎样去区分，处理的时候绝不能只是简单地做一下复制粘贴，因为复制出来的文档在短期内看着是省了一些力气，可一旦原始的公共需求发生了修改，各个项目就很容易各改各的，慢慢就谁也说不清哪个版本是准的了。好就好在Polarion本身就支持需求的复用和分支管理，既可以共享那些公共的规格，又能够把每个产品独有的差异给保留下来，照着这个思路去梳理就会清晰很多。

　　一、Polarion怎么管理需求复用

　　在决定复用一批需求之前，最好先想清楚，后续是不是允许各个产品自己再去做一些改动；只是让多个文档共同引用同一条需求的做法，跟允许某个产品独立调整这条需求的做法，应该选择不同的处理方式，不能全用一种模式去套。

　　1、只想引用但不想产生副本时保留单一来源

　　如果好几个项目都需要看到同一条公共需求，又规定不能自己随便修改，那就可以直接去引用那一条已经存在的工作项；这样一来，像法规条文、术语的定义，还有那些公共的接口说明，从头到尾就只维护这么一份，别的文档全都通过关联关系去查看它，不会因此生成一大堆内容差不多的副本，Polarion官方资料里面也专门区分过直接复用现有内容、引用已有工作项，以及分支管理这三种不同的思路，可见这一步选对方法很关键。

　　2、公共规格适合用派生文档来分发

　　遇到那些需要下发到多个项目去的法规要求、企业规范，还有平台级的技术要求，用派生文档会更顺手；当源文档那边有人做了更新之后，各个项目团队可以根据自己的实际需要，再去有选择地接收这些变化，Siemens相关说明里也提到过，派生文档特别适合跨项目去共享法规类的需求，并且能够按需把更新分发出去，而不用一下子全推给所有项目。

　　3、产品变体则用分支文档来承接

　　如果某个产品既要继承那一套公共的需求，同时又要允许保留一些自己的修改，那就可以从主文档上面拉出一个分支；主文档继续管好那些通用内容，分支文档则用来补充不同车型、不同客户或不同版本之间的差异，Polarion本身就支持对规格文档做分支管理，拿它来同时维护产品共性和各个产品专属的需求，刚好对路子。

　　4、给复用出来的内容补齐版本信息

　　不管创建的是派生文档还是分支文档，事后都应该记清楚它的源文档是哪一个、源版本是什么、落在了哪个目标项目、对应哪一个产品版本、由谁负责以及什么时间更新的；而且这些需求还得继续跟测试用例、风险项和设计输出保持关联，如果只是把文字给复用过来，追溯关系却没有一块儿保留，那后面再去做影响分析的时候，依然会漏掉不少东西。

　　二、Polarion复用后的版本差异怎么区分

　　复用之后出现的版本差异，不能光靠人一行一行地拿眼睛去比对文本；需要先把变化分成公共基线的改变、各个分支自己独立的修改，还有已经合并完的变化这几类，然后再决定要不要去做同步。

　　1、先看清源文档和分支的关系

　　进到目标文档里面以后，要最先确认它到底是从哪一个主文档分出来的，当前又在对应哪一个产品版本；当不同项目里冒出了标题看起来一样的需求时，不要只看标题，还要结合工作项的标识、源文档和分支关系，来判断它们到底是不是同一条需求，否则很容易混淆。

　　2、用Compare功能来查看差异

　　当分支文档有了一些改动之后，完全可以通过对比功能，把主文档和分支文档放在一起比较；Polarion的Compare视图会识别出那条branched from的关系，把分支之后的需求看作是对原需求的一种变化，这样一来，到底有哪些内容被改过，就会看得比较清楚。

　　3、把发现的差异归成三类

　　新增出来的需求，要去判断它是不是仅仅属于当前这个产品才有的；被删除掉的需求，则需要确认是因为这个产品本身就不适用，还是说公共基线那边已经把它给废弃了；至于字段上的修改，那就要去看描述、状态、优先级和追溯链接这些地方是不是发生了变化，分类整理完以后，再决定是把变化往主文档那边推送，还是从主文档那边把更新拉过来。

　　4、执行合并时要格外谨慎

　　等到确实需要同步变化的时候，再去用Compare和Merge这些功能来处理；像Polarion ALM 2404已经增加了自动合并的能力，可以用三方合并的办法来识别变化，并且对工作项的修改、删除和新增都能应付，也能在主文档和分支文档之间做双向的同步，只是一旦碰上冲突内容，还是得靠人工去最后确认，不能完全放手让机器自动去判。

　　三、Polarion需求复用记录怎么维护

　　当复用的机制慢慢建立起来以后，还得给团队定下一套后续维护的规矩，不然就算文档是能分出分支了，版本的状态还是会随着时间慢慢变乱。

　　1、把主文档的负责人固定下来

　　公共的需求应该只由指定的人员去维护；当项目成员发现公共内容有需要修改的地方时，要走变更申请的路子，而不要直接在好几个分支里面各自改写，这样才能堵住源头上的分叉。

　　2、按发布节点做一轮差异复核

　　每次到了需求冻结、测试准备和版本发布的前面，都应该对主文档和分支文档做一次差异检查，新加进来的、被删掉的、等着合并的，还有已经确认要保留的差异，都要分别记录，让每一次发布时心里都有本明白账。

　　3、把每次变更的说明保留好

　　每一次做合并操作的时候，都要记清楚来源是哪里、目标是哪里、为什么要做这次修改，以及由谁来最终确认的；需求文字变了以后，还要顺便去检查一下它所关联的测试、风险和设计输出，看看这些东西是不是也需要跟着同步更新，免得住干一处湿一处。

　　总结

　　总的来看，在Polarion上管理需求的复用以及区分复用后的版本差异，完全可以按照“先判断复用的目的、再选择引用或派生或分支、接着记录好版本关系、然后执行差异对比、最后确认合并结果”这样一条顺序来处理。公共的内容尽量保留单一的来源，让各个产品独有的差异交放到分支文档里去维护；只要版本变化能够看见来源，也能够追溯到当初的处理记录，需求的复用才不至于慢慢变成一种新的文档负担。