《软件工程实践与项目管理》课件第4章

4.1需求分析的目标

4.2需求分析的任务

4.3需求分析的步骤4.4数据流图

4.5数据字典4.6《需求分析报告》的书写格式4.7需求分析的特性4.8需求管理工具

第4章软件需求分析4.1需求分析的目标软件需求分析的基本目的是确定系统必须完成什么工作，也就是对目标系统提出完整、准确、清晰、具体的要求。软件需求分析建立在软件可行性报告基础上，项目分析员通过与用户密切合作、充分交流、完整准确地理解项目中用户信息及信息的处理过程，详细了解用户需求，最终写出用户认可的需求分析报告。为此，软件需求分析人员应该具备如下能力：

(1)具备系统的硬件和软件的应用能力；

(2)具备良好的书面和口头形式进行讨论和交换意见的沟通能力；

(3)具备“既能看到树木，又能看到森林”的洞察能力。4.2需求分析的任务软件需求分析阶段的任务包括：分析系统的信息和数据要求，确定系统的综合要求，使用数据流图和数据字典导出目标系统的逻辑模型，修正系统开发计划，开发原型系统。

1．分析系统的信息和数据要求

1)分析系统的信息要求系统的信息要求分析主要围绕以下几方面进行：

(1)信息内容和关系。信息内容包括单个数据和控制对象。

(2)信息流。信息流是系统中数据和控制的流向。

(3)信息结构。信息结构指不同的数据和控制项的内部结构。

2)分析数据要求任何一个软件系统本质上都是一个数据处理系统，都包括数据的输入、处理与输出过程，因此，软件需求分析阶段必须考虑数据和数据处理方面的有关问题，即弄清系统涉及哪些数据、数据间的联系、数据性质、数据结构，数据处理的类型、数据处理的逻辑功能等。

2.确定系统的综合要求系统的综合要求包括如下几个方面：

(1)系统功能要求。系统的功能要求是系统最主要的需求，它确定了系统必须完成的功能。

(2)系统性能要求。性能要求包括可靠性、联机系统的响应时间、存储容量、安全性等，应该根据具体系统而定。

(3)系统运行要求。运行要求指系统运行的环境要求，如系统软件、数据库管理系统软件、外存和数据通信接口等。

(4)系统扩充要求。对将来可能提出的系统扩充及修改要求作准备。

3．导出目标系统的逻辑模型在分析完系统的功能需求后，应该建立目标的逻辑模型。逻辑模型的主要任务是建立系统的数据字典、实体关系图(即E-R图)、状态转换图、数据流图。如图4-1所示。图4-1需求分析模型结构图具体分析如下：

(1)数据描述。数据描述主要利用实体关系图(E-R图)和数据字典来描述。

E-R图中的基本图形符号如表4-1所示。表4-1E-R图的基本图形符号及含义现以“课程管理系统”为例，来说明教师、课程、学生之间的实体关系。如图4-2所示。图4-2课程管理系统实体关系图关于数据字典的设计在本章节后面部分将作详细介绍。

(2)控制描述。控制描述主要使用状态转换图来表示。状态图是是用来说明事物的状态、事件和它们之间的关系的。状态图由状态组成，各状态由转移链接在一起。状态是对象执行某项活动或等待某个事件时的条件。关于状态图的设计详细介绍见第6章。

(3)处理描述。处理描述主要使用数据流图和数据字典来表示。关于数据流图的设计也将在本章节后面部分作详细介绍。

4.修正系统开发计划修正系统开发计划是根据分析过程中获得的对软件需求更深入、更具体的认识，对目标系统的成本及进度进行更准确的估算，从而对系统开发计划进一步进行修正。

5.开发原型系统一般地，在一种新产品投产之前，通常先制造一个“样机”，试机成功后再进行批量生产。原型化系统开发思想是从“样机”中借鉴过来的，即在目标系统开发之前，先构造一个原型系统，以便通过较少的投入和较短的时间，让用户尽快感受到目标系统的主要功能，用户也可以通过对原型系统的了解更准确地提出和确定对所开发的软件的要求。4.3需求分析的步骤软件需求分析阶段的工作可以分为以下五个部分：获取项目需求，分析与综合，编制需求分析文档，综合评审，管理需求变更。

