【DOORS】需求管理实施过程中的需求属性

一、引言

　　企业在项目中实施需求管理过程中，其中关键的一点是对需求内容进行存储和管理。而针对于需求管理而言，单纯的需求内容的管理是重要的，但是不完备的。需求的表述除了 需求主体 之外，往往还需要额外的属性信息进行补充描述。这些属性的类型随着企业特点、项目特点或是业务流程的不同而有所差异。需求属性的选择不依赖于具体的需求管理工具，而是基于实际的也无需求驱动。本文主要对需求管理实践中一些常用的、典型的属性进行概要性说明，以供参考。

二、典型的属性

1.   需求ID

　　需求管理的最佳实践之一就是对需求进行唯一性标识，这种标识有利于需求的定位以及需求的追踪。需求ID的唯一性最低层级要在单个需求文档内确保唯一，但最佳的方式是推荐在项目的上下文下确保需求唯一性。当然，如果企业需要针对某一特定类型的产品进行统一的需求库的建设，则可以在企业内部进行唯一性标识。

2.   负责人

　　需求的负责人。

3.   需求来源

　　需求来源一般用于进行标识需求来自于哪一个涉众。可能来自于某一个工程师、某一个系统、法律要求等等。

4.   是否需求

　　需求工程师对于需求的阐述文档中一般不全部是对需求的描述，可能会包含一些需求的上下文的描述等非需求信息。该属性用于对需求进行区分。

5.   需求类型

　　需求类型典型的可能包括功能性需求和非功能性需求，当然也可以细分，如功能性需求、安全性需求、可靠性需求、维护性需求等等。通过对需求进行类型标识，有利于为涉众提供一个观察需求的维度。

6.   是否衍生需求

　　众所周知，需求是具有内在的层次结构的，需求管理注重需求层级间的追踪。而实际工程中，有些需求可能是属于衍生需求，这些需求不是通过某条需求拆解而来，它们没有来源。

7.   优先级

　　需求的优先级，例如典型的高、中、低。

8.   风险

　　需求的风险等级。

9.   是否清晰

　　布尔型，是或否，用于描述需求是否是清晰的。

10. 正确性

　　需求是否是正确的。用户的需求不一定总是正确的，这也是需要对需求进行分析的必要性所在。

11. 完整性

　　需求表述是否是完整的，能够完善的表达该表述的意义。

12. 可实现性

　　需求是否是可实现的，例如可以实现、不能实现、

13. 可验证性

　　需求是否是可以验证的，例如可以验证、不能验证、难验证。

14. 可跟踪性

　　需求是否是便于同其他需求或领域项进行追踪的。需求管理的最佳实践之一是需求的条目化，一个段落只表述一条需求，这种细粒度的拆分有利于需求的追踪。相反，一个段落描述了太多的需求，这样粗粒度的追踪大大降低了需求追踪的价值。

15. 验收标准

　　需求的验收标准。

16. 冲突需求ID

　　与该需求存在冲突的需求ID.

17. 评审状态

　　需求的评审状态

18. 测试状态

　　需求当前的测试状态，如待测试、测试通过、测试失败。

19. 实现状态

　　需求的实线状态，例如未开始、未满足、以满足。

20. 备注

三、总结

需求的补充属性很多，不同的企业基于实际业务的需求可能会制定不同的需求属性集合对需求进行补充描述。上述讨论的属性有些是用于需求评审的，如清晰性、完整性、可验证性、评审转台、可跟踪性、正确性、优先级、冲突需求、风险等。有些则关注需求自身的内容信息，如需求ID、是否需求、需求类型、是否衍生需求等。而有些则关注需求的状态，如是实现状态、测试状态等。