DOORS模块属性与对象属性的配置，以及二者发生混用时的处理办法，是需求库整理、评审流程和追溯报表里很容易出错的问题。在IBM DOORS当中，模块和对象的信息都可以通过属性来保存，属性通常由属性类型、属性定义和属性值这几个部分组成，但模块属性与对象属性的作用范围并不相同，前者描述的是整个模块，后者描述的是模块里面的具体对象。一旦混用，常见的问题就是报表字段不准确、筛选结果出现异常、需求状态统计发生错位，甚至同一个字段在不同的视图里面，含义也变得不一致。

当需求模块里的属性越加越多以后，负责人、状态、优先级、验证方式还有追溯信息这些内容，很容易全挤在同一个界面上，看得人眼花缭乱；所以要弄清楚在DOORS里面怎么去调整属性列的顺序，以及当属性列突然显示不全的时候又该怎么恢复过来，一般是不用去修改属性本身的定义的，只要把当前模块的视图好好整理一下就行，DOORS允许我们在模块里插入新的属性列或者Layout DXL列，也能随时编辑、移除这些列，然后把整理好的布局保存成视图，后面再打开这个模块的时候，就能继续使用同一套排布方式。

在需求模块里误删了一条对象，最怕的就是马上再手工新建一条内容差不多的来顶替，这样做看起来是把东西补上了，可实际上原来的对象标识、关联链接还有变更历史，很可能全都变了样。所以要弄明白DOORS里面怎么把误删的对象恢复回来，以及恢复以后编号为什么会跟以前不一样，就得先分清楚对象只是被标记成了删除状态，还是已经被彻底清除掉了，因为前一种情况还能挽回，后一种就真的从模块里移走了。

在日常维护需求对象的时候，我们经常要往里面塞规格书、测试截图、表格这类附件，有时候放进去以后，过一阵子却发现打不开了，或者别人那边根本看不到。要在DOORS Classic里把这个附件管理清楚，并且搞清楚链接失效之后怎么修，首先得知道导入文件的时候，它是直接把文件嵌进数据库里，还是只留了一条路径指向外面的文件。嵌入的做法会把原文件整个复制到DOORS属性中，哪怕外面那份文件后来被删掉或者修改了，库里的东西也不会自己跟着变；而链接这种方式记的只是一个路径，源文件一旦更新，链接就能反映出来，但只要那个共享路径一变动，或者权限被调整，链接就很容易断开。

当需求文档被导入到DOORS里面以后，章节的结构经常还需要继续调整，不管是新增一条需求、挪动一个小节，还是补进去一组子需求，后续的编号都会跟着变。做这类调整的时候，最好提前把标题对象和正文对象分开来看，标题一般填在Object Heading里面，具体的一条条需求内容填在Object Text里。一个标题的下方可以再放子标题，也可以直接放多条正文需求，用这种层级关系来搭文档结构，比手工在标题前面敲编号要灵活得多。

DOORS链接模块怎么配置，链接模块的关联关系失效了又要怎么修复，在做需求管理和需求追溯的时候，这是很常被碰到的问题，DOORS里面的链接这个东西，它可不是简简单单地把两个对象给它连到一块儿就算完了，在它背后还会去牵扯到链接模块、源模块、目标模块、链接的方向，还有权限的设置这些事情，要是链接模块的配置没有被弄得明明白白的，到了后面去做需求追溯、覆盖率的检查、影响分析的时候，就很容易会跑出来关系被断掉了、链接在那边看不到、追溯的那条链子它不完整，这一类的问题了。

需求模块被反复修改过之后，光靠当前页面上的样子，其实很难一眼就看出某条需求是被谁改的、具体改动了哪些地方，以及会不会对下游那些对象产生影响。在DOORS里面要把对象的历史记录管好，关键就是要把对象自身的历史、整个模块的变动痕迹、页面上的变更提示，还有按阶段存下来的基线这四样东西，搭配在一起去看。如果对象历史已经攒得太多，那就要先把对象的范围、是谁改的、大概在什么时间改的这些条件给缩一缩，然后再去仔细核查那些真正牵动了需求内容的改动。DOORS会在后台自动记录下新建、编辑、移动、删除、恢复和粘贴这些操作，同时也会把对象属性里面的“最后修改人”和“最后修改日期”这两项一并刷新下来。

需求模块里的内容越积越多以后，光去扫一眼对象的总数，已经远远不够用了，评审的时候大家通常还要知道新增的需求究竟有多少、已经确认的有几条、正在等着验证的有几条，还有分到不同优先级下面的对象又各占了多少。所以，在DOORS里面怎么把这些统计结果生成出来，导出以后又该怎么把表格的格式理顺，这两件事就变得挺实际了，下面就以DOORS桌面端的正式模块作为例子，展开说明一下。比较稳当的操作次序是，先为统计这件事单独建好一个视图，再通过筛选去把各项的数量看清楚，最后把当前这版视图导出成表格文件，拿到外面去再整理。

