DOORS里头的对象编号到底要怎么维护，对象编号重复了以后又要怎么去重新排序，这些事情，先要分清楚两种不一样的编号：一种，是DOORS它自己自动给弄出来的对象标识；另外一种，是团队自己人维护起来的那些需求的编号。在DOORS里面，那个对象标识，一般是跟模块的前缀，还有对象的绝对编号这些东西有关系的，主要是用来把一个对象给定位住的；在跳转的那个功能里面，你直接输一个整数，就能定位到对应那个绝对编号的对象上，要是输入一个能用的模块前缀再加上对象的编号，也是能定位到那个对象标识上去的。可真正容易给弄重复了，真的需要去重新排一排的，常常倒不是系统自动给的那些编号，而是从Word、Excel，或者是自定义的那些属性里面，带进来的那一些业务上的编号。
一、DOORS对象编号怎么维护
对象编号的这个维护，不能就只是盯着那个显示出来的顺序看。需求的对象在模块里面，是会不断有新加进来的、有给删掉的、还有挪来挪去的，你要是把那个“显示的位置”和“那个唯一不变的标识”给弄混到一块儿去了，那到了后面，追溯、链接，还有评审这些事，就全都要乱套了。
1、要把系统给的那个编号，和业务上的编号给分开来看
DOORS自己主动生成的那个对象标识，是不太建议你把它当成是那种能随便去改动的章节编号来用的。这个东西，它更适合拿来给对象做定位和追溯，因为对象创建了以后，这个编号它就有了那个唯一性，而且很稳定。要是项目上确实需要像REQ-001、REQ-002这一种连着下来的业务编号，那就最好是单独再去建一个属性来维护它，可别想着去改那个系统的对象标识。对象标识这个东西，它自己本身，是不能够像平常那些文字一样，能让你随随便便就去给改写掉的，这也就是它为啥，适合去当一个稳定的追溯标识的原因。
2、把模块的那个前缀给维护好
在【Module Properties】这里面，去检查一下模块的前缀，要确认好，在同一个项目里面，这个命名的规矩是清清楚楚的。
那个模块的前缀，它是会参与到对象标识的展示里面去的，所以最好是照着项目、系统、子系统，或者是模块是拿来干什么用的，去给它统一地起名字。不要让好多个模块，随随便便地就都用上了一样的前缀，要不然的话，不同模块里面的那些对象，看着就会特别的像，等到导出文档，或者是做评审的时候，是很容易就给弄出误会来的。
3、把从外面导进来的编号给它管好
从Word或者是Excel里面，往里头导需求的时候，得要先决定好，要不要把原来文件里面的那个编号给留下来。原来文件里面那种1.1、1.2的，或者是REQ的编号，要是直接就给你导进到正文里面去了，那后头再在DOORS里头去移动这些对象的时候，它是不会自己就跟着那个业务的逻辑去更新。一个更稳当点的搞法，是把原来文件里面的那些个编号，给它放到一个单独的属性里面去，正文里面，就只把需求的那个内容给留下来就行了。
二、DOORS对象编号重复后怎么重新排序
要是你发现“对象的编号给弄重复了”，先别着急，上手就去直接一大批一大批地改。得先去判断一下，给弄重复了的，到底是系统给的那个对象标识，还是你们自己定的那些需求的编号、章节的号、还有从外面导进来的编号。这些编号的来源不一样，后头要对付它们的法子，那也是完全不同的。
1、先去确认一下，这重复的来源到底是什么
要是重复的是系统的那个对象标识，在一般正常的情况下，它是不应该会出现真正的重复的。要是你瞅着它好像是重复了，那有可能是不一样模块的前缀给用成了一样的，或者是往出导表格的那会儿，光把数字的那一部分给导出来了，没带上模块的那个前缀。要是重复的是你们自己定的那个属性，就比如说是Req ID、需求的编号、文档的编号这些，那这个，就得照着项目自己的那套规矩，去重新把它给捋顺了。
2、去把那些自己定义的编号，重新给排一排
在【Attributes】这个里面，把团队自己维护的那个需求编号的字段给找到，然后再照着现在对象排好的那个顺序，去重新给它填上。
在动手重排之前，最好是先把当前这个模块的清单给导出来，这里面要包含着对象的层级、标题、现在的那个编号、对象的标识，还有链接的状态。等这些都核对得没毛病了，然后再去用脚本、批量的编辑，或者是表格回导的这些法子，去把自定义的编号给更新一下。可别直接就往系统的那些字段上头去覆盖，也别光凭着页面上显示出来的样子，一条一条地拿手去改，这样是很容易给漏掉的。
3、要把旧的那个编号的对应关系给留下来
在重新排完了以后，最好是能把旧编号对着新编号的那个关系，给它保留下来的。因为好多项目里，那些评审的意见、测试的用例、变更的单子，还有外部的那些文档，说不定还在引用着旧的那个编号呢。要是光改了一个新编号，却不把这个对应关系给留下来，那后头别人再去翻查以前那些问题的时候，是会找不到它对应的那个对象的。
三、编号维护时怎么避免后续混乱
维护这个编号，真正让人头疼的，倒不是动手去改一回两回的，而是到了后面，怎么能让它一直都不乱起来。DOORS的这个模块，它是要不断地往里头加新对象、删旧对象、挪动对象的，要是没一个统一的标准，那这个编号，用不了多久，就又会冒出断号、重号，还有引用对不上的这些毛病了。
1、别太去追求系统的那个编号，是不是连着的
系统给对象的那个编号，中间有跳过去的号，这是很平常的事。对象被删掉了、清理过了，或者是以前有过什么操作，这编号它就不一定是连着的了。系统编号这个东西，它要紧的地方是在于唯一，还要稳定，可不是为了排起版来好看。要光是图文档的那个顺序看着顺眼，是可以用章节的那个层级，或者是自己定义一个显示的编号的，不要去硬生生地重置那个绝对的编号。
2、把编号的那套规矩给统一起来
一个项目，它应该提前就把编号的格式、啥时候去生成它、让不让拿手去改、对象删了以后那个编号还让不让别人再用，这些个规矩，全都给规定好了。就比方说，是可以规定需求的编号只准往上涨，不准往回调，废弃掉的对象就让它留着那个状态，不把它的编号收回来再用；也能规定，在正式发布之前，统一去生成一版正式的编号。规矩有点不一样，这倒没啥大问题，但就是得给它固定下来才行。
3、每次有变动了以后，去做一回检查
每回在批量导入、把模块给拆开、移动了需求，或者是给编号重排了以后，都是要去查一下有没有重复的编号、空着的编号、链接断掉了的对象，还有外面引用的那些情况。特别是基线快要发布之前的那会儿，最好是能把对象的标识、自定义的编号、章节的层级，还有链接的这些关系，搁在一块儿去核对一下，省得到了评审完了以后，还得再回过头来返工。
总结
DOORS对象编号怎么维护，对象编号重复了以后又要怎么去重新排序，这里头核心的一件事，就是先要去把系统给的对象标识，和自己定义的那些业务编号，给区分开。系统的对象标识，别去随便地改动它，也别为了图一个连着的好看，就硬去给它重排；真正需要去费心维护和重排的，一般是团队自己定下来的那个需求的编号属性。碰上编号有重复的时候，要先查清楚这个重复是从哪里来的，然后再照着当前模块里面的那个顺序，去把自己定义的编号给理顺了，并且把旧的编号映射关系给保留下来。这么弄，就既能保证DOORS里面追溯起来是稳稳当当的，也能让导出去的文档，还有评审的那些材料，都显得更清楚一些。
