软件工程 Chap3_软件需求分析.ppt

1、高 级 软件工程,陈宁江 ,2,需求工程概述 需求获取 需求分析和建模 需求验证与管理,本章内容,3,什么是需求（Requirement） ？,需求 用户对目标软件系统在功能、行为、性能、设计约束等方面的期望 IEEE的定义（1997年） 用户解决问题或达到目标所需的条件或能力 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力 反映以上两条的文档说明 软件需求分析的目标： 调查分析，准确理解用户的要求 撰写需求，将用户的非形式的要求转化为完整的、形式的规格说明,4,软件需求分析的任务,5,需求的类型,业务需求（business requirement） 客户对系统的高

2、层次的目标要求。在项目视图与范围文档中予以说明 用户需求（user requirement） 用户使用产品必须要完成的任务 功能需求（functional requirement） 开发人员必须实现的软件功能，使得用户能完成他们的任务，满足业务需求 非功能需求（non-functional requirement ） 对系统提供的服务或者功能提出的约束，包括时间、开发过程、软件质量、标准等约束,6,一个例子,从不同的角度来看，需求具有不同的层次，即业务需求、用户需求、功能需求和非功能需求等 例子：字处理程序 之 “ 拼写检查器” 业务需求：“用户能有效地纠正文档中的拼写错误” 用户需求：“找出

3、文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词” 功能需求：“找到并高亮度提示错词的操作”；“显示提供替换词的对话框”；“实现整个文档范围的替换” 非功能需求：“替换操作执行速度快”；“异常出现概率小”,7,功能需求,对于功能性的系统需求，应需要详细描述系统中的操作功能、输入、输出、异常等 功能需求的描述应做到： 严密性 全面性 一致性,8,非功能需求,与软件系统的总体特性相关，并作用于整个系统；与软件系统的开发过程有关,9,非功能需求的度量,10,软件需求各组成部分之间的关系,11,软件需求的作用,软件开发的基础和前提 只有在明确了软件需求之后才能开展有针对性的软件开发工作

4、没有需求无法进行设计和编码 制定软件开发计划的基础 只有知道你想做什么，才能知道需要多少工作量，才能制定计划 最终目标软件系统验收的标准 只有知道你想做什么，才能知道你最终是否做好了 没有定义明确的需求，就不知道最终基于什么进行验收,12,需求分析的重要性：例子,31,53,9,16,% 的项目被终止！平均超出时间122%,% 的项目超支，平均超支 89%！,% 的项目按期在预算之内完成！ (大公司),%的项目按期在预算之内完成！ (小公司) Standish Group 98 Chaos Report,用户参与不足！,不完整的用户需求！,需求不断变化！,13,需求分析的重要性：例子说明,14

5、,需求分析的重要性：事实支撑（1/4）,软件生命周期中，一个错误发现得越晚，修复错误的费用越高,15,需求分析的重要性：事实支撑（2/4）,许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 在需求过程中会产生很多错误 DeMarco研究报告：被检查出来的错误的56产生的根源可以追溯到需求阶段。,16,需求分析的重要性：事实支撑（3/4）,在需求阶段，代表性的错误为疏忽、不一致和二义性 美国海军研究实验室对海军A-7E飞机上的飞行操作程序进行实地测试，得出的研究数据表明：A-7E项目中77的需求错误特点是不明确：疏忽、不一致和二义性。 按错误类型对这些错误分布进行分析的结果是： 49不

6、正确的事实，31疏忽，l 3不一致，5二义性,17,需求分析的重要性：事实支撑（4/4）,需求错误是可以被检查出来的,18,需求分析的重要性推论,在需求过程中会产生很多错误 许多错误并没有在早期被发现 这样的错误是能够在产生的初期被检查出来的 如果没有及时检查出来这些错误，软件费用会直线上升,19,获取软件需求的复杂性,系统复杂和庞大 如何将软件需求得到？描述清楚？ 片面, 不完全 如何保证得到了所有的软件需求？ 模糊, 不准确 如何保证把需求说清楚和准确？ 不一致, 歧义 如何保证所描述的需求是不矛盾的？ 及时性 当需求变更时，如何让相关人员都知道需求已经变更？ 软件需求变动带来的问题 波动

7、性 放大性,20,需求分析与程序分析的不同,21,需求分析常见问题,误解 交流障碍 缺乏共同语言 “完整性”问题 需求永远不会稳定 用户意见不统一 错误要求 认识混淆,22,案例分析：中源公司的电信软件项目,思考： 为什么需求工作出现了问题？ 在需求出现变更时怎么办？ 如何更好地进行需求管理？下一步可采取什么措施？,23,需求问题的解决方法和手段,技术层面 需求分析方法、技术和工具 方法：数据流、面向对象 技术：抽象、建模、多视点、原型、 工具：UML，Rose，Word，Excel，RequisitePro 管理层面 对需求分析中的人、活动和产品进行管理 形成新的研究领域：需求工程,24,需