在多人一起维护需求文档的时候，最怕出现的情况就是两个人同时改到了同一处地方，可能一个人正在那里重新梳理对象的层级，而另一个人还在继续往里面补充属性信息，等到各自保存的时候，前面刚做好的修改就很容易被后面保存的动作给悄无声息地盖掉。所以，想要弄明白在DOORS里面怎么把正在编辑的模块给锁住，以及模块被别人占用了以后又该怎么去解除锁定，就得先分清楚当前用到的到底是整份模块独占编辑，还是按照章节来共享编辑，因为这两种模式能够锁住的范围是不一样的，解除锁定的操作方法也完全不同。

当项目里的需求条目慢慢增多以后，再去靠手工一条条核对字段、刷新追踪关系、梳理模块内容，效率就会明显跟不上。在DOORS Classic这个环境里，要弄清楚怎么用DXL脚本来帮忙干活，以及万一脚本跑着跑着报了错，又该从哪入手去排查，这些就是咱们要讲的重点。DXL是DOORS平台自己带的一套脚本语言，它能自动计算字段值、响应系统里的事件，还能给菜单添加自定义功能。它的写法跟C语言、C++有点接近，但里面涉及到的对象、模块，还有权限这些东西，都必须遵守DOORS运行环境的那套规矩。

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

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

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

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

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

DOORS里头的对象编号到底要怎么维护，对象编号重复了以后又要怎么去重新排序，这些事情，先要分清楚两种不一样的编号：一种，是DOORS它自己自动给弄出来的对象标识；另外一种，是团队自己人维护起来的那些需求的编号。在DOORS里面，那个对象标识，一般是跟模块的前缀，还有对象的绝对编号这些东西有关系的，主要是用来把一个对象给定位住的；在跳转的那个功能里面，你直接输一个整数，就能定位到对应那个绝对编号的对象上，要是输入一个能用的模块前缀再加上对象的编号，也是能定位到那个对象标识上去的。可真正容易给弄重复了，真的需要去重新排一排的，常常倒不是系统自动给的那些编号，而是从Word、Excel，或者是自定义的那些属性里面，带进来的那一些业务上的编号。

当需求模块打开之后，搞研发的、做测试的还有负责质量的人，他们所关心的字段其实是不一样的。要把DOORS里面属性的列顺序给调整好，还有遇到某些属性列不显示了又该怎么恢复过来，头一件事就是得先弄清楚，现在在界面上看到的，只是当前这个模块所套用的一个视图而已，它并不是属性本身的定义。在DOORS Classic里面，是允许往模块中添加新的属性列、去拖动调整它们的先后顺序、设定每一列的宽度，还能把这一整套的界面布局给保存成一个视图的，并且这个视图不光会记住列怎么摆的，连筛选的条件、排序的规则，还有层级展开的情况，也都会一块儿记住。

当需求模块里面的对象越积越多以后，光是手工去逐条翻看它们的状态、负责人，还有彼此之间的链接关系，就会变得很花时间。要在DOORS里面把过滤条件给设好，以及为什么过滤结果明明保存了，下次打开却看不到效果，这里头很关键的一点，就是得把“过滤条件”和“视图保存”这两件事情分开来理解。过滤器它管的是，哪些对象会被显示出来；而视图呢，负责记住的是当前用了哪些列、按什么顺序排的、有没有开着过滤，还有层级展开的样子。下面就以DOORS Classic这个客户端来举例。

在需求评审的过程里，状态、优先级、验证的方式，还有负责的部门这几项，通常都是需要从一组固定选项里来选的，不能让大家随便填。用经典版DOORS的Formal Module来管理需求时，枚举属性就很适合用来限制这种填写范围，打个比方，可以把需求状态限定为“草稿”、“评审中”、“已确认”和“已关闭”这几种。DOORS里面的属性，是由属性类型、属性定义和属性值这三部分组成的，枚举的那些选项应该先在属性类型里面配置好，然后通过属性定义绑定到模块或者对象上去，这样后面用起来才不会乱。

一旦需求发生了修改，跟它关联在一起的那些设计说明、测试用例，还有下游的需求，就不一定还能原样成立了。DOORS会把受到牵连的对象标成“存在可疑链接”，用来提醒项目里的人重新去确认一下追溯关系。可疑状态并不等于链接本身就错了，也不代表应该马上把链接删掉，它只是在说，上游或者下游的对象已经变动过，需要重新去掂量一下影响的范围。