摘要

需求是研发团队工作的起点，很多研发团队的开发过程混乱的源头都在于需求管理没有做好。项目失败或严重超支的八个最重要原因中有五个都与需求相关：

1)    不完整的需求；

2)    缺乏用户的参与；

3)    不实际的客户期望；

4)    需求和需求规格说明的变更；

5)    提供许多不必要的功能。

本文就有关需要的概念以及主流需求管理系统，进行了论述。

一、需求工程综述

图1-需求分析组成部分

1）需求定义

通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。

按CMMI软件能力成熟度的定义，需求是开发方和客户方就系统未来所达到的功能和质量所达成的一致约定和协议。

PMP定义，需求是指发起人、客户和其它干系人的已量化且记录下来的需要与期望。收集需求旨在定义和管理客户期望。

2）需求工程概述

需求工程过程——即需求分析活动，以下统称为需求工程——在整个系统开发与维护过程中越来越重要，它贯穿于系统开发的整个生存周期。上个世纪80年代中期，形成了软件工程的子领域——需求工程 (Requirement Engineering, RE)。

需求工程，是应用已证实有效的技术、方法进行需求分析，确定需求客户，帮助系统开发分析人员理解问题，评估可行性，协商合理的解决方案、无歧义地规约方案、确认规约以及将规约转换到可运行的系统时的管理要求。

需求工程通过合适的工具和符号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

需求工程是一个项目的开端，也是项目建设的基石。需求工程的过程包括了需求开发和需求管理两个部分。整体需求工程过程在项目启动后开始，进行需求获取、分析、规划定义和需求验证，并进行组织内外的需求评审，以确定需求基线，并在需求发生变更时，重新进行需求的获取、分析、定义和验证评审，并对需求变更影响项进行相关识别、风险应对、修改和跟踪，并对需求状态和变化过程进行统计分析和测量汇报。

需求开发（RD，Requirement Development）指的是从问题收集、分析和评价到编写文档、评审等一系列产生需求的活动，这几个阶段的活动可以是相互独立和反复的，不一定非要遵循线性的顺序。需求开发讲究的是用系统的方法获取真正的全面的能实现的需求。

需求管理（RM, Requirement Management）则是与需求直接相关的活动，即软件项目开发过程中控制和维持需求约定的活动，主要包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。需求管理强调的是需求的确认以及需求变更的控制，其目的是确保各方对需求的一致理解，管理和控制需求的变更，从需求到最终产品的双向跟踪。

3）需求工程主要过程

1）需求开发规程：分为需求获取、需求分析、规格化定义和需求验证等操作过程。

 2）需求评审规程：对完成的系统需求进行组织内外评审的过程；

 3）需求变更管理规程：需求基线产生后对需求进行变更管理的过程；

 4）需求跟踪管理规程：对需求进行状态跟踪和过程跟踪的管理过程；

 5）需求的测量和分析：对需求状态和需求变化过程进行测量和分析评估的管理过程；

4）需求分析的特点

需求分析工作的复杂性及面临的潜在风险主要体现在以下方面：

1)    需求描述的准确性问题;

2)    需求的完备程度问题;

3)    需求开发的时间问题;

4)    需求的细化程度问题;

5)    需求的变更问题。

5）需求开发的十种常用方法

1)    需求调查：采用需求调查表进行需求收集和调查；

2)    需求访谈：进行面对面的需求访谈、记录、整理并确认；

3)    资料收集和文档考古：收集业主方的有关资料进行分析提炼；

4)    需求研讨：召开需求研讨会有目的的对需求进行研讨；

5)    需求头脑风暴：发散式的对需求进行遐想和探索；

6)    需求原型：依据需求原型进行需求沟通和探索，是电子政务行业常用的需求开发方法；

7)    实地学习：实地深入业主方业务现场进行观摩学习，以提炼需求；

8)    实务跟踪/实地工作：更加深入的跟踪现场多个实物，甚至深入业主方现场进行实地、实务长时间、多案例的实地工作；

9)    案例讲述和故事板：通过对案例或故事的讲解和分析获取需求；

10)  场景模拟/角色扮演：通过模拟一个场景或者由不同人员扮演不同的角色进行需求模拟和角色分析，来获取需求。

6）需求建模方法

需求建模是软件需求工程过程的重要阶段。不同的需求建模方法蕴含了不同的建模理念，代表了看待软件系统的不同视角。

1、  结构化需求分析方法

自20 世纪70 年代中期以来，结构化的需求建模方法一直是比较流行和普及的需求建模技术之一。它认为系统的功能就是“数据”流经系统时发生变迁的能力，同时需要外部事件触发进行完成变迁的过程。

