需求管理理论知识及需求管理工具介绍

需求管理理论知识及需求管理工具介绍Marco Lee2012-09-04目录一、需求有关概念综述 (3)1）需求定义 (3)2）需求分析概述 (3)3）需求分析主要过程 (4)4）需求分析的特点 (4)5）需求开发的十种常用方法 (5)6）需求建模方法 (5)7）主要概念区分 (5)二、CMMI需求开发过程 (6)1）基本概念 (6)2）需求调查方法 (7)3）CMMI需求分析过程 (8)三、需求管理工具介绍 (11)1）Rational RequisitePro (11)2）IBM Rational DOORS (11)3）Borland CaliberRM (13)4）Cloudtopo Topo (13)摘要需求是研发团队工作的起点，很多研发团队的开发过程混乱的源头都在于需求管理没有做好。

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

一、需求有关概念综述图 1-需求分析组成部分1）需求定义通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。

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

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、结构化需求分析方法2、面向对象的需求分析方法3、面向问题域的需求分析方法面向问题域(Problem Domain，PD) 的需求分析方法(Problem Domain-Oriented Analysis，PDOA) 是由M·Jackson和P.Zave等人提出的一种需求分析方法。

与传统的结构化需求分析方法和面向对象需求分析方法相比显著不同，其本质在于从待求解问题的角度，考虑待开发的软件系统将在与待求解问题相关的域内产生的效果。

7）主要概念区分项目范围管理，包括为成功完成项目所需要的一系列过程，以确保项目包含且仅仅只包含项目所必须完成的工作。

范围管理首先要定义和控制在项目内包括什么、不包括什么。

一般来说，范围分为产品范围和项目范围。

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

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

项目范围是否完成以项目管理计划作为衡量标准，而产品范围是否完成以产品需求作为衡量标准。

两种范围管理需要很好地集成起来，以确保项目工作能产生所规定的产品并准时交付。

需求开发、需求管理、项目范围管理的区别和联系主要如下：1)首先通过需求开发来获取项目的需求, 在此基础上确定项目的范围，进行项目范围管理。

2)对于项目需求, 可以根据需求的紧急重要程度、项目本身和项目双方的实际情况，分步或分期满足。

确定每期应满足的需求后，本期的范围管理就有了基础。

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

二、CMMI需求开发过程1）基本概念CMMI提出了RD，要理解好RD PA (Process Area, 过程域) ，需要先理解清楚以下几个关键的概念：•客户需求(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讲述的是需求分析和确认的过程。

三、需求管理工具介绍1）Rational RequisiteProIBM Rational RequisitePro 是一个强大、易用、集成的需求管理产品。

而通过与Rational系列软件产品的广泛集成，大大扩展了RequisitePro及其它产品的功能，给软件工程生命周期内的各个阶段都提供了强大、方便的信息查询、跟踪、管理功能。

从而能够促进更好的团队沟通、帮助管理变更和评估变更的影响，帮助验证所有的规划需求被交付物所满足、降低项目风险。

Rational RequisitePro helps project teams to manage their requirements, to write good use cases, to improve traceability, to strengthen collaboration, to reduce project rework, and to increase quality.•Avoid rework and duplication using advanced, real-time integration with Microsoft® Word•Manage complexity with detailed traceability views that display parent/child relationships•Mitigate project risk with display of requirements that may be affected by upstream or downstream changes of requirements•Achieve collaboration for geographically distributed teams through fully functional, scalable Web interface and discussion threads •Capture and analyze requirements information with detailed attribute customization and filtering•Improve productivity by tracking changes using project version comparisons with XML-based project baselines•Align business goals and objectives with project deliverables though integration with multiple tools in the IBM Rational software developmentand delivery platform•Operating systems supported: Windows family2）IBM Rational DOORSIBM Rational DOORS前身是大名鼎鼎的Telelogic DOORS，被IBM收购后更名为IBM Rational DOORS。