软件过程管理(5)课件.ppt

1、 chapter_0承上启下承上启下q项目合同管理q生存期模型 chapter_1RoadMapRoadMap合同管理合同管理 生存期生存期 需求管理需求管理 任务分解任务分解项目进度项目进度规模估算规模估算质量计划质量计划 配置计划配置计划风险计划风险计划团队管理团队管理项目度量项目度量集成项目集成项目跟踪控制跟踪控制 项目结束项目结束 chapter_2软件开发项目管理软件开发项目管理第四章第四章软件项目需求管理软件项目需求管理 chapter_3需求管理中的问题举例需求管理中的问题举例q需求的隐含错误q需求不明确、含糊q用户不断增加需求、变更需求q用户刁难q开发人员的镀金 chapter

2、_4镀金（镀金（gold plating）的定义）的定义 给予用户的东西要多于他们所要求的。给予用户的东西要多于他们所要求的。事实上，额外的特性、扩展的功能、事实上，额外的特性、扩展的功能、更好的组件以及其他等等，通常都不会更好的组件以及其他等等，通常都不会为项目增加什么价值。实际上，镀金常为项目增加什么价值。实际上，镀金常常会增加项目的开支，因为这需要更多常会增加项目的开支，因为这需要更多的资源、更长的开发周期，还会增加重的资源、更长的开发周期，还会增加重新设计的风险、耽误项目的交付使用。新设计的风险、耽误项目的交付使用。chapter_5镀金案例镀金案例n在检视项目要求的时候，你发现了在检

3、视项目要求的时候，你发现了一个需要创建软件模块的要求。这一个需要创建软件模块的要求。这个模块允许用户在浏览应用程序的个模块允许用户在浏览应用程序的时候，在屏幕上维持其所喜好的颜时候，在屏幕上维持其所喜好的颜色和字体样式。在更进一步检视的色和字体样式。在更进一步检视的时候，你意识到这个模块的加入虽时候，你意识到这个模块的加入虽然很好，但是不会为整个项目增添然很好，但是不会为整个项目增添什么价值。什么价值。chapter_6如何确定项目里是否包含有镀金的内容如何确定项目里是否包含有镀金的内容要验证开发要求或者任务里是否包含要验证开发要求或者任务里是否包含有镀金内容的一种方法是：思考一下有镀金内容的

4、一种方法是：思考一下如果项目没有包含这个模块的话，其如果项目没有包含这个模块的话，其影响会是什么。问问你自己：如果这影响会是什么。问问你自己：如果这个项目没有包含这个模块，这个应用个项目没有包含这个模块，这个应用程序的可靠性、效率是否会更低，或程序的可靠性、效率是否会更低，或者根本就不会有任何降低。者根本就不会有任何降低。chapter_7本章要点本章要点q一、软件需求定义一、软件需求定义q二、软件需求管理过程q三、需求建模的基本方法q四、案例分析软件需求定义软件需求定义 chapter_9软件需求软件需求q需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，

5、达到什么性能。chapter_10软件需求的层次软件需求的层次业 务需求用 户需求功 能需求软 件 需 求 规格非功能性需求质量特性约束和假设系 统需求 chapter_111业务需求（业务需求（business requirement）反映了组织机）反映了组织机构或客户对系统、产品高层次的目标要求，它们构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明在项目视图与范围文档中予以说明 2用户需求用户需求(user requirement)文档描述了用户使文档描述了用户使用产品必须要完成的任务，这在使用实例（用产品必须要完成的任务，这在使用实例（use case）文档或方案

6、脚本说明中予以说明。）文档或方案脚本说明中予以说明。3功能需求功能需求(functional requirement)定义了开发人员定义了开发人员必须实现的软件功能，使得用户能完成他们的任必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。务，从而满足了业务需求。在软件需求规格说明书在软件需求规格说明书（SRS）中说明的功能需）中说明的功能需求充分描述了软件系统所应具有的外部行为。软求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对管理以及相关项目功能中都起了重要

7、的作用。对一个大型系统来说，软件功能需求也许只是系统一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。（或软件部件）。chapter_12作为功能需求的补充，软件需求规格说明作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的面的具体细节；性能要求；设计或实现的约束条件及

8、质量属性。所谓约束是指对开约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。产品对用户和开发人员都极为重要。chapter_13 以一个字处理程序为例来说明需求的不同种类。业务需求业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。用户需求用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表

