一、需求管理概述

需求管理是一种系统化方法，用于获取、记录、组织和跟踪系统需求，并使客户和项目团队在系统需求变更上保持一致。有效的需求管理在于维护清晰明确的需求描述、每种需求类型所适用的属性，以及与其他需求和其他项目工作之间的可追踪性。

需求管理的目的是在产品的整个生命周期中对期望与需求控制基线的变更进行管理，保持在利益相关者期望、客户需求、产品技术需求、产品组件需求、设计文档与试验计划和技术规程之间的双向可追溯性。成功的需求管理的关键活动如下：

·按照利益相关者的期望、使命任务目标及约束、运行使用目标、使命任务成功准则，对需求进行确认。

·从系统设计流程获得需求并将它们组织成层次化树状结构。

·建立执行需求管理的计划，让当前项目计划和需求保持一致。

·在需求之间建立双向可追溯性，通过需求跟踪对应的设计、制造和试验工作。

·为需求设立控制基线，在整个项目过程中跟踪需求状态及其变更情况。

·评价项目生命周期中需求控制基线的变更请求，实施经过变更委员会批准的变更请求。估计变更所产生的影响并在此基础上协商新的约定，以一种可控制的方式将需求变更融入当前项目中。

·为每一个需求定义验证方法，维护需求、应用场景和架构/设计间的一致性，并采取消除不一致性的行动。

二、需求管理的内容

1.需求管理的特定实践

需求管理包含5个特定实践，如图14-1所示。

图14-1　需求管理实践示意图

·获得对需求的理解：在初步整理需求的基础上，项目需求分析人员和用户代表通过初步的分析讨论，对当前项目的需求达成共识，并在需求列表中进行相应记录。

·获取需求承诺：通过项目参与者的书面承诺，建立各方或各项工作的基准。

·管理需求变更：维护变更历史，为调整与控制提供数据支撑。

·在需求变更后维护对需求的双向可追溯性：从系统（产品）可维护性的角度提出管理要求。

·标识项目工作（包括计划和产品）与需求的不一致性：若发现不一致性，即启动纠正措施。

2.需求管理的管理流程

上述5个特定实践可归结为以下3项活动，即需求确认、需求跟踪和需求变更。

（1）需求确认

需求管理的一项重要工作是根据利益相关者的期望、使命任务目标与约束、运行使用目标及任务成功准则进行需求确认。需求确认包含了两项重要工作：需求评审和需求承诺，即图14-1中的第1、第2个特定实践。其中需求承诺是由开发方和客户共同对主要需求文档——需求规格说明书进行评审，双方达成共识后做出的书面承诺，使需求文档具有合同效力。

需求确认主要包括如下3个步骤：

1）需求是否正确书写：确认以“需要”形式陈述的需求，并更正格式错误和编辑错误。

2）需求在技术层面上是否正确：在将需求交给利益相关者评审之前，技术团队中训练有素的评审人员要辨识并尽可能多地去除技术错误。

3）评审人员应当对需求陈述做如下检查：

·需求对于控制基线设定的利益相关者的期望是否具有双向可追溯性。

·所用的假设是否合理。

·需求对产品设计、生产、交付、服役等阶段的成功准则是否重要。

·需求是否令利益相关者满意：所有利益相关者检查并去除需求缺陷。

需求确认的结果常常是决定项目能否进入功能分解或系统综合流程的关键因素。项目团队应该做好以下准备工作：

·证明项目需求是完备和可理解的。

·证明评价标准与需求是一致的，与使用和保障概念是一致的，并获得利益相关者的认可。

·证明运行使用构想及架构概念可以支撑使命任务需要、目的、目标、前提、方针和约束。

·证明管理需求变更的流程已经在项目知识库中建立和记录，并已经与利益相关者交流。

（2）需求跟踪

