【DOORS】如何基于DOORS实施需求管理

引言

IBM Rational DOORS，简称DOORS，是被业界广泛认可的需求管理工具，在国内外需求管理领域具有较高的市场占有率。需求管理作为传统的工程领域，理论发展相对成熟和健全。随着越来越多的企业开始注重在需求管理工程层面的投入，企业的需求管理成熟度也在逐步提高。在需求管理实施过程中，不可避免的会依托相关的需求管理工具支撑。而实施过程中所存在的关键困难之一就是：工具与业务如何紧密结合。很多企业虽然购买了相应的产品，但是工具层面的操作培训不足以使得企业的项目在需求管理工具中落地。鉴于此种情况，本文将基于具有较大受众的DOORS工具，对实施需求管理的工作流进行论述。

需求管理的关键要素

要实施需求管理，总要明确需求管理要实施那些内容。本质上，实施那些内容没有统一的规定或约束。但我们可以从一般的需求管理理论层面入手，明确需求管理的理论范畴。

需求管理属于需求工程范畴，需求管理强调四个方面：需求状态管理、需求追踪、需求版本管理和需求变更管理。

　　状态管理：需求除了自身的主题内容描述之外，还具有相应的状态属性。这些属性标识了需求在整个系统研发的生命周期中的状态。基于不同的业务需求，需求需要不同的状态进行描述。从工程师角色维度分析，作为测试工程师，我们可能关注需求的验证状态（验证结果：测试通过、测试未通过或未测试等等）。而作为软件开发人员，我们可能关注哪些需求是由我负责，当前需求的实现状态是什么。作为项目经理，我们可能关注需求的满足状态是什么，又或者是需求的成本等等。同样的，我们还可能关注需求是不是被评审通过了、需求的变更状态等等。

　　需求追踪：需求追踪是需求管理中非常关键且极为重要的方面之一。需求追踪提现在两个层面：需求层级内部的追踪以及跨领域的追踪。需求层级内部的追踪是指在分层的需求间建立的关联关系，例如从用户需求到系统需求间的追踪，从系统需求到子系统需求间的追踪，以及子系统需求到组件需求间的追踪等等。跨领域的需求追踪，是指关联不仅仅发生在需求之间，需求还应该和测试、设计、实现相关的工件建立关联，以实现在系统研发整个生命周期的可追踪性。

　　版本管理：对需求的版本进行管理，记录需求数据的历史记录，方便历史数据的追溯。

　　需求变更管理：变更管理也是需求管理至关重要的一环，也是需求管理中最为常见的活动。变更管理要记录变更的原因、时间、变更内容、变更历史等内容。

当然，以上四个是需求管理的基本要素，至少在需求管理的实现效果中会体现。初次之外，需求管理还有一个横贯所有要素的方面 - 流程管理。对，就是流程，管理离不开流程，高效的流程是实施需求管理的关键。需求管理中经常出现的流程包括但不限于以下几个层面：

　　需求评审流程

　　基线发布流程

　　需求变更流程

　　需求入库流程

需求实施的典型过程

• 启动项目：召集项目相关人员召开项目启动会，明确实施目的、范围、愿景以及协调组织机制，宣布项目启动。该阶段必须要有高层参与，得到高层的潜力支持，这是保证实施项目成功的关键要素之一。
• 确定试点项目：在企业内部选定一个典型项目作为需求管理实施的试点项目，以此确定当前实施的范围。
• 确定项目核心成员：需求管理项目以试点项目为起点，须要试点项目核心成员的参与。明确参与人员列表、角色、职责等。
• 需求管理现状调研：实施团队人员要对客户当前的需求管理现状有明确的认识，通过现状调研，了解企业目前存在的问题及痛点。 -- 生成需求管理现状调研报告。
• 业务流程调研：调研企业内部当前的需求管理相关的业务流程，例如当前的需求管理规范、项目实施的阶段划分、需求变更流程、需求基线发布流程、需求评审流程等等相关流程。-- 生成业务流程调研报告
• 实施方案制定：基于已调研的信息，并结合行业经验，形成需求管理实施方案。
• 实施方案落地：实施方案必然涉及到相关信息化工具的支撑，该阶段基于已评审的实施方案进行实施。
• 试点项目试运行：将定制的方案在试点项目中试运行，解决试运行过程中出现的问题，发现并记录方案潜在的优化点。
• 方案优化：基于试运行的反馈信息，对已有方案进行优化。
• 方案退关：在企业内部更大的范围内推广需求管理实施方案。

基于DOORS的特定实践

结合DOORS的实践主要体现在实施方案的制定阶段，在该阶段的方案细节要充分考虑DOORS工具的功能特点。典型的，包括以下几个层面

• 定义需求信息架构模型：所谓信息架构模型是指需求在DOORS中的组织结构，项目、文件夹、模块、链接模块如何组织，这当然隐式的包括了纳入需求管理的文档范围。
• 定义需求跟踪矩阵： 定义模块间需求的条目的追中关系，例如是从系统需求指向用户需求，还是从用户需求向下指向系统需求。将模块间的链接关系定义好。
• 定义需求属性：基于业务需要，对需求所需要具备的属性进行定制。不同的模块可能定义的属性不太一样。而该定义那些，不同企业和业务流程可能不同。
• 定义模块视图：视图的定制有利于不同角色或用户便捷的定位所需要的数据。同样，基于DOORS的视图机制，根据实际的业务需要定义不同的视图。
• 定义用户权限分配：为用户或角色进行权限分配。

典型的最佳实践

• 以分层的方式存储需求：用户需求、系统需求、子系统需求、组件需求等
• 链接模块单独存在一个文件夹中
• 需求存储条目化，表达多条需求的文字描述要进行拆分
• 需求链接的方向保持一致
• 通用视图：需求评审视图、变更影响分析视图、标准视图、测试视图、实现视图等等
• 通用属性：优先级、来源、分配人员、评审状态、满足状态、验证状态、可验证性、成本、风险、需求类型、是否需求等等
• DOORS模块中只有叶子结点存放需求，非叶子结点不是需求。

总结

不同企业内的需求管理实践各有不同，但共性的都包括需求的状态管理、跟踪、版本、变更以及与之相配套的流程。即使没有需求管理工具的支撑，企业还是可以按照需求管理的理念进行实践。只不过基于需求管理工具能够降低需求管理的复杂性，一定程度上降低成本，提高需求管理的效率。