9、来供选择替换拼错的词”。同时，该拼写检查器还有许多功功能需求能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。chapter_14功能需求功能需求n功能需求：列举出被开发软件在职能上应做什么。功能需求：列举出被开发软件在职能上应做什么。这是最主要的需求，规定开发人员必须在产品中这是最主要的需求，规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，实现的软件功能，用户利用这些功能来完成任务，满足业务需求。满足业务需求。n通常功能性需求是：通常功能性需求是：u 产品功能的规格说明；产品功能的规格说明；u 产品必须执行的动作；产品必须执行的动作；

10、u 源自于产品的基本目标源自于产品的基本目标n例如：银行例如：银行ATM系统系统 功能性需求：取、存、查、密码检验功能性需求：取、存、查、密码检验 chapter_15非功能需求非功能需求n许多非功能需求关心的是系统整体特性，而不是个别的系统特性。因此非功能需求比功能需求对系统更关键。一个功能需求没有满足可能降低系统的能力，而一个非功能系统需求没有满足则可能使整个系统无法使用。n例如：一个飞机系统不符合可靠性需求，它将不会被批准飞行。若一个实时控制系统无法满足其性能需求，控制功能可能根本无法使用。n例如：银行ATM系统 非功能需求：响应时间，安全保密等 chapter_16需求管理的重要性需求

11、管理的重要性 chapter_17项目项目失败的原因分析失败的原因分析No.Top 10 Factors 平均值平均值 1 Inadequate requirements specification 不充分的需求规范不充分的需求规范 4.5 2 Changes in requirements 需求的改变需求的改变 4.3 3 Shortage of systems engineers 缺乏系统工程师缺乏系统工程师 4.2 4 Shortage of software managers 缺乏了解软件特性的经理人缺乏了解软件特性的经理人 4.1 5 Shortage of qualified pr

12、oject managers 缺乏合格的缺乏合格的项目经理项目经理 4.1 6 Shortage of software engineers 缺乏软件工程师缺乏软件工程师 3.9 7 Fixed-price contract 固定价合同固定价合同 3.8 8 Inadequate communications for system integration 系统集成阶段系统集成阶段,交流与沟通不充分交流与沟通不充分 3.8 9 Insufficient experience as team团队缺乏经团队缺乏经验验 3.6 10 Shortage of application domain exp

13、erts 缺乏应用领域专家缺乏应用领域专家 3.6 Scale:5=Very Serious 3=Serious 1=No Serious Source:Carnegie-Mellon University,Software Engineering Institute chapter_18本章要点本章要点q一、软件需求定义q二、软件需求管理过程二、软件需求管理过程q三、需求建模的基本方法q四、案例分析软件需求管理过程软件需求管理过程 chapter_20软件需求管理的过程软件需求管理的过程需求分析需求分析编写需求规格编写需求规格需求验证需求验证需求获取需求获取需求变更需求变更需求确认需求变更

14、chapter_21需求开发需求开发(确认确认)和管理基本任务和管理基本任务需求工程需求工程需求管理需求管理需求开发需求开发需求获取需求获取需求分析需求分析需求规格说明需求规格说明需求验证需求验证变更管理变更管理版本控制版本控制风险分析风险分析 chapter_22本章要点本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更q三、需求建模的基本方法q四、案例分析 chapter_23需求获取图示需求获取图示 chapter_24需求获取需求获取用户要求 扩展需求基线需求软 件 需求 chapter_25程、硬件环境、软件环境、现有的运行系统等

15、具体情况和客观的信息，建立起良好的沟通渠道和方式 chapter_26 chapter_27进行需求获取应注意的问题进行需求获取应注意的问题1.识别真正的客户识别真正的客户2.正确理解客户的需求正确理解客户的需求3.具备较强的忍耐力和清晰的思维具备较强的忍耐力和清晰的思维4.说明和教育客户说明和教育客户 chapter_28本章要点本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更q三、需求建模的基本方法q四、案例分析 chapter_29需求分析定义需求分析定义q需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。cha

16、pter_30需求分析模型需求分析模型 chapter_31本章要点本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更q三、需求建模的基本方法q四、案例分析 chapter_32需求规格需求规格q需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书q需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。chapter_33软件需求规格说明的原则软件需求规格说明的原则 chapter_34 chapter_353 3、规格文档参考规格文档参考1.引言2.系统定义 3.