1.获取项目需求项目需求包括下面几个方面的内容：

(1)功能需求。功能需求指所开发的目标系统应该完成什么功能，是最主要的需求。

(2)性能需求。性能需求给出目标系统的技术性能指标，包括存储容量限制、响应速度限制等。

(3)环境需求。目标系统运行时对运行环境的要求。例如在硬件方面，对机型、外部设备、数据通信接口等的要求。在软件方面，对支持目标系统运行的系统软件(操作系统、网络软件、数据库管理系统等)的要求。在使用方面，对使用部门的制度及其操作人员的技术水平的要求等。

(4)可靠性需求。不同软件运行时，失效的影响不同。在需求分析时应按实际的运行环境对目标系统运行时发生故障的概率提出要求。对于重要系统，或是运行失效会造成严重后果的系统，应提出较高的可靠性需求。

(5)安全保密需求。不同的用户对系统的安全、保密的要求也不尽相同。应当对用户这方面的需求恰当地作出规定，以便对待开发系统进行特殊的设计，使其满足用户对安全保密性方面的要求。

(6)用户界面需求。如果软件具有友好的用户界面，用户就能够方便、有效、愉快地使用该软件。从市场角度看，具有友好用户界面的软件系统具有较强的竞争力。因此，在需求分析时，必须对细致地规定用户界面应达到的标准。

(7)资源使用需求。这是指目标系统运行时对数据、软件、内存空间等各项资源的要求。另外，软件系统开发时所需要的人力、支撑软件、开发设备等都属于软件开发的资源，需要在需求分析时加以确定。

(8)软件成本消耗与开发进度需求。在软件项目立项后，要根据合同规定，对软件开发的进度和各步骤的费用提出要求，以作为开发管理的依据，并预先估计以后系统可能达到的目标。这样，在开发过程中，可以为系统将来的扩充与修改做好准备。一旦有扩充或修改需要时，就比较容易进行补充和修改。获取项目需求唯一和最好的方法是深入现场(带上录音笔和调研问题列表，见表4-2)，倾听用户对目标系统的要求。系统分析员绝不能坐在办公室凭空想象用户的需求而进行“闭门造车”。表4-2调研问题列表与用户沟通交流的方式有会议、电话、电子邮件、小组讨论、模拟演示(或场景表演)等。与用户的每一次交流都一定要有记录(或录音)，交流的结果还应该进行分类，以便后续的分析活动。例如，可以将需求细分为功能需求、非功能需求(如响应时间、平均无故障工作时间、自动恢复时间等)、环境限制、设计约束等类型。

2.分析与综合分析与综合是需求分析阶段的第二步工作，系统分析员需要从信息流和信息结构出发，逐步细化软件的所有功能，找出系统各元素之间的联系、接口特性和设计上的约束，分析它们是否满足功能要求、是否合理，并依据功能、性能、运行环境等需求，最终制定出系统的解决方案和目标系统的详细逻辑模型。分析与综合工作要反复地进行，直到分析人员与用户双方对系统的解决方案和目标系统的详细逻辑模型都无异议为止。

3.编制需求分析文档对在分析与综合过程中已经确定了的需求应当用文字清晰准确地进行描述，形成需求分析文档。这些文档应作为软件文档存档，需求分析文档通常由以下四部分构成：

(1)软件需求规格说明书：主要描述目标系统的概貌、功能需求、性能需求、数据需求(主要包括数据字典、数据流图等)、运行需求和将来可能的扩充需求。

(2)初步的用户手册：主要包括系统的使用步骤和方法等。

(3)软件开发实施计划。

4.综合评审综合评审是需求分析阶段工作的复查手段，综合评审过程中，要对系统各项需求的正确性、完整性和清晰性给予评价。在需求评审中主要评审以下内容：

(1)设计方案的正确性、先进性和经济性；

(2)系统组成、系统要求及系统内部接口的合理性；

(3)系统外部接口的合理性；

(4)采用的设计准则、规范和标准的合理性；

(5)系统可靠性、可维护性、安全性等要求是否合理；

(6)关键技术的落实情况；

(7)编制的质量保证计划是否可行。

