DOORS视图过滤怎么设置，视图过滤之后需求条目变少了又要怎么排查，做需求评审、状态统计、追溯检查的时候，很容易碰到这个问题。DOORS里面的视图，它不光是管着显示哪几列，还会把过滤、排序、层级隐藏这些设置叠在一块儿；过滤器本身也能按属性、链接还有对象的条件，去把模块里的对象筛出来。所以视图这么一切换，需求条目忽然就变少了，这个不一定是需求被删掉了，更多的时候是被过滤的条件、层级显示或者是权限的状态给挡在了外头。

在处理需求拆分、版本派生，或者对模块进行重新编排的时候，常常会碰到需要把一整批对象给复制到新模块里去的情况。那么在DOORS里面，到底应该怎样把对象复制到新模块里，又为什么明明复制完成了，链接却会跟着丢掉，这背后的原因，通常并不是系统出了什么故障，而是我们选的复制方式本身就没有把原先的链接给带过来。能不能做到这一点，关键在于得先把它想清楚——这次操作，究竟是只想把内容简单地搬个家，还是希望连同它们之间的追溯关系也一起迁过去，因为DOORS对跨模块的对象复制和整个模块的复制，所采用的规则是完全不一样的。

在做系统需求、软件需求和测试用例之间的追踪时，光靠手工备注是不够的。经典版DOORS通常用Link Module来存标准链接信息，然后用Linkset去记录从某个源模块指向某个目标模块的那一组链接。动手建立这些之前，最好先统一追踪方向，比如系统需求指向软件需求，软件需求再指向测试用例；要是方向不先约定好，后面去查覆盖率、做影响分析的时候就会很乱。

需求文档在迭代多次之后，仅仅通过文件名来分辨哪一处内容被修改过，已经相当困难。为了更好地梳理变更情况，我们就需要掌握两个关键操作：一是怎样用DOORS去比对两个模块，二是比对结束后如何把差异的结果导出来。这里以IBM Engineering Requirements Management DOORS的桌面版本作为说明对象。通常，对于两份各自独立的模块，可以借助模块比对向导来处理；而针对同一个模块的不同冻结快照，采用基线比较会更合适一些。这两种情形最好不要混杂在一起操作。

IBM Rational DOORS怎么做基线，IBM Rational DOORS基线与版本如何管理，很多团队不是不会用DOORS，而是把“基线”“版本”“变更”“交付”当成四件互不相关的事：有人在模块里随手点一次Baseline就算完成，有人在发版前才临时复制模块当备份，还有人靠邮件和表格记版本号，最后一到追溯就对不上。

DOORS系统需求分析报告口径不统一怎么办，DOORS系统需求分析报告评审标准如何定，很多团队在做DOORS系统需求分析时，最大的阻力往往不是需求写不出来，而是同一份系统需求分析报告在不同人手里呈现出不同口径：术语不一致、层级不一致、字段不一致、评审结论也落不下来。

很多团队一开始把DOORS当成“装上就能用”的工具，等需求量上来、并发变多、跨地点协作一开，才发现同样的模块有人秒开有人卡半天，同样的查询有人顺滑有人转圈。问题往往不在某一次操作，而在DOORS系统架构从部署形态、网络路径、数据组织到运维节奏没有统一口径。

在DOORS里复制模块，真正容易出问题的地方，不是【Copy】这个动作本身，而是复制完成以后，大家默认以为链接也会原样跟过去。IBM官方文档把这件事说得很清楚，数据库资源确实可以在【Database Explorer】里通过剪切、复制、粘贴来处理，但模块复制和链接保留并不是一个简单的“全带走”逻辑，尤其是入链、链接模块和目标模块不一起复制时，结果最容易和预期不一样。

在DOORS里，链接一开始没定规矩，后面通常不会只是“有点乱”，而是会直接影响追踪、评审、基线和变更判断。IBM官方说明里讲得很清楚，标准链接信息是放在link module里的，而每个link module下面又会按源模块到目标模块拆成不同linkset；同时，正式模块还能定义default linkset pairing和mandatory linkset pairing，用来控制链接到底该落到哪个link module。也就是说，所谓链接规则，核心不是写一条口头规范，而是把链接语义、落点和权限一起固化到模块配置里。

在DOORS里维护外部链接，最容易踩坑的地方，不是链接怎么建，而是把它当成普通链接去管。IBM官方文档写得很清楚，外部链接是从DOORS对象指向当前数据库之外资源的单向链接，可以指向网页，也可以指向别的DOORS数据库对象；同时它们并不存放在link module里。这个边界一旦没分清，后面做集中维护和批量修复时就很容易走错路。