2、  面向对象的需求分析方法

面向对象的需求建模方法是当今工业界的主流方法，它认为现实系统是由各种各样的现实“对象”组成，对象可以被分类、被描述、被组织、被操作、被创建，系统是要实现对现实世界实体(对象)的计算，需要在系统中建立这些实体的映像，这些实体的个体操作模型和交互模型就是系统的功能模型。面向对象的需求建模方法的关键是从获取的需求信息中识别出问题域中的类与对象，并分析它们之间的关系，最终建立起简洁、精确和易理解的需求模型。UML是随着面向对象方法发展起来的统一建模语言，包括用来表示系统静态结构的用例图、类图等，以及表示系统动态结构的状态图、活动图、序列图、协作图和配置图等。

3、面向问题域的需求分析方法

上述两种传统方法都只是针对软件系统本身的建模方法，并没有涉及软件需求从哪里来、客户存在什么问题需要解决、为什么客户会期望或者需要软件来帮助它们解决这些问题、他们需要软件帮他们做什么等问题。20 世纪90 年代之后，提出在进行软件系统建模之前，需要对软件将处于的环境，即软件将要解决的现实世界的问题进行建模，需要对包含软件及其环境的软件加强型系统进行建模，这样才能识别出或者推导出人们对软件的真正需求。

面向问题域(Problem Domain，PD)的需求分析方法 (Problem Domain-Oriented Analysis，PDOA)是由M·Jackson和P.Zave等人提出的一种需求分析方法。与传统的结构化需求分析方法和面向对象需求分析方法相比显著不同，其本质在于从待求解问题的角度，考虑待开发的软件系统将在与待求解问题相关的域内产生的效果。面向问题域建模的核心是问题框架。

问题框架方法认为，软件系统对现实世界的作用是软件问题的来源，对软件系统将与现实世界发生的作用进行结构化分析是需求分析的切入点。问题框架方法强调需要对软件系统将要作用的客观现实世界进行刻画，并将需求的含义指称（映射）到对现实世界相关领域的描述上。其建模的基本概念是现实世界中的领域以及未来软件系统与领域的交互。问题框架方法定义了一些常见的软件问题类型，称为问题框架。问题框架方法的基本思想就是在问题分析中使用问题框架，将复杂的现实世界软件问题结构化为相互作用的可以匹配到问题框架的子问题的集合。

基于问题框架方法进行需求建模，其第1 类概念是现实世界中的领域和未来软件系统与领域的交互。它认为，系统的功能体现在未来软件系统与现实世界领域的交互下产生的对现实世界领域的作用效果。在问题框架方法中，用机器领域显式地表示了要创建的软件系统。用问题领域建模现实世界领域，严格区分了问题领域和机器领域，由此确定了问题的边界，却又不涉及任何关于机器领域的细节描述。由此避免过早进入问题的解决方案。它强调在关注解决方案之前关注问题本身，尽可能地识别出关键的困难并尽早地加以解决。这是它与其他需求工程方法的根本区别。

7）主要概念区分

1、项目范围管理

项目范围管理，包括为成功完成项目所需要的一系列过程，以确保项目包含且仅仅只包含项目所必须完成的工作。范围管理首先要定义和控制在项目内包括什么、不包括什么。一般来说，范围分为产品范围和项目范围：

1)    产品范围是指表示产品或服务的特性和功能。

2)    项目范围是指为了完成具有所规定特征和功能的产品必须完成的工作（需求定义）。

项目范围是否完成以项目管理计划作为衡量标准，而产品范围是否完成以产品需求作为衡量标准。两种范围管理需要很好地集成起来，以确保项目工作能产生所规定的产品并准时交付。

2、需求开发、需求管理、项目范围管理的区别和联系

主要如下：

1)    首先通过需求开发来获取项目的需求, 在此基础上确定项目的范围，进行项目范围管理。

2)    对于项目需求, 可以根据需求的紧急重要程度、项目本身和项目双方的实际情况，分步或分期满足。确定每期应满足的需求后，本期的范围管理就有了基础。

3)    需求管理处理需求的变更，需求的变更同时会引起项目范围的变更。

二、CMMI需求开发过程

1）基本概念

CMMI提出了需求开发--RD，要理解好RD PA (ProcessArea, 过程域)，需要先理解清楚以下几个关键的概念：

∙      客户需求(Customer Requirements)：客户需求可以理解成客户为什么要做本系统，要解决什么问题，客户对系统有怎样的期望，希望能具备一些怎样的特点，简单的说，就是客户的需求是什么（通常会包括对系统目标、范围、解决问题、软件特性、接口要求等有详细的描述）。