5.需求变更在开发的过程中，需求的变更是不可避免的，软件系统在设计、编码以及测试的任何阶段都可能发生需求变更。如何以可控的方式管理软件的需求变更，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着需求分析过程没有得到充分的执行。所以需求管理要保证需求分析的各个活动都得到了充分的执行，以求得到正确的需求。为了保证软件开发的顺利进行，对软件系统需求的变更要按照流程进行严格管理，如图4-3所示。图4-3需求变更流程首先进行变更发起。变更的发起者可以是用户，也可以是开发方。用户或者开发方在开发过程感到某些地方不满意时，都可以发起变更要求。在考虑是否提出需求变更时，建议遵循如下原则：

(1)减少频繁变更。不要轻易进行需求变更。

(2)处理过程规范化。如果确实需要变更，必须首先写出“变更申请书”书面申请，经过项目组讨论确定之后才可以实施变更。在用户向项目组递交“变更申请书”后，项目组要进行需求变更的影响分析和评价，评价的结果可能是批准，也可能是拒绝“变更申请书”的变更。如果批准变更，有可能要对项目的计划进度或人员等进行相应变更，所以要进行重新计划。最后，是执行相应的变更计划。4.4数据流图数据流图(DataFlowDiagram，DFD)是描述系统的逻辑模型的主要形式。它不涉及硬件、软件、数据结构与文件组织，与系统的物理描述无关，只是用一种图形及与此相关的注释来表示系统的逻辑功能，即所开发的系统在信息处理方面“要做什么”。由于图形描述简明、清晰，不涉及到技术细节，所描述的内容是面向用户的，即使完全不懂信息技术的用户单位的人员也容易理解，因此数据流图是系统分析人员与用户之间进行交流的有效手段，也是系统设计(即建立所开发的系统的物理模型)的主要依据之一。

1．数据流图使用的符号数据流图中有四种基本元素，其符号表示如图4-4所示。符号①描述一个源点或终点，其中注明源点或终点的名称。符号②描述一个变换数据的处理，输入数据在此进行变换产生输出数据，其中需注明处理的名称。符号③描述一个数据存储，通常用于代表一个数据表，其中注明数据表的名称。符号④描述一个数据流，即表示被加工的数据及其流向，流线上注明数据名称，箭头代表数据流动方向。注意，数据流与程序流程图的画法不能混淆。在数据流图中只有“数据源(或称做外部项)、数据处理(或称做加工)、数据存储、数据流”这四种图形元素，不能随意创造任何其他图形符号。一个数据存储并不等同于一个文件，它可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等。数据流由一个或一组确定的数据组成。数据流的表示应该注意以下事项：

(1)数据流名应能直观地反映数据流的含义。

(2)数据流的流向。

(3)数据流可以同名，也可以有相同的数据结构，但不同的数据具有不同的含义。

(4)两个符号(加工、外部项、数据存储)之间可以有多个数据流存在。

(5)避免错误的数据流命名方法。

(6)当数据存储需要重复时，为了避免可能引起的误解，如果代表同一个事物的相同符号在图中出现在n个地方，则在这个符号的一个角上画n-1条短斜线做标记。加工又称处理(亦称变换)，它表示对数据流的操作。加工的符号分成上、下两部分，从上到下分别是标识部分和功能描述部分(见后面的图4-7所示)。标识部分用于标注加工编号，以“P”开头；功能描述部分用来写加工名。数据源点和终点(又称端点)是系统外的实体，称做外部项。它们存在于环境之中，与系统有信息交流，从源点到系统的信息叫系统的输入；从系统到终点的信息称系统的输出。同一个端点可以是人或其他系统。在数据流图中引入源点和终点是为了便于理解系统，所以不需要详细描述它们，但可以有编号。

如果数据源点和终点相同，可以只用一个符号代表数据的源点和终点，这样至少将有两个箭头和这个符号相连(一个进一个出)，如后面的图4-7中的S1。

2．绘制数据流图的步骤绘制数据流图过程示意如图4-5所示。

图4-5绘制数据流图过程示意图具体绘制步骤如下：

(1)确定所开发的系统的外部项(外部实体)，即系统的数据来源和去处。

(2)确定整个系统的输入数据流和输出数据流，把系统作为一个加工环节，画出关联图。

(3)确定系统的主要信息处理功能，按此将整个系统分解成几个加工环节(子系统)确定每个加工的输入与输出数据流以及与这些加工有关的数据存储。