17、应用环境4.功能规格 5.性能需求6.产品提交7.实现约束8.质量描述9.其它10.签字认证 chapter_36本章要点本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更q三、需求建模的基本方法q四、案例分析 chapter_37需求验证需求验证q需求是正确的吗？q需求是一致的吗？q需求是完全的吗？q需求是实际可行的吗？q需求是必要的吗？q需求是可检验的吗？q需求是可跟踪的吗？q最后的签字 chapter_38本章要点本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更q三、需求建模的基

18、本方法q四、案例分析 chapter_39需求总在变化需求总在变化 chapter_40 chapter_41需求变更管理需求变更管理1.1.确定需求变更控制过程确定需求变更控制过程2.2.建立变更控制委员会建立变更控制委员会(SCCB)SCCB)3.3.进行需求变更影响分析进行需求变更影响分析4.4.跟踪所有受需求变更影响的工作产品跟踪所有受需求变更影响的工作产品5.5.建立需求基准版本和需求控制版本文档建立需求基准版本和需求控制版本文档6.6.维护需求变更的历史记录维护需求变更的历史记录7.7.跟踪每项需求的状态跟踪每项需求的状态8.8.衡量需求稳定性衡量需求稳定性 chapter_42需

19、求变更管理需求变更管理q管理和控制需求基线的过程q需求变更控制系统q一个正式的文档，说明如何控制需求变更q建立变更审批系统 chapter_43控制需求渐变的策略控制需求渐变的策略1.需求一定要与投入有显然的联系，在项目的开始双方都要明确：需求变化，成本也要变化。2.需求的变化要经过出资者的认可。3.小的需求变更也要经过正规的需求管理过程，否则积少成多。4.精确的需求和范围的定义并不会阻止需求的变更。这是两个层面的问题。chapter_44变更控制过程变更控制过程 chapter_45需求变更处理流程需求变更处理流程n提出变更n变更评估n实施变更 chapter_46变更申请变更申请需求方需求

20、方开发方开发方忽略忽略选择变更方式选择变更方式SCCB评估评估项目经理自行决定项目经理自行决定根据评估结果根据评估结果拒绝拒绝接受本次修改接受本次修改下个版本再修改下个版本再修改修改合同相关信息修改合同相关信息修改相关需求修改相关需求修改相应的项目计划修改相应的项目计划 chapter_47表4-3 需求变更提交单软件基线产品修改提交单软件基线产品修改提交单申请申请人人韩万江韩万江申请日期2002。1011项目项目名称名称项目管理系统项目管理系统阶段阶段名称名称系统设计系统设计文件文件名名 称称RCR-PM-01.doc,RCR-PM-02.doc,变更简述如下修改内容1）修改测试流程控制：将

21、2个角色，3个渠道流，改为3个角色，4个渠道流，详见RCR-PM-01.doc2）增加开发人员技能信息库管理，详见RCR-PM-02.doc验证意见同意RCR-PM-01.doc变更。RCR-PM-02.doc的变更可以推迟到下一个版本实施验证人杨炎泰验证日期20021011SCCB韩万江，姜岳尊，孙泉 填表人韩万江 chapter_48 需求变更管理原则需求变更管理原则（1）建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。（2）制订简单、有效的变更控制流程，并形成文档。在建

22、立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。（3）成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。（4）需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。（5）需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。（6）妥善保存变更产生的相关文档。chapter_49需求变更应对之道需求变更应对之道 相互协作很难想像遭到用户抵制的项目能够成功。在讨论需求时

23、，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来过分的要求，也应该仔细分析原因，积极提出可行的替代方案。充分交流需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。安排专职人员负责需求变更管理有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。合同约束需求变更给软件开发带来的影响有目

24、共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。区别对待随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、chapter_50需求变更应对之道需求变更应对之道对项目进度有重大影响的需求。遇到这种情况，开发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求(虽然用户认为是细化需求，但实际上是增加了工作量的新需求)，会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需

25、求变更评估的一项依据。同时，还要注意控制新需求提出的频率。选用适当的开发模型采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。用户参与需求评审作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行

26、最后确认的机会，可以有效减少需求变更的发生。chapter_51本章要点本章要点q一、软件需求定义q二、软件需求管理过程q三、需求建模的基本方法q四、案例分析 chapter_52需求建模的基本方法需求建模的基本方法1.原型方法2.结构化分析法3.面向对象的用例分析法4.功能列表法5.其他 chapter_53本章要点本章要点q一、软件需求定义q二、软件需求管理过程q三、需求建模的基本方法q原型方法q结构化分析法q面向对象的用例分析法q功能列表法q其他q四、案例分析 chapter_54原型方法原型方法q按照用户的需要，快速形成一个操作流程界面q可能只是一个框架，具体的功能没有实现，只是结果q

