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

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

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

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

DOORS需求管理系统设计怎么做，DOORS需求管理系统设计不统一怎么办，真正让团队效率下降的，往往不是有没有上工具，而是系统结构一开始就没定好：项目层级有人按部门建，有人按产品线建，属性字段今天加一个明天改一个，视图、模板、状态流转各自为政，最后看起来都在用DOORS需求管理，实际上却很难沉淀成一套可复用的方法。

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

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

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

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

IBM DOORS Classic项目迁移怎么做，IBM DOORS Classic迁移打包清单有哪些，真正容易出问题的地方，不是有没有把项目导出去，而是迁移边界、打包内容和迁移后的核对动作没有提前理顺。很多团队在做IBM DOORS Classic迁移时，只关注模块文件有没有过去，却忽略了属性定义、链接关系、基线版本、权限配置和定制脚本是否同步带走，结果新环境里虽然能看到项目，却无法继续正常协作。

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

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

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

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

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

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

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

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

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

很多团队在用IBM DOORS做需求录入时，习惯先在Excel里整理内容，等到真正导入时才发现列名不一致、空行太多、层级关系丢失、富文本格式被破坏，最后不是导入失败，就是导入后对象顺序和属性全部跑偏。想把IBM DOORS导入做稳，关键不是反复重试，而是先把失败原因拆开，再把映射规则按统一口径设清楚。