(4)根据自顶向下，逐层分解的原则，对上层图中全部或部分加工环节进行分解。

(5)重复步骤(4)，直到逐层分解结束。

(6)对图进行检查和合理布局，主要检查分解是否恰当、彻底，数据流图中各层是否有遗漏、重复、冲突之处，命名、编号是否确切和合理，对错误与不当之处进行修改。

(7)与用户进行交流，在用户完全理解数据图的内容的基础上征求用户的意见。

3．数据流图举例下面以储户到银行取款的过程为例来分析绘制数据流图的步骤，其过程描述如下：首先储户填好取款单，然后把取款单和存折一起交给银行柜台人员。银行柜台人员做如下处理：

(1)审核存折是否合格，取款金额是否有效，如果不合格或无效，将储户的存折、取款单退回储户。

(2)如果上述两个条件都验证成功，则进行取款并修改账目，然后将存折及现金交给储户，同时将取款单存档。该业务过程的数据流图描述如下：

(1)画出顶层的数据流图—银行取款处理数据流图(如图4-6所示)。图4-6银行取款处理顶层数据流图

(2)逐层分解加工，画出下层数据流图，即取款的第2层数据流图(如图4-7所示)。图4-7取款的第2层数据流图4.5设计数据字典

1．数据字典的内容数据字典一般包括以下五类元素(或条目)。

1)数据流在一个数据流图中，数据以数据流为单位进行传输。其主要内容为：编号：数据流名称：说明(简要介绍作用及其产生的原因和结果)：数据流来源：数据流去向：数据流组成：2)数据元素(数据项)数据元素也称数据项，是数据的最小单位。其主要内容为：编号：数据元素名称：类型：长度：取值范围：数据结构：3)数据存储数据存储是数据保留或保存的地方。其主要内容为：编号：数据存储名称：简述(存放的是什么数据)：输入数据：输出数据：数据存储组成：存储方式(查询、更新、关键码)：4)处理(加工)处理就是一个处理过程，其主要内容为：编号：处理名称：简要描述(功能简述)：输入数据流：输出数据流：处理逻辑(处理算法、处理顺序)：5)外部实体(数据源和数据终点)外部实体是系统的“人—机”界面。数据流由外部实体流入，又从系统向外部实体流出。其主要内容为：编号：外部实体名称：简要描述：从外部实体输入：向外部实体输出：2.举例现以图4-7为例，来设计有关的数据字典。数据字典如下：1)数据流编号：F2数据流名称：存折和现金说明：本数据流是经“取款处理”后的结果数据流来源：取款处理数据流去向：储户数据流组成：存折 = 存折号 + 开户行名称 + 户名 + 交易金额 + 交易日期 + 余额 + 操作人 + 复核人

2)数据存储编号：D1数据存储名称：账目记录简述：主要存储有关账户信息。输入数据：客户取款后更新账务数据。输出数据：用于款项更新、打印和账务查询。数据存储组成：账目数据=操作日期+贷记方+借记方+余额+操作人+复核人3)处理编号：P1处理名称：取款审核简要描述：审核账户是否本行账户、取款金额是否小于存折余额。输入数据流：F1输出数据流：F1.1，F1.24)外部实体(数据源)编号：S1数据源名称：储户简要描述：拿存折和取款单取款。从数据源输入：客户提供取款金额等信息。

3.总结数据流图只描述了系统的“分解”，并没有表达图中的数据、处理等具体含义。对数据流图上各项目含义的不同理解将对以后的开发和维护工作造成不便。数据字典是对数据流图中的所有数据、处理等进行精确定义。数据流图和数据字典共同构成系统的逻辑模型。数据字典是需求分析阶段的工具，数据字典最重要的用途是用户通过它可以清楚地了解分析员对系统数据和处理的详细说明。不同的开发人员或不同的开发小组之间可以通过数据字典对数据的理解达成一致，从而避免定义混乱。数据字典对处理的描述也是很有价值的，如果改变了某个数据的定义，就会对处理产生相应影响。数据字典也是下一步设计的依据，如果所有开发人员都根据数据字典的定义去设计模块，则能避免许多麻烦的接口问题。4.6“需求分析报告”的书写格式下面给出“需求分析报告”的书写格式以供参考。

