【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、是否需求、需求类型、是否衍生需求等。而有些则关注需求的状态，如是实现状态、测试状态等。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删