需求跟踪包括图14-1中的第4、第5个特定实践，即维护对需求的双向可追溯性和标识项目工作与需求的不一致性。为了有效地检验最终系统或产品能否满足所有需求，对项目的需求要进行跟踪管理。跟踪的目的是建立与维护“需求—设计—制造—测试”之间的一致性，确保所有工作成果都符合用户需求。为此可采用需求大纲中的需求跟踪矩阵，对每个需求追踪到实现该需求的设计、制造以及测试用例，从而验证产品是否实现了所有需求，是否对所有需求进行过测试。

（3）需求变更

需求变更是图14-1中的第3个特定实践。在项目过程中，可能会发生需求和约束的变更。随着项目的进展，用户和开发方对需求的了解越来越深入，原先的需求文档很可能存在错误或不足。另一方面，市场会发生变化，原先的文档也可能跟不上当前的市场需求。可见需求变更总是不可避免的，有些是为了修正缺陷，有些属于增强功能。需求变更控制是需求管理中最重要的工作，将在本章第四节详细讨论。

三、需求管理的关键

1.专注需求的可追溯性

在记录每一个需求的同时，应当记录其双向可追溯性。对于每一个需求，应当回溯其控制基线文档中的高层需求/源需求或期望，或确定其“自源性”并从更高层的需求源寻求其一致性。自源性需求可以是源自于从局部优化角度采纳的需求，或者是在执行功能分解与系统综合活动时产生的需求。

如果可能，应对需求进行独立的评价，以确保需求追溯关系的正确性，并确保其完备地表达了高层需求。需确保所有记录的顶层需求已经分配至较低层次的需求中。如果出现没有高层需求而又是不可接受的自源性需求，那么只能假设追溯流程存在缺陷而重新进行，或干脆假设这些需求是画蛇添足。

需求的追溯性通常以需求矩阵的形式记录。追溯性定义如下：

·追溯性：在两个或者更多的逻辑实体（如需求、系统单元、验证或者任务）之间可辨识的联系。

·双向追溯性：在两个或者更多的逻辑实体之间双向的可辨识联系（如指向或者发自实体）。

2.严格控制需求变更

为有效管理需求变更，需要在变更被批准与实施之前评估变更对需求控制基线的影响。必须先描述控制基线的技术状态，并指明评估变更影响的工具。以下典型工具常用于分析变更带来影响：

·性能余量列表：这个工具是系统关键性能余量及其当前余量状态的列表，为确保任务可以安全可靠地完成，必须让系统性能保持一定的冗余量。这些冗余量在需求变更的过程中会有所变化，更多的可能是余量被吞噬。

·技术状态管理的主要评估人员名单：这份名单由项目管理办公室开发，目的是确保由合适的人员评估变更及其影响。所有变更需按顺序送到合适的人员手中，确保辨识出变更的所有影响。这份名单需要定时更新。

·风险分析系统与威胁列表：风险分析系统可以用来辨识项目的风险及其与成本、进度、技术方面的关联。控制基线的变更可能影响辨识风险的结果，或给项目带来新风险。威胁列表通常用来辨识与项目所有风险相关的费用，项目备用预算就是用来抵御这种风险的。分析对比威胁列表确定的需求及可用储备，有助于确定备用预算使用的优先顺序。

3.强烈关注需求渐增

“需求渐增”是用于描述项目实施过程中需求细微增加的术语。在开发过程中需求集合的尺度会出现持续增长的趋势，这种趋势导致系统比预期的更为昂贵和复杂。通常来说，这种变化并不是有意为之，并且从表面来看，这些变化似乎的确使系统性能得到了提升。

然而，在技术需求定义流程中某些需求渐增中可能包含实际上并不存在的新需求，事先也无法做出预测。这些新需求是演化的结果，并且在构建系统的过程中，这些需求不能忽略。

避免或者尽量减少需求渐增现象的几项技术如下：

·在需求定义阶段的早期，列出可能已经注意到而未被陈述的、未察觉的，甚至难以想象的需求。

·建立严格的需求变更评估流程，作为技术状态管理的一部分。