1．目的和对象阐明编写需求说明书的目的，指明读者对象

2．项目背景描述

(1)项目的委托单位、开发单位和主管部门；

(2)该软件系统与其他系统的关系，描述本项目的适用场合及业务处理情况；

(3)项目名称：本项目的名称，包括项目的全名、简称、代号、版本号；

(4)名词定义：列出文档中用到的专门术语的定义和缩写词的原文，对重要的或是具有特殊意义的名词进行定义；

(5)调研情况介绍：描述主要的调研活动及对象。

3．用户情况

1)用户特点介绍本项目用户(或潜在用户)的情况，包括：

(1)用户的组织结构及职责；

(2)用户的技术水平。

2)业务工作流程

(1)业务工作流程图：画出用户业务流程图；

(2)业务情况描述：描述用户工作中每个业务情境；

(3)用户原有系统的情况：介绍用户现在使用的软件系统的主要功能。

4.任务概述

1)目标阐明本项目所需达到的目的。

2)作用范围以及其他应向读者说明的有关该软件开发的背景解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点即可。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。

5．运行环境

1)硬件环境详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其他特殊设备。

2)软件环境包括操作系统、网络软件、数据库系统以及其他特殊软件要求。

3)条件与限制说明本软件产品在实现时所必须满足的条件和所受的限制，以及相应的原因。必须满足的条件包括输入数据的范围以及格式，所受的限制包括软件环境、硬件环境等方面的内容。

4)主要特点说明本软件产品与同类产品相比的特点，如卖点(仅限于自主产品)。

6．功能需求与功能分析

1)功能划分从用户的角度将产品按功能划分成不同的部分，但这些部分并不对应于最终程序实现时的功能模块。

2)功能描述细化由功能划分所生成的各部分的内容，应包括下列内容：

(1)必须完成的功能以及对此功能的详细描述：按功能类型分类，逐条列出本软件所能完成的各项功能以及对此功能的详细描述；

(2)不支持的功能以及相应的原因：列出本软件所不支持的各项功能以及相应的原因。此部分内容务必详细准确、无二义性，以作为将来验收和测试的标准。用列表的方式逐项定量和定性地叙述对软件所提出的功能要求，说明软件可支持的终端数和可支持的并行操作的用户数。

7．需求分析

1)用户需求用例分析画出业务系统的UML用例图。给出业务的角色和用例对应关系。

2)业务系统的活动图描述业务系统的UML活动图。

3)功能分析从系统分析角度介绍采用什么新技术，采用哪种对策来解决将来出现或可能出现的问题。

(1)按照业务需求或功能特性画出系统结构图；

(2)采用逐步求精方法分解系统功能结构，画出各子系统的功能结构图，并进行文字描述。

8．数据描述

1)静态数据静态数据指长时间不发生改变或临时存储的数据。例如身份证号码等。

2)动态数据动态数据指经常发生改变的数据。

3)外部数据信号、文件、数据库等数据的处理和输入规定。

4)输入/输出数据说明输入/输出数据的类型及格式。

5)数据流图从数据传递和加工的角度描述系统的数据流图(此数据流图不包含任何有关实现的内容，只是从最上层对有关内容加以描述)。

6)数据词典对数据流图中出现所有被命名的图形元素(数据的源点/终点、数据流、数据存储、数据处理)在数据词典中加以定义，使得每一个图形元素的名字都有一个确切的解释。

9．性能需求

1)数据精确度根据实际情况，确定产品最终输出数据(包括传输中)的数据精确度。

2)时间特性说明产品(尤其是交互式产品)在响应时间、更新处理时间、数据转换与传输时间、运行时间等方面所需达到的时间特性。

3)适应性

(1)复用性。说明本产品是否可以复用已有软件或最终产品是否可为其他产品复用。

(2)灵活性。说明在运行环境、与其他软件的接口以及开发计划等发生变化时，具有的适应能力。如：操作方式上的变化，运行环境的变化，同其他软件的接口的变化，精度和有效时限的变化，计划的变化或改进。对于为了提供这些灵活性而进行专门设计的部分应该加以标明。

10．运行需求

1)用户界面说明本产品的人机界面风格。如屏幕格式、报表格式、菜单格式、输入/输出格式等。