27、静态的操作流程，以便与用户快速就需求达成一致q主要考虑系统的功能需求，很少考虑非功能需求 chapter_55原型方法原型方法需求分析原型开发原型评价 chapter_56原型方法的类型原型方法的类型q进化型q开发出来用于了解问题，并形成被交付软件的部分或全部的基础q抛弃型q开发出来获以便更多地了解问题或探究可能的方案的灵活性或者合理性，是尝试性软件，不用于被交付软件的实际部分 chapter_57原型实例原型实例q原型系统 chapter_58本章要点本章要点q一、软件需求定义q二、软件需求管理过程q三、需求建模的基本方法q原型方法q结构化分析法q面向对象的用例分析法q功能列表法q其他q四、

28、案例分析 chapter_59结构化分析方法结构化分析方法（SA,Structured AnalysisSA,Structured Analysis）q20世纪70年发展起来的面向数据流的方法q是一种自顶向下逐步求精的分析方法q根据软件内部数据传递、变换的关系进行分析的 chapter_60结构化分析方法结构化分析方法-技术技术q数据流图(DFD)q数据字典(DD)q系统流程图 chapter_61 chapter_62 chapter_63 chapter_64数据字典数据字典q描述系统中涉及的每个数据,是数据描述的集合,通常配合数据流图使用,用来描述数据流图中出现的各种数据和加工.chap

29、ter_65数据字典数据字典-组成组成q数据项:数据元素q数据流:由数据项组成的数据流q数据文件:表示对数据文件的存储 chapter_66数据流图需求分析实例数据流图需求分析实例q建立学生管理系统q学管科q体检科q学籍科q学生处 chapter_67数据流图数据流图-顶层顶层学管科学管科体检科体检科学籍科学籍科学生管理信息系统学生处领导学生基本信息学生健康信息学生成绩学生健康情况表学生成绩单查询要求不及格人数人数统计表 chapter_68数据流数据流图图-0-0层层 chapter_69数据流图数据流图-1-1层层 chapter_70数据流图数据流图-1-1层层 chapter_71数据

30、字典数据字典-数据流数据流 学生基本信息：学号十姓名 学生健康信息：学号十健康情况 学生成绩：学号十课程名+成绩 查询要求：健康查询单|平均成绩查询单 l不及格人数查询 学生健康情况表：优十良十一般十差 学生成绩单：学号十姓名十课程名+成绩+总成绩 不及格人数统计表：学号十成绩十不及格总人数 chapter_72数据数据字典字典-数据文件数据文件q文件名：基本信息q组成：学号十姓名十入学成绩十生源q组织：按学号递增顺序排列q文件名：健康文件q组成：学号+姓名+健康情况q组织：按照健康情况为优、良、一般、差顺序排列q文件名：成绩文件q组成：学号+姓名+平均成绩q组织：按照评剧成绩递增顺序排列 c

31、hapter_73系统流程图系统流程图q系统包含的部分以及各个部分之间的关系q是描述物理系统的工具q用图形符号表示系统中的元素q表达了系统中各个元素之间的信息流动情况 chapter_74系统流程图符号系统流程图符号 chapter_75制定出访计划开 始出访组团登记出访计划表出访团组基本情况登记表是否需要办理护照护照管理护照登记表护照卡申请护照签证管理结束是否临时出访计划表申请出国护照事项表申请出国签证事项表高检院外事局出访业务流程图计划是否落实是否是否本单位人员是否结束 chapter_76本章要点本章要点q一、软件需求定义q二、软件需求管理过程q三、需求建模的基本方法q原型方法q结构化分

32、析法q面向对象的用例分析法q功能列表法q其他q四、案例分析 chapter_77面向对象的需求分析面向对象的需求分析qOOSEqOOAqOODqOOPqOOTq.chapter_78OOAOOAq是OO软件工程的第一项技术活动q将现实世界的“视图”转化为用对象来描述的模型q描述对象之间的各种关系，以满足软件系统的要求。chapter_79用例需求（用例需求（Use caseUse case）分析）分析q用例需求分析方法采用一种面向对象的情景分析方法q用例是系统向用户提供一个有价值的结果的某项功能q从用户角度出发考虑的功能需求q所有的用例结合起来就构成了用例模型 chapter_80UMLUML