·为递交变更申请设立官方渠道，这将明确谁有权生成变更请求并将其正式提交给技术状态控制部门（例如合同指定的代表、项目技术负责人、客户/研究团队领导、用户等）。

·度量每个需求变更请求的功能性并评估变更对系统其他部分的影响。比较这些影响与变更未被批准后的结果差异，如果不批准变更，会有什么风险？

·确定变更提议能否在财务及技术资源预算内被容纳。如果在资源余量内不能满足变更的需求，则变更就很有可能被拒绝。

4.反馈到需求控制基线

在系统组件的开发过程中，需要不断向需求基线提供反馈。这种反馈通常在产品设计、确认及验证流程中产生。这些反馈包括影响系统的接口及运行使用的设计实施问题。在许多情况下，产品设计可能会对组件如何运行、维护及存储带来一些约束。这种信息需要与项目团队交流，以便评估其对系统运行使用或架构设计的影响。每个系统组件都对自身的设计和运行使用做优化，而系统工程师的作用就是评估这种组件级的自身优化对整个系统带来的影响。

四、需求变更控制

1.变更利弊的评估

对项目方而言，变更需求通常意味着要调整资源、重新分配任务，并修改前期工作成果，有时要付出较大代价。如果随意变更需求，则项目永远不能按时完成。为此，需求变更必须遵守利大于弊的原则。为避免出现失控等风险，对纳入基线以前的需求文档，可通过正常的check-in和check-out进行更改。而纳入基线以后的需求文档，更需按照预定的变更控制规程，确保进行快速、顺利和有序的变更。

对变更进行充分评估十分重要，以确定其对架构、设计、接口、运行使用构想及高层和低层需求的影响。进行功能分析和敏感性分析，可以确保需求切合实际并均匀分配。严苛的需求验证与确认过程可确保需求能够满足并且符合使命任务目标。所有的需求变更必须经过评审和审批，以维持可追溯性并确保其对系统所有部件的影响被完全评估。系统工程师、项目负责人及其他关键工程师通常参与技术状态控制部门的审批流程，评估需求变更对成本、性能、流程及安全性方面的影响。

一旦完成需求确认并经过系统需求评审流程，需求即被置于正式技术状态控制之下。技术团队还应该确保及时地与相关人员交流经批准的需求。每一个项目都应该建立追踪和传递最新项目信息的机制。

2.需求变更的流程

对需求变更要进行控制，严格防止因失控而导致的项目混乱，避免出现重大风险。需求变更通常按“变更申请审批更改重新确认”的流程进行，如14-2所示。

图14-2　需求变更流程

（1）变更申请

此时的状态为“请求变更”。首先由申请人提交需求变更申请书，其内容主要如下。

·变更源类型：指引起变更的原因类型，可分为需求变更、设计变更、制造变更、文档优化和计划变更等。

·变更优先级：依据变更的重要性、紧迫性和对关键业务的影响程度，以及对系统安全性和稳定性的影响程度，可分为critical、high、middle和low等4级。

·变更标志：分为新增、修改和删除。

·变更影响分析：包括变更影响的工作产品和负责人，对工作量和进度的影响，发生风险的可能性与影响程度，以及需要回测的范围。

·可能影响的工作产品：项目计划、需求文档、概要设计文档、详细设计文档、试制产品、测试计划和测试用例以及用户文档。

上述申请书应由项目经理进行评估，其内容如下。

·该需求变更在技术上是否可行。

·需求变更对工期、成本、质量的影响。首先评估单个设备对工期的影响，即实现该需求变更需要的成本和工作量；然后评估实现该需求变更对整体工期、工作量和成本的影响。

（2）变更审批

按照影响的大小由不同的负责人审批：

·对影响小的变更，由项目经理直接审批。

·对影响大的变更，提交变更控制委员会（CCB）审批。

·项目变更委员会仍无法决定的变更，再提交高层变更委员会决定。

如果审批请求未通过，则该变更请求结束。

（3）变更修改