2)硬件接口说明该产品与硬件之间各接口的逻辑特点及运行该软件的硬件设备特征。列出运行该软件所需要的硬件设备。说明其中的新型设备及其专门功能，包括：处理器型号及内存容量；外存容量；媒体及其存储格式；设备的型号及数量；输入及输出设备的型号和数量；数据通信设备的型号和数量；其他专用硬件。

3)软件接口列出系统的支撑软件(包括中间件)，列出用到的操作系统、开发环境、数据库和测试软件等。说明该产品与其他软件之间接口，对于涉及到的软件产品应指出规格说明、版本号等。

4)故障处理列出可能出现的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。说明本产品在健壮性方面所能达到的目标。

11．不确定的问题说明目前尚未确定的问题及处理的计划。

12．风险分析说明本项目面临的主要风险。例如：时间进度风险、人力资源风险等。

13．其他需求其他需求如易用性、安全保密性、可维护性、可移植性等。

14．同类产品简介(限自主产品)描述同类产品的特点，如工作流程、运行环境、限制条件等。

15．用户手册提交初步用户操作手册(或软件使用说明书)。

16．编写人员及编写日期列出参与编写的人员的名字及编写日期和版本号等，并标明项目负责人。

17．参考资料

(1)项目经核准的计划任务书、合同或上级机关的批文；

(2)文档所引用的资料、标准和规范等。列出这些资料的作者、标题、编号、发表日期、出版单位等。4.7需求分析的特性编写一个高质量的“需求分析报告”应该具有以下五个特性：

1.正确性每个需求必须精确地描述要交付的功能。需求的正确性取决于是否反映了用户的真正意图。

2.可行性在已知的能力、有限的系统及其环境中，每个需求必须是可实现的。为了避免需求的不可行性，在需求分析阶段必须有技术人员参与。

3.优先级对用户需求进行优先排队，并指出具体的产品版本中优先实现的需求。

4．明确性需求叙述对于多个读者应能达成共识。要避免使用一些对于读者不清楚的主观词汇或形容词，如用户友好性、轻易、简单、快速、有效、几个、艺术级、改善的、最大、最小等。每写一个需求都应简洁、直观，并采用用户熟知的术语，不要采用过于专业的术语或网络语言。

5.可验证性可以使用测试手段验证产品中每个需求是否正确地实现。编写优秀的需求分析报告是没有公式可循的。这里给出编写高质量需求分析报告的建议：

(1)句子和段落要简短。采用主动语气。使用正确的语法、拼写和标点。使用术语要保持一致性，并在术语表或数据字典中定义。

(2)换位思考。要看需求是否被有效定义，要和用户进行换位思考。

(3)需求的细化和合并。努力正确地把握细化程度。可以考虑将多个比较小的需求合并为一个大的需求。

(4)需求中的定义要一致。需求分析报告的术语在定义上要保持一致。4.8需求管理工具需求管理是项目团队工作的起点，很多研发团队开发过程混乱的源头都在于需求管理没有做好。项目需求管理应从需求采集开始，贯于整个项目生命周期，力图实现最终产品同需求的最佳结合。需求管理工具是项目团队工作的利器。考察一个需求管理工具软件，可以从下面几点出发：(1)需求基本信息是否完备。(2)需求的层次组织，即需求本身是如何组织在一起的。(3)需求的评审及权限控制。(4)需求和版本、测试是如何关联的。(5)需求变更的支持。本节介绍几款国内外流行的需求管理工具。它们是IBM公司的RationalRequisitePro、TelelogicDOORS、BorlandCaliberRM、统御需求管理软件oKit四个工具。读者可以根据自己的项目特点来选择使用。4.8.1常用工具介绍1．RationalRequisiteProIBM的RationalRequisitePro解决方案是一种需求和用例管理工具，它能帮助项目团队改进项目目标的沟通，增强协作开发，降低项目风险，并可以在部署前提高应用程序的质量。通过与MicrosoftWord的高级集成，RationalRequisitePro可以为需求的定义和组织提供熟悉的环境。RationalRequisitePro还提供数据库与Word文档的实时同步能力，为需求的组织、集成和分析提供方便；支持需求详细属性的定制和过滤，以最大化各个需求的信息价值；提供了详细的可跟踪性