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

　　一、DOORS模块属性怎么配置

　　在配置模块属性以前，需要先判断这个字段是不是用来描述整个文档或者模块的。如果这个信息只需要在模块这一层维护一次，它就更适合被做成模块属性；如果每条需求都有可能不一样，就不应该把它放在模块属性当中。

　　1、先把属性的用途定义下来

　　在【Attribute Definitions】里面创建属性定义的时候，需要先确认它是被用于模块、对象，还是两者都要使用。

　　IBM的文档也说明过，属性定义可以被应用于模块、模块里面的对象，或者同时应用于模块和对象。比如模块名称、文档版本、适用项目、基线状态、模块负责人、发布批次，这一类的字段通常更适合放在模块属性当中，它们描述的是整份需求模块，而不是某一条需求。

　　2、把属性设置成合适的类型

　　模块属性可以使用字符串、枚举、日期、整数、文本这些类型。枚举字段比较适合状态、阶段、等级这一类选项固定的内容；日期字段适合发布时间、冻结时间、评审时间；文本字段则适合说明类的信息。不要把所有字段都设成字符串，否则到了后面，做筛选、统计和一致性检查的时候，就会比较麻烦。

　　3、控制好权限和维护的入口

　　模块属性通常是在【Module Properties】里面进行维护。

　　IBM的文档里面也提到过，对象属性会显示在对象属性窗口当中，并且每个对象都可以有不同的值；模块属性则在模块属性窗口中可用，用来保存适用于整个模块的值。所以维护的流程需要写清楚，哪些字段由需求管理员去维护，哪些字段由项目负责人去维护，要避免出现多人随意修改的情况。

　　二、DOORS模块属性和对象属性混用怎么办

　　当模块属性和对象属性被混用的时候，先不要急着去删除字段，而是要先看一看，这个属性当前被哪些视图、筛选器、导出模板、DXL脚本或者追溯报表所使用。如果直接去改动字段的类型，或者把属性给删掉，是很容易影响到已有数据的。

　　1、先判断字段的真实含义

　　如果这个字段所代表的是整份模块的共同信息，比如模块的版本、所属的系统、文档的状态，那就应该把它收敛成模块属性。如果这个字段所代表的是单条需求的信息，比如需求的状态、优先级、ASIL等级、验证方法、责任人，那就应该把它当作对象属性。在DOORS里面，正式模块是对象的集合，每一行对象的数据都是存放在属性当中的，这类逐条变化的信息，放在模块属性里面，天生就是不太合适的。

　　2、检查是不是存在一名多用的情况

　　有些项目里面会出现同名的属性，既被用于模块，又被用于对象。IBM的文档提醒过，一个同时作为模块属性和对象属性的属性，它的模块值和对象值是可以不一样的。这样一来就会带来一个麻烦，字段的名字虽然一样，但是读取的位置却不同，报表和脚本就很容易取错值。碰到这种情况，需要先把使用的场景梳理清楚，然后再去决定是不是要把它拆成两个命名更加清楚的字段。

　　3、把历史数据迁移出来

　　如果发现对象这一层的信息，被错误地放到了模块属性当中，那就需要新增一个对象属性，再把对应的数据补到每一条对象上面。反过来，要是模块这一层的信息，被重复地写在了很多个对象属性里面，那就可以保留一个模块属性，把它作为主数据，然后再逐步去清理掉对象上面那些重复的字段。在迁移以前，最好是先把数据导出一份作为备份，免得批量修改完了以后，再想往回退，就变得很难了。

　　三、DOORS属性配置怎么避免后期混乱

　　DOORS的属性，一旦被大量的视图、链接和脚本所引用，到了后期再去调整，成本就会很高。所以属性的设计，最好是在项目的早期就被规范下来，不要一边用一边随手去添加字段。

　　1、建立一套属性的命名规则

　　可以去整理一份属性命名清单，把字段的名称、适用的层级、属性的类型、取值的范围、维护的角色，还有使用的位置，这几项都明确下来。比如模块这一层的字段，可以统一使用Module Version、Module Owner这一类的命名；对象这一层的字段，则使用Requirement Status、Verification Method这一类更加贴近单条需求的名称。

　　2、按照视图去验证字段的使用情况

　　配置完成了以后，要在常用的视图里面去检查字段是不是显示正确了。DOORS支持在模块当中，通过添加列、筛选、排序和保存视图，来查看所需要的数据。如果某个字段是被用来筛选单条需求的，可它却只能在模块属性里面去维护，那就说明属性的层级，很可能在一开始就被设计错了。

　　3、在修改以前，先确认好影响的范围

　　在删除、重命名，或者改变属性类型以前，需要先去确认一下，报表、导出模板、追溯矩阵和DXL脚本，是不是在依赖这个字段。特别是那种枚举字段，选项一旦发生了变化，就可能会影响到筛选的条件，还有状态的统计，不能只是从界面显示的角度去处理它。

　　总结

　　DOORS模块属性的配置，以及模块属性和对象属性混用以后的处理，这里面的关键，是先要分清楚，这个字段所描述的对象，到底是整个模块，还是模块里面的每一条对象。模块版本、模块负责人、文档状态这一类信息，适合放在模块属性当中；需求状态、优先级、验证方法、责任人这一类逐条变化的信息，则应该放在对象属性里面。当混用的情况已经发生了的时候，不要直接去删除字段，而是要先梳理清楚字段的含义、使用的范围，还有历史的数据，然后再去分层进行迁移。等到属性的层级都被理顺了以后，DOORS里面的视图、报表和追溯的结果，才会变得更加可靠。