如果需求变更已审批通过，应指定相关的责任人对系统（产品）进行修改，并指定人员对更改后的系统进行审核。还应在系统列表中记录具体修改的系统名称、修改描述和是否完成修改的状态，具体如下：

·应及时更新相应的需求大纲和需求分析说明。

·如果影响项目计划内容，则修改项目计划，以反映需求变更。

·如果影响到概要设计文档、详细设计文档、试制的产品、测试计划、测试用例或者用户文档，则也需要对它们及时更新。

·如果对文档进行修改，需在修改历史表格中注明修改人、修改时间以及修改原因。

·如果对原文件修改过大，必要的话，项目经理可以重新组织工作产品的评审。

（4）变更关闭

如果修改后不需要进行测试，则当所有产品全部修改完成时，由最后完成修改的人关闭该变更。如果变更修改后需要测试，则由测试人员负责决定该变更是否最后关闭：

·如果测试未通过，则返回修改者继续修改。

·如果所有工作产品全部修改完成，并且测试通过，关闭该变更。

3.需求变更的数据项

为了确切记录需求变化，还需登记如表14-1所示的变更数据列表。

表14-1　需求变更登记表

五、需求管理工具

通过需求管理工具可以构建需求模型，解决传统的基于文件的系统工程中存在的问题，最终形成以需求为牵引的系统（产品）研发流程。在系统规模较小的时候，人们采用文档文件的方式来存储系统需求规格说明书和其他文档。但是，随着系统越来越复杂，系统规模也越来越庞大。这时传统的基于文档存储需求的方式越来越显露出局限性，主要体现在：

·传统的基于文件的系统工程需求信息散落在各个文件中，手工维护大量文档文件十分困难，难以查找共享。

·需求采用大段的文本描述，容易造成理解歧义，且很难保持文档与现实一致，达成共识的工作量巨大。

·需求文档版本多，通知受变更影响的设计人员是手工过程，技术状态不容易控制，需求跟踪管理的效率低下，甚至难以跟踪。

·不太容易做到为每一个需求保存附加信息，很难在功能需求与相应的用例、设计、制造、测试、项目任务之间建立联系链。

·文档规模大、内容多、评审困难，问题不易被发现。

·重方案、轻需求，研发流程不是被需求牵引，这使得产品与需求不符。

·异地协作开发变得很困难。

随着系统工程技术的发展，需求管理的任务越来越繁重，迫切需要研制需求管理工具来自动化地管理需求，提高工作效率。

需求管理工具需要从三个实践出发，解决目前需求管理领域存在的困境。

·解决用户需求分类：客户在需求定义过程中，可通过需求属性进行分类与查询。同时工具应通过用户的分类要求实现对需求的规范与整理，并可实现需求文档生成，满足用户对不同需求方的需求分发与管理。

·解决用户需求重用：随着用户项目的增加，需求也随之增多。在需求撰写过程中，可通过搜索和查询手段进行过滤。在需求库中查找可重用的需求条目，快速组合以形成新的需求文档。

·解决用户需求追踪：传统型号或项目的需求管理过程复杂而繁琐，工具应提供型号全范围的各类需求及文档的跟踪与追溯，用户可自定义各级需求追踪矩阵，同时满足项目管理和CMMI（GJB 5000A）过级、复检需要。

需求管理工具应提供如下功能（见图14-3）：

·需求定义：支持需求文档的结构规划、版本控制、需求条目定义等。

·需求关联：支持实现需求文档依赖（关联）、需求条目关联等。

·需求跟踪：支持实现需求文档追踪、需求条目追踪、提供需求跟踪矩阵。

·需求变更：支持实现需求变更单定义、变更内容与变更单关联，形成针对各个管理层级的需求变更影响分析报告。

·系统管理：实现权限配置和管理，满足用户管理和三员分离管理要求。

图14-3　需求管理工具的功能模块

• 上一篇：竞品分析包括哪些内容？竞品分析五大维度是什么？
• 下一篇：需求管理中的GAPS落差工具；