∙      产品需求(Product Requirements)：产品需求是能满足客户需求，并对软件产品规格进行了详细描述的需求，软件设计师可以根据产品需求进行设计、编码等工作。

∙      产品组件需求(Product Component Requirements)：产品组件需求是对产品需求的进一步细化，产品可能会分割成几个子系统、几个部分，每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等，这些可以认为是产品组件需求。

图2-需求间的层次关系

从另外一个角度，需求可以分为功能性需求和非功能性需求两类。功能性需求就是系统具备怎样的功能，能做什么事情，而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。软件需求分为三大部分：

∙      功能需求：指系统需要完成那些事情，即向用户提供那些功能。

∙      非功能需求：指产品所具备的品质和属性，比如可靠性、扩展性、响应时间、性能等

∙      设计约束与限制：也称条件约束、补充规则。比如用户要安装该产品他需要有什么样的必备条件。（系统对操作系统的要求、硬件环境的要求等）

客户需求、产品需求和产品组件需求，都会包含功能需求和非功能需求。

2）需求调查方法

需求调查与问题定义，在做需求调查时需要做到2W1H即 What、Where、How

∙      What-----应该收集什么信息

∙       Where----从什么地方收集

∙       How-------用什么机制或技术来收集

客户需求一般都是比较高层次的，而且描述也会比较简单，不能作为日后验收的标准，我们需要对软件的规格进行说明。当我们明确客户需求后，就应该把客户需求转变成产品需求和产品组件需求。而产品和产品组件需求，是比较细致的需求，会详细描述软件与用户是怎样交互的，用户需要输入什么，系统会输出什么等都会比较详细描述出来。客户需求一般是难以验证是否已实现的，而产品需求和产品组件需求是对软件规格的描述，是可以用来做为验收的标准的。

一般来说，我们写的软件规格说明书（SRS,Software Requirement Specification）都会包含产品需求和产品组件需求的。我们导出产品需求和产品组件需求的时候，要注意产品需求和产品组件需求，必须和客户需求对应起来，通常是多对多的关系。为什么要对应起来？我们要保证，软件的每一个界面，每一个功能都是有用的，都是“源自”客户需求的，这样才能保证我们做的事情都是正确的事情，防止被不相干的事情干扰。

我们经常抱怨客户的需求在变，其实80%的原因是没有把握住客户需求，其实客户经常变的是产品需求或者是产品组件需求，客户需求是很少变的，就是因为我们没有把握住客户到底想要什么、需要什么，导致我们认为客户太难“服侍”了。只有把握住客户真正的需求，我们才能抓住根本，万变不离其中。

3）CMMI需求分析过程

CMMI第二级（初始级，管理级，定义级，量化管理级和优化级共5级），即管理级，包含了需求分析等过程。需求开发过程：RD有三个SG（Special Goal），SG1开发客户需求，SG2开发产品需求，SG3分析和确认需求。前两个SG讲述的是需求开发由顶而下、由粗到细的过程，SG3讲述的是需求分析和确认的过程。

SG(特定目标)

SP(特定实践)

干系人的需要、期望、约束和接口要求被收集并转化为客户需求

SP1.1 导出干系人对整个产品生命周期各阶段的需要、期望、约束和接口要求等：要包含了几个要点：

1) 干系人：干系人除了指甲方的领导、系统的最终用户，还包括使用本系统的第三方以及与本系统有交互的第三方系统的拥有者、使用者等。

2) 产品生命周期各阶段：干系人对系统的期望不一定只限于软件功能的，可能还包括数据的整理、资料录入、安装培训、维护要求等，干系人可能对软件生产的过程阶段都会提出他的要求，获取需求的时候，要注意干系人在软件生命周期不同阶段有什么要求。

3) 需要、期望、约束、接口要求：甲方一般会对系统的目标、范围、解决什么问题、希望系统具备怎样的一些特性，满足一些什么接口要求和约束条件等，都会有大致的想法。需求调研工作，首先要注意搞清楚这些内容。

4) 导出：客户的原始想法可能是不明确的，或者是客户一时难表达完整的，我们需要用一定的方法，让客户能完整无遗漏准确地表达出他的想法。通常我们可以通过原型、图示、类比、问卷等办法来导出客户的需求。

SP1.2转化干系人的需要、期望、约束和接口要求为客户需求

上一个SP1.1讲述的是通过一些方法记录客户原始的需求信息，而SP1.2讲述的就是把客户原始的需求信息整理成正式的客户需求，通常会包括对系统目标、范围、解决问题、软件特性、接口要求等有详细的描述。

