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

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

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

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

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

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

很多团队第一次接触DOORS软件时，会把它当成“把需求写进去的表格工具”，结果用着用着就发现越写越乱、越改越难追。DOORS软件的价值不在于记录文字，而在于把需求拆成可管理对象，把属性、链接、基线与评审串成一条可追溯链路，让需求从提出到落地都能被复核、被对齐、被交付。

DOORS Next Generation是什么，DOORS Next Generation与DOORS Classic如何选，很多团队纠结的点并不在“哪个更强”，而在两者的工作方式完全不同：一个以Web协作为中心，把需求拆成可链接、可复用的条目来管理；另一个以模块化编辑为核心，适合在既有资产和脚本体系里持续深挖。

很多人觉得DOORS需求管理效率低是因为需求太多，其实更常见的原因是信息没有被“组织成可检索的形态”：同一模块里对象堆叠、关键字段缺失、视图列随人而变、过滤条件每次重写，结果就是打开慢、找不到、改不动、审不完。

在DOORS里批量改对象属性，看起来只是多选后改一遍，实际最容易出问题的地方有两层。第一层是批改本身没有真正落到对象上，比如模块没开独占编辑、对象或属性没有修改权限，或者改完还停留在未提交状态。第二层是值其实已经改了，但当前显示列没有马上更新，尤其是DXL属性列和layout DXL列，这时肉眼看起来就像没刷新。IBM官方文档对这几步写得很清楚，批量改属性要走对象属性表，模块还必须以exclusive edit mode打开，而显示刷新则要区分普通属性、DXL属性和layout DXL列分别处理。