8、求工程（Requirement Engineering ）,软件工程的子领域。应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义和管理目标系统的需求,需 求 工 程,需求获取,需求 分析,需求 建模,需求 规约,需求 验证,25,软件需求工程： 需求获取 需求分析与协商 需求建模 需求描述 需求验证 需求管理,需求分析和协商,需求描述,需求验证,系统模型,用户需求和系统需求,需求规约,需求管理,需求获取,需求建模,26,（一）需求获取,系统分析人员通过与用户交流，对现有系统的观察及对任务进行分析： 确定系统或产品范围 与系统或产品有关的人员及特征列表 系统的技术环

9、境的描述 系统功能的列表及应用于每个需求的领域限制 一组描述不同运行条件下系统的应用场景 为更好地定义需求而开发的原型 需求获取工作的产品为进行需求分析提供了基础,27,需求获取方法,工作内容 用耳 聆听用户的需求 用脑 分析和整理所获取的信息 用手 形成文档化的描述 方法 建立顺畅的通信途径 客户访谈和调查 建立联合分析小组， 观察用户操作流程 组成联合小组 及时整理分析，反馈循环 快速原型,28,建立顺畅的通信途径,建立分析所需要的通信途径，以保证能顺利地对问题进行分析。,29,访谈与调查,在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照

10、如下原则进行准备： 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化 不要限制用户对问题的回答，这有可能会引出原先没有注意的问题 提问和回答在汇总后应能够反映用户需求的全貌。,30,需求分析要深入实际,市场调查 了解市场对待开发软件的要求；市场上有无与待开发软件类似的系统及其情况 访问用户和用户领域的专家 考察现场,跟踪现场业务流程 查阅与待开发系统有关的资料,31,例子：“围棋比赛成绩计算系统”的第一次面谈的准备计划,32,观察用户操作流程,到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交

11、的问题陈述，对用户需求可以有更全面、更细致的认识。,33,组成联合小组,便利的应用规约技术(Facilitated Application Specification Techniques , FAST) ： 打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调 鼓励建立客户和系统分析员之间的合作，由他们共同工作来标识问题、提出解决方案的要素、商议不同的方法以及刻画出初步的解决方案需求,加强联系 促进交流 增进合作,34,FAST基本原则,在中立的地点举行由开发者和用户出席的会议； 建立准备和参与会议的规则； 建

12、议一个足够正式的议程以便可以进行自由的交流； 一个“协调者”(他可以是用户、开发者或其他外人)来控制会议； 使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)； 目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。,35,需求收集的注意事项,如果应用规模较大，可分成几个需求调查小组同时进行，最后对结果进行汇总 一定要和用户进行充分的交流，发现问题要及时沟通 要和用户打成一片，建立起良好的合作关系 如果发现多个软件需求相互矛盾，要能找到仲裁人或者决策人 需求调查应遵循先整体后部分、先抽象后具体的原则 帮助用户发现潜在的需求,36,（二）需

13、求分析,需求获取结束后，分析活动对需求进行分类组织，分析每个需求与其它需求的关系，检查需求的一致性、重叠和遗漏的情况，并对需求进行排序 在需求获取阶段，经常出现以下问题： 用户提出的要求超出软件系统可以实现的范围或实现能力 不同的用户提出了相互冲突的需求,37,需求协商,协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案 协商不是简单的逻辑或技术上的争论，要注意组织和行政方面的因素 不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异,38,参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员 会议应该讨论那些非正式讨论不能解决的问题,通常会议

14、是解决冲突最快的方式,39,（三）需求建模,为什么需要对软件需求进行建模？ 需求调查所获取和文档化（文字）的软件需求不能有效地描述软件需求 文字描述的局限性(不准确、二义、歧义、不能直观揭示关联) 不准确 不一致 不全面 .,40,建模技术,建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图 常用的建模方法 面向数据流方法 面向对象的方法,41,结构化分析方法,数据建模的基础，描述数据对象及其关系,功能建模的基础，描述数据怎样转换以及转换的功能,行为建模的基础，表示系统