33、需求视图需求视图q用例视图（Use case Diagram）q顺序图（Sequence Diagram）q状态图（State Diagram）q活动图（Activity Diagram）chapter_81 chapter_82 chapter_83 chapter_84 chapter_85用例视图用例视图q用例视图主要是展示了外部行为者所观察到的系统将提交的功能.即:各类外部行为者与系统所提供的用例的连接 chapter_86用例视图用例视图q用例（用例（Use caseUse case）：系统所提供）：系统所提供的功能描述的功能描述q角色（角色（ActorActor）：可能使用用例）：

34、可能使用用例的人或者外部系统的人或者外部系统 chapter_87UMLUML图符图符 chapter_88n通信关系：执行者通信关系：执行者 与用例之间的连线来表示与用例之间的连线来表示n泛化关系：用例间的泛化关系意味着一个用例是泛化关系：用例间的泛化关系意味着一个用例是另一个用例的特殊版本，特殊用例可在一般用例另一个用例的特殊版本，特殊用例可在一般用例的执行序列的任意位置插入额外的动作序列，也的执行序列的任意位置插入额外的动作序列，也可修改某些继承来的操作和顺序。在可修改某些继承来的操作和顺序。在UML中用带中用带连线的三角形表示。连线的三角形表示。n包含关系：描述用例间的共同行为，当两个

35、或多包含关系：描述用例间的共同行为，当两个或多个用例有共同的执行序列片断时，可将这些序列个用例有共同的执行序列片断时，可将这些序列片断抽取，形成被包含用例。片断抽取，形成被包含用例。UML中用标有中用标有 include的虚箭头线来表示。有点类似于程序的虚箭头线来表示。有点类似于程序间的调用关系。间的调用关系。n扩展关系：当对一个已存在的用例增加新的功能扩展关系：当对一个已存在的用例增加新的功能时，可使用扩展关系，扩展关系一般用于有条件时，可使用扩展关系，扩展关系一般用于有条件地扩展已有用例的行为，是一种不改变原始用例地扩展已有用例的行为，是一种不改变原始用例的情况下增加用例行为的一种方法。的

36、情况下增加用例行为的一种方法。chapter_89存款存款验证密验证密码码支取管支取管理理取取款款维护维护通知透通知透支支转转帐帐includeincludeextend顾客顾客银 行 系银 行 系统统管理管理员员 chapter_90用例实例用例实例 chapter_91用例实例用例实例 chapter_92顺序图示顺序图示q顺序图展示了几个对象之间的动态协作关系，主要用来显示对象之间发送消息的顺序，还显示对象之间的交互，即系统执行某一特定时间点所发生的事。chapter_93顺序图示顺序图示 chapter_94状态视图状态视图q状态图是对类描述的补充，它说明该类的对象所有可能的状态以及那

37、些事件将导致状态的改变。q它是一个类对象所可能经历的所有历程的模型图 chapter_95活动视图活动视图q活动图用来描述执行工作流程中涉及的活动，展示了连续的活动流 chapter_96活动图例活动图例 chapter_97Use CaseUse Case需求分析方法综述需求分析方法综述q识别出系统的Actorq描述主要的Use caseq实现用例视图q实现顺序视图，活动视图,状态视图等 chapter_98实例实例用Rational rose工具实现的需求规格文档q贸易链需求的需求实例 chapter_99 chapter_100 chapter_101 chapter_102 chapt

38、er_103 chapter_104 chapter_105 chapter_106 chapter_107 chapter_108 chapter_109本章要点本章要点q一、软件需求定义q二、软件需求管理过程q三、需求建模的基本方法q原型方法q结构化分析法q面向对象的用例分析法q功能列表法q其他q四、案例分析 chapter_110功能列表功能列表需求类别（功能需求类别（功能/性能）性能）名称名称/标识标识描述描述特性（Feature）AA.1A.n特性Feature BB.1B.n特性Feature CC.1C.n chapter_111功能列表实例（功能列表实例（某网站功能列表某网站功