客户需求是精确和详细的，以用来开发产品需求和产品组件需求

SP 2.1:建立和维护产品和产品组件需求，这些产品和产品组件需求是基于客户需求的

产品和产品组件需求，是比较细致的需求，会详细描述软件与用户是怎样交互的，用户需要输入什么，系统会输出什么等都会比较详细描述出来。而客户需求一般只描述能实现什么功能、解决什么问题等，比较高层次。客户需求一般是难以验证是否已实现的，而产品需求和产品组件需求是对软件规格的描述，是可以用来做为验收的标准的。

SP 2.2:分配需求给每一个产品组件

这个SP将需求开发与技术解决方案联系起来，所有的需求应该与设计的产品组件对应起来，保证需求驱动后续的设计工作，同时也保证设计都是为了需求服务的。SP2.2是对SP2.1的进一步细化。

SP 2.3:定义接口需求

接口需求包括系统与第三方的系统的接口要求，也包括系统本身各组件、各子系统、各部分之间的接口要求。通常这些接口需求在客户需求级别的时候，并不是很明细，需要对客户需求进一步细分成产品需求、产品组件需求，然后发掘出接口需求。SP2.3也是对SP2.1的进一步深化。

需求被分析和确认，并定义出具体的功能性需求

SP 3.1:建立和维护操作场景及相关情景

SP 3.2:建立和维护功能定义

SP3.1和SP3.2是对需求描述的要求，要求描述出具体需求的操作场景、上下文，具体的操作步骤，对功能的详细描述等。通常我们可以通过UML的Use Case图或者是序列图等来表达这些内容。

SP 3.3: 分析需求以确认需求是必须和充分的

SP 3.4:分析需求平衡以平衡干系人的需要和约束

SP3.3和SP3.4是对需求的准确性、全面性、可实现性方面的要求，除了要取得全面准确地需求，还需要平衡约束条件，保证需求在约束条件下是可实现的。

SP 3.5:用各种合适的方法确认需求，确保最终产品能在用户的环境中按照设想运行

这是需求开发的最后一步了，需求导出过程中尽管用了很多办法，但需求确认的时候，仍然需要采取办法确保获取的需求是符合最终的使用场景要求。

SP3.3、SP3.4和SP3.5，通常是通过需求评审来满足的。

三、需求管理工具介绍

1）Rational RequisitePro

IBM Rational RequisitePro 是一个强大、易用、集成的需求管理产品。而通过与Rational系列软件产品的广泛集成，大大扩展了RequisitePro及其它产品的功能，给软件工程生命周期内的各个阶段都提供了强大、方便的信息查询、跟踪、管理功能。从而能够促进更好的团队沟通、帮助管理变更和评估变更的影响，帮助验证所有的规划需求被交付物所满足、降低项目风险。

2）IBM Rational DOORS

IBM Rational DOORS前身是大名鼎鼎的Telelogic DOORS，被IBM收购后更名为IBM Rational DOORS。DOORS 是最老牌的企业需求管理套件，通过使用DOORS/ERS，可以帮助企业更有效地进行沟通并加强协作与验证，从而降低失败的风险。通过对整个组织实施多种需求管理的方法，可以使项目的管理更加透明。它可以使企业跨越地域与组织的边界来按国际化的方式运行。

3）Borland CaliberRM

Borland CaliberRM是一个基于Web 和用于协作的需求定义和管理工具，可以帮助分布式的开发团队平滑协作，从而加速交付应用系统。CaliberRM 辅助团队成员沟通，减少错误和提升项目质量。CaliberRM 有助于更好地理解和控制项目，是Borland 生命周期管理技术暨Borland Suite 中用于定义和设计工作的关键内容，能够帮助团队领先于竞争对手。CaliberRM 提供集中的存储库，能够帮助团队在早期及时澄清项目的需求，当全体成员都能够保持同步，工作的内容很容易具有明确的重点。此外，CaliberRM 和领先的对象建模工具、软件配置管理工具、项目规划工具、分析设计工具以及测试管理工具良好地集成。这种有效的集成有助于更好地理解需求变更对项目规模、预算和进度的影响。

4）Cloudtopo Topo

Topo系统提供了完整的需求管理解决方案，包括需求管理，规格管理以及需求跟踪（需求开发，需求的测试覆盖分析等）功能均提供的非常完善。在Topo系统中，需求管理分为两个部分的内容：需求和规格。Topo的最大特色是它并不仅仅是一个完整的需求管理解决方案，更是提供了从需求到开发到测试的完整研发过程管理解决方案。

• 上一篇：华为需求管理流程
• 下一篇：IPD-PLM 之需求管理