15、的各种行为状态以及状态间的转换方式,适用于 数据处理类型软件的需求分析,42,数据流图 DFD - Data Flow Diagram,图形化技术，描绘信息流和数据从输入移动到输出的过程中所经受的变换。 在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，是系统逻辑功能的图形表示。 设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能，所以它也是今后进行软件设计的很好的出发点。,43,数据建模：实体关系图（ERD）,数据模型的基本元素 数据对象 描述对象的属性 描述对象间相互连接的关系 数据对象之间的关联 一对一（1:1） 一对多

16、（1:N） 多对多（M:N）,44,数据流图,描述了信息流和数据转换，表达系统内数据的运动情况 系统的功能体现在核心的数据变换中 系统的输入源于用方框表示的外部实体，这种输入引发系统的数据变换，产生传递给外部实体的输出,45,- 系统逻辑模型,46,数据流图的基本组成,47,数据流图的层次结构,为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。 在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据。 底层流图是指其加工不需

17、再做分解的数据流图，它处在最底层。 中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。,48,分层的数据流图,49,对数据流图进行分层,George Miller在著名的论文“神奇的数字7加减2：我们处理信息的能力的某种限制”中指出：人们在一段时间内的短期记忆似乎限制在59件事情之内 根据自顶向下逐层分解的思想将数据流图画成层次结构 每个层次画在独立的数据流图中，加工个数可大致控制在“7加减2”的范围中,50,数据字典,数据字典描述数据流图的数据存储、数据加工（最底层加工）和数据流 数据字典的任务是: 对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，

18、使得每一个图形元素的名字都有一个确切的解释。 数据流图和数据字典共同构成系统的逻辑模型 没有数据字典数据流图就不严格，没有数据流图， 数据字典也难于发挥作用。,51,行为建模,状态迁移图/表 描述系统或对象的状态，以及导致系统或对象的状态改变的事件，从而描述系统的行为,52,（四）需求规约,需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求 需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用,签字不是万能的 但没有签字是万万不能！,53,需求的描述,不宜使用自然语言描述系统需求

19、 原因：理解的二义性，随意性大，难以模块化 书写需求的一些原则 设计一个标准的格式，保证需求定义按格式书写 使用一致的语言 突出显示关键性需求 尽量避免使用计算机专业术语,54,需求描述方法,结构化语言描述 依赖于定义标准格式或模板来表达需求描述 程序描述语言（PDL） 使用一种类似于程序设计语言的语言，但是具有更多抽象特征，通过定义系统的操作模型来定义需求 图形化符号 图形语言辅之以文本注释来定义系统的功能需求 数学描述 基于数学概念的符号 （如有限状态机、集合等）,55,结构化语言描述,56,程序描述语言（PDL）,好处： 可以用软件工具进行语法和语义检查 可检查需求遗漏和不一致 便于描述

20、比较复杂的操作，如循环、选择等 可定义接口 便于实现需求到设计的过渡 缺点： 表达功能的能力不够充分 需要具有程序语言知识的人容易提前进入设计阶段，偏离需求分析的目标,57,图形化符号描述,结构化分析 用例分析,58,需求的描述（续1）,需求说明语句 保持语句和段落的简短 采用主动语态的表达方式 编写具有正确的语法和标点的完整句子 使用的术语应该和词汇表中定义的一致 需求陈述应该具有一致的式样，例如“系统必须”，或者“用户必须”，并紧跟一个行为动作和可观察的结果 例如：“仓库管理子系统必须实现一张在所请求的仓库中有存货的药品名单。”,59,需求的描述（续2）,为了减少不确定性，避免采用模糊的、

21、主观的术语 例如：用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的、健壮的 避免使用比较性的词汇 例如：提高，最大化，最小化和最佳化 定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值,60,例1,“产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于60秒” “后台任务管理器在用户界面的指定区域显示状态消息” 在后台任务进程启动之后，消息必须每隔60（+_10）秒更新一次，并且保持连续的可见性。 如果正在正常处理后台任务进程，那么后台任务管理器必须显示后台任务进程已完成的百分比 当完成后台任务时，后台任务管理器必须显示一个“已完成”的消息。

22、如果后台任务中止执行，那么后台任务管理器必须显示一个出错信息。,61,例2,“分析程序应该能生成HTML标记出错的报告，这样就可以使HTML的初学者使用它来迅速排错” 在HTML分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个报告中包含了在分析文件中所发生错误的HTML所在的行号以及文本内容，还包含了对每个错误的描述。 如果分析过程中未发生任何错误，就不必生成任何错误报告,62,需求说明的质量特性,正确性 完整性 一致性 无二义性 可修改性 可跟踪性 可验证性,63,其它需求分析阶段的文档,初步的用户手册：着重反映目标软件的用户功能界面和用户使用的具体要求。 测试计划 修改和