39、能列表)chapter_112本章要点本章要点q一、软件需求定义q二、软件需求管理过程q三、需求建模的基本方法q四、案例分析 chapter_113案例分析案例分析“School”项目的需求管理过程：q需求确认：原型法q需求变更：q变更控制系统q变更过程 chapter_114Infosys公司常用的变更管理过程公司常用的变更管理过程（1）记录变更。（2）分析变更对工作产品的影响。（3）估计变更申请所需的工作量。（4）重新估计交付时间表。（5）执行累积的成本影响分析。（6）如果影响超出一定限度，则与高级主管一起评审影响。（7）客户不再提出变更申请。（8）修改工作产品。chapter_115变更

40、申请日记变更申请日记n护一个变更申请日记，以跟踪变更申请。n日志中的每条记录包含一个变更申请号、关于变更的简单描述、变更的影响、变更申请的状态以及关键日期。n在评估变更申请的影响时，必须执行影响分析。n影响分析涉及标识出需要进行变更的工作产品，并估算对每种产品的变更量；通过重新查看风险管理计划，重新评估项目风险；评估需求变更蕴涵的总的工作量和进度估计的变化。n 客户对分析结果进行评审评审，并做出答复答复。n变更申请一般作为需求规格说明文档的附件变更申请一般作为需求规格说明文档的附件。有时还要修改文档的有关部分以反映所做的变更。n监督已认可的变更申请并保证它们正确实现，这部分由配置管理过程处理。

41、chapter_116变更的累积影响变更的累积影响 需求变更的一种危险是：尽管每种变需求变更的一种危险是：尽管每种变更本身并不大，但是生命期中所有变更本身并不大，但是生命期中所有变更的累积影响却是很大的。因此，除更的累积影响却是很大的。因此，除了研究每个变更的影响并对它们进行了研究每个变更的影响并对它们进行跟踪外，还必须监督变更的累积影响。跟踪外，还必须监督变更的累积影响。chapter_117Infosys公司的项目经理有时为处理变更申请预留一定的余地。只要所有变更累积的工作量不超过这一预留的工作量，就不需要做任何特殊的处理。然而，如果所有变更的累积工作量超过了这一预留的工作量，则再进行变更

42、可能会对总成本和进度安排产生负面影响。在这种情况中，项目经理必须修改估计并使它们得到承认。chapter_118课堂讨论课堂讨论面对客户的需求变更，接受还是拒绝？面对客户的需求变更，接受还是拒绝？在某公司的项目管理课堂上，小李，小王等人正在七嘴八舌地议论纷纷。原来，大家正在讨论小王的公司最近遇到的两个颇为有趣的项目。据小王介绍，这两个项目分别由两个项目经理来担任。其中，项目经理A属于“谦虚”型，对于客户提出的问题，无论大小都给与解决，客户对此非常满意，然而，项目进度却拖得比较长，而且，客户总想把所有的问题都改完再说，项目已经一再延期。相比之下，项目经理B显得稍有些“盛气凌人”，对于客户提出的问

43、题，大多都不予理睬，客户对此不是很满意，不过，该项目的进度控制得比较好，基本能够按期完成项目。chapter_119话刚一说完，小李就抢着说：“A比较像我，一般在和我的一些战略客户打交道的时候，我基本是有求必应，与客户的关系处得如鱼得水，这样做肯定不会错。就像前天我连合同都写错了，找到客户，人家二话没说就同意改了。你说如果是B的话可能吗？”小王对此不以为然，“对项目经理来说，成本、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘考虑项目的各要素。对于用户的要求，应该在有限的范围内给与解决，但不可以做出太大的牺牲。一味的迁就用户将会使整个项目失败。”小林接着小王的话说：“当前，国

44、内的项目一般情况下是由销售处面签单，再由项目经理接手后续的工作，因此客户关系多在事前已经搞定。发生新的情况后，可以由公司的公关部出面与客户进行协调，项目经理可以在此过程中坚持一下原则，与公司的公关部一个红脸，一个白脸，唱出一出好戏。”chapter_120小赵反驳道：“不管怎样，客户才是第一位的。客户可以给你带来收入，也可以给你带来更多的客户和工作，有什么道理不多配合一下他们呢？说实话我对B的做法蛮欣赏的，可惜行不通。因为客户是上帝，如果照B的做法，后果会造成做一次项目丢掉一个客户，太不划算了。”问题：1、如果你的项目遇到需求变更问题，你会采用哪种方式去应对？2、分析这两种应对需求变更方式的优缺点。分析结果 chapter_121 chapter_122小结小结q软件需求开发过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更q需求建模的基本方法q原型方法q结构化分析法q面向对象的用例分析法q关键功能列表法