23、完善软件开发计划,64,（五）需求验证,作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。,65,需求验证方法,需求评审 原型建立 测试用例生成 自动的一致性分析 编写用户手册,66,需求评审,需求审查是需求分析阶段工作的最后一步，是由软件工程师和客户一起进行并完成的 目的是发现软件需求规格说明中的错误、二义性和遗漏的需求 复审首先在宏观的级别上进行，复审者试图保证软件需求规格说明是完整的、一致的、精确的，然后更详细地关注软件需求规格说明中的措词,67,评审实施(1/2),高级管

24、理者定期参与对软件需求管理活动进行的评审 高级管理者参与定期评审的主要目的是在合适的抽象层次上及时地了解和洞察软件过程。 评审间隔时间应该满足组织的需要，如果存在异常情况报告机制，间隔时间可以长些 项目负责人可定期或者事件驱动地参与对软件需求管理活动的评审,68,评审实施(2/2),软件质量保证组对软件需求管理活动和工作产品进行评审和(或)审计，并报告其结果 软件需求已评审，且有关问题在软件工程组开发软件之前已得到解决 当软件需求更动时，软件计划、工作产品和活动已经适当地更动 由软件需求的更动所导致的对承诺的更动已与受影响组进行协商,69,评审人员往往需要检查以下内容：,系统定义的目标是否与用

25、户的要求一致； 系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求 被开发项目的数据流与数据结构是否确定且充足 主要功能是否已包括在规定的软件范围之内，是否都已充分说明 设计的约束条件或限制条件是否符合实际 开发的技术风险是什么 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认,70,小结1：需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的,领域了解,需求收集,需求描述,需求文档,过程入口,分类,冲突解决,优先排序,需求检查,(1),(2),(3),(4),(5),(6),(7),(8),(9),(10),(11),

26、(12),(13),(14),(15),71,小结2：软件需求分析人员应该具备的素质,善于领会一些抽象的概念，重新整理使之成为各种逻辑成分，并根据各种逻辑成分综合出问题的解决办法 善于从各种相互冲突或混淆的原始资料中吸取恰当的论据 能够理解用户的环境及领域知识 具备把系统的硬件和软件部分应用于用户环境的能力 具备良好的书面和口头形式进行讨论和交换意见的能力 具有“既能看到树木，又能看到森林”的能力,72,（六）需求管理,为什么要需求管理？ 软件需求肯定是不完全的 需求变动，软件演化 需求管理是对系统需求变更了解和控制的过程，是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动

27、 从演化的角度看，需求分为： 持久的需求 易变的需求,73,需求管理常见的问题,软件开发所基于的需求往往 不完整 不准确 模棱两可 需求定义没有生成文档，或文档未及时更新 即使已采用一个个孤立的文档来管理需求，但是 文档散布各处，没人知道哪个是最新版本 文档对信息分析、优先级别划分和跟踪效率不高 很难从需求文档中提取与项目有关的状态信息 对需求没有达成共识 随着情况的改变需求产生变更，但无法有效地管理和跟踪,74,导致问题的原因,缺乏用户参与 忽略了用户分类 在需求阶段，项目的范围尚未很好的定义 忽视了运行、操作、法规等方面的约束 “张三”不知道怎么写需求说明 对需求过程不够了解 管理层不重视

28、 开发过程中修补原始需求的缺陷 不可控制的外因,75,需求管理的内容,76,需求管理的方法,确定需求变更控制过程 进行需求变更影响分析 维护需求变更的历史记录 建立需求基准版本和需求控制版本文档 跟踪每项需求的状态 衡量需求稳定性,77,需求变更管理,问题分析和 变更描述,变更分析和 成本计算,识别出的问题,修正后的需求,变更实现,需求变更管理的要求 仔细评估已建议的变更 制定合适的变更处理 变更及时通知所有涉及的人员,78,控制需求的变更(1/3),需求变更不可避免 软件需求本身是变化的 在需求分析阶段对软件需求的描述和分析不全面、不准确等 需求变更对软件项目的开发会产生巨大的影响 产品功能

29、 开发成本 开发进度 产品质量,79,控制需求的变更(2/3),需求变更的权衡，需要和用户协商，并对计划进行变更,80,控制需求的变更(3/3),如何控制需求的变更 提出软件需求变更请求 对软件需求变更进行评审 变更软件需求说明书（SRS） 将变更后的SRS纳入配置 通知受影响小组和人员 变更其他产品(软件设计文档、测试文档)和计划(软件开发计划),81,8 .3 软件需求的变更控制,需求变更处理流程,82,需求文档的版本控制,统一确定版本 变更必须文档化，及时通知有关人员 指定专人更新需求 文档应包括版本修正历史 需求管理工具的数据库存储需求 使用专门的版本管理工具及数据库,83,需求跟踪,

30、当某项业务需求发生变化时，可能会影响到系统需求和功能需求的变化，并且连带地影响到设计、测试、实现、项目计划等各方面的变化 需求跟踪：应编制每个需求同系统元素之间的联系文档,84,需求跟踪的方式,正向跟踪： 以用户需求为切入点，检查需求规约中的每个需求是否都能在后继工作产品中找到对应点 逆向跟踪： 检查设计文档、代码、测试用况等工作产品是否都能在需求规约中找到出处,85,需求跟踪能力矩阵,例子： 大量的需求跟踪信息可以使用特定的工具进行管理,86,小结：需求阶段的常见问题,需求的沟通与理解 缺乏足够的用户参与 添加不必要的特性 忽略了用户分类 需求的变化与控制 用户需求不断增加 需求说明的明确与

31、完整 需求模棱两可 需求说明过于简单,87,CMM对需求管理的要求(1/3),需求管理是CMM 2级的一个关键过程域 CMM对需求管理的理解和定义 需求管理是指在用户和将处理“分配给软件的系统需求”的软件项目组之间建立对“分配给软件的系统需求”的共同理解，由软件工程组对“分配给软件的系统需求”进行分析、精化，按照规范详细描述“分配给软件的系统需求”，形成“软件需求规格说明”文档，并对该文档进行评审,88,确保需求管理的必备条件(1/4),建立和明确系统需求分析和分配的人员及其职责 ，明确： 在整个项目生存期内，管理和分配系统需求，并将它们写成文档 实施对系统需求及其分配的更动，当系统需求发生更

32、动时，应及时更动软件需求,89,确保需求管理的必备条件(2/4),将软件需求规范化 技术需求，如软件功能、性能、设计约束、编程语言、界面需求 非技术性需求(即协议、条件、和(或)合同条款),包括：要交付的产品、交付日期、里程碑等 用于确认软件产品满足软件需求的验收准则,90,确保需求管理的必备条件(3/4),提供足够的用以管理分配需求的资源和经费 指派在应用领域和软件工程方面有经验和技能的个人去管理软件需求 提供可用的、能支持软件需求管理活动的工具 电子表格程序 配置管理工具 跟踪工具 测试管理工具,91,确保需求管理的必备条件(4/4),软件工程组和其它受影响组的人员接受需求管理方面的培训，

33、如： 项目所使用的方法、标准和规程 应用领域知识,92,需求管理活动的度量,进行度量，并将度量结果用以确定软件需求管理活动的状态，度量内容包括： 每个软件需求的状态（确认并批准、问题等） 关于软件需求的更动活动 对用软件需求更动的累积数，包括建议的、未解决的、已批准的并已纳入系统基线的软件需求更动的总数,93,需求管理CASE工具,回顾：项目成功有赖于“需求管理” 高效的需求管理 沟通：收集和分析不同类型的需求信息 协同：能在整个项目过程中建立相关需求的链接和跟踪 验证：通过将工作严格限制在已定义的需求之内来控制项目范围和项目成本 动态的需求管理 保持对持续发生变更的受控状态，并能透明地看到变

34、更的潜在影响 允许需求规约能随项目的进展而改变，同时不失项目控制力 适应现代公司管理理念的方法,94,需求管理工具关注的问题,需求开发方面 如何方便的收集业务部门需求 如何准确理解业务部门所要解决的问题 如何准确的描述需求 需求管理方面 如何对需求进行量化管理和统计分析，包括方便的查询、排序等 如何实现需求的可追踪性，并有效追踪需求的变更所造成的影响 需求变更方面 如何有效管理用户的变更请求,95,常见需求管理工具,RequestPro DOORS CaliberRM,96,IBM Rational需求管理解决方案的构成,方法论统一软件开发过程 RUP 管理流程RUP需求管理规程 工具Requ

35、isitePro，ClearQuest（可选）,97,需求开发方面 使用ClearQuest方便收集客户需求 使用用例模型和文档的有机结合，准确的描述需求 需求管理方面 RequisitePro提供统一整个团队的需求管理平台 在RequisitePro中使用属性描述需求，实现需求的量化管理和分析 使用RequisitePro的追踪矩阵，实现需求的可追踪性，有效追踪需求的变更所造成的影响 变更管理方面 使用ClearQuest变更管理平台，建立标准的需求变更管理流程，有效管理用户的变更请求,IBM Rational需求管理解决方案,98,所有人都能方便地访问需求,“RequisitePro 把我们的项目团队