软件项目管理第第4章软件需求

1、承上启下0情景引入：计划1How long?How much?How good?项目计划2没有计划的情况3时间资源投入开发工作计划性工作协调性工作有计划的情况4时间资源投入开发工作计划性工作协调性工作明确做什么？ chapter_45范围计划6软件项目管理 第二篇7第第 4 4 章章软件项目需求管理软件项目需求管理需求管理中的问题举例8需求的隐含错误需求管理中的问题举例chapter_49用户不断增加需求、变更需求项目失败的原因分析10No. Top 10 Factors 平均值平均值 1 Inadequate requirements specification 不充分的需求规范不充分的需求

2、规范 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 project managers 缺乏合格的缺乏合格的项目经理项目经理 4.1 6 Shortage of software engineers 缺乏软件工程师缺乏软件工程师 3.9 7 Fixed - price contract

3、 固定价合同固定价合同 3.8 8 Inadequate communications for system integration 系统集成阶段系统集成阶段, 交流与沟通不充分交流与沟通不充分 3.8 9 Insufficient experience as team团队缺乏经团队缺乏经验验 3.6 10 Shortage of application domain experts 缺乏应用领域专家缺乏应用领域专家 3.6 Scale: 5 = Very Serious 3 = Serious 1 = No Serious Source: Carnegie-Mellon University

4、, Software Engineering Institute本章要点11软件需求定义软件需求管理过程需求建模的基本方法案例分析 课程实践软件需求定义 chapter_212需求是指用户对软件的功能和性能的要求。本章要点13软件需求定义软件需求管理过程需求建模的基本方法案例分析 课程实践软件需求管理的过程 chapter_414需求分析需求分析需求规格编写需求规格编写需求验证需求验证需求获取需求获取需求变更需求变更需求确认需求变更1、需求获取 chapter_215需求获取的方法 chapter_416用户要求软件需求获取需求n 访谈和调研访谈和调研l和用户进行访谈和调研通常是适用于任何环境

5、下的最重要和用户进行访谈和调研通常是适用于任何环境下的最重要最直接的方法之一。最直接的方法之一。l访谈的一个主要目标是确保访谈者的偏见或主观意识不会访谈的一个主要目标是确保访谈者的偏见或主观意识不会干扰自由的交流。干扰自由的交流。通过几次这样的访谈，开发人员和系统分析员能获得一些问通过几次这样的访谈，开发人员和系统分析员能获得一些问题域中的知识，对要解决的问题有进一步的理解。题域中的知识，对要解决的问题有进一步的理解。需求获取方法n 专题讨论会专题讨论会l专题讨论会是一种可用于任何情况下的软件需求调研方法。专题讨论会是一种可用于任何情况下的软件需求调研方法。l专题讨论会的目的是鼓励软件需求调研

6、并且在很短的时间内专题讨论会的目的是鼓励软件需求调研并且在很短的时间内 对讨论的问题达成一致。对讨论的问题达成一致。l专题讨论会一般由开发团队的成员主持，主要讨论系统应具专题讨论会一般由开发团队的成员主持，主要讨论系统应具备的特征或者评审系统特性。备的特征或者评审系统特性。l专题讨论会前的准备工作是能否成功的举行会议的关键。专题讨论会前的准备工作是能否成功的举行会议的关键。需求获取方法n 脑力风暴脑力风暴l 脑力风暴是一种对于获取新观点或创造性的解决方案而言非脑力风暴是一种对于获取新观点或创造性的解决方案而言非常有用的方法。常有用的方法。l 通常，专题讨论会的一部分时间是用于进行脑力风暴，找出

7、通常，专题讨论会的一部分时间是用于进行脑力风暴，找出关于软件系统的新想法和新特征。关于软件系统的新想法和新特征。l 脑力风暴包括两个阶段：想法产生阶段和想法精化阶段。脑力风暴包括两个阶段：想法产生阶段和想法精化阶段。应用程序脑力风暴中确定的特征系统特征定义家用自动照明系统自动照明设置用户可以制定每天自动照明的时间计划，系统将按时间计划触发照明事件任务管理系统代理任务通知当用户将自己的任务代理给其他人时，系统自动发送Email通知将接手该任务的人脑力风暴中为确定的问题定义系统特征脑力风暴中为确定的问题定义系统特征需求获取方法n 场景串联场景串联l 场景串联的目的是为了尽早的从用户那里得到用户对建

8、议的场景串联的目的是为了尽早的从用户那里得到用户对建议的系统功能的意见。系统功能的意见。l 场景串联提供了用户界面以说明系统操作流程，它容易创建场景串联提供了用户界面以说明系统操作流程，它容易创建和修改，能让用户知道系统的操作方式和流程。和修改，能让用户知道系统的操作方式和流程。l 根据与用户交互的方式，场景串联被分成三种模式：静态的根据与用户交互的方式，场景串联被分成三种模式：静态的场景串联、动态的场景串联以及交互的场景串联。场景串联、动态的场景串联以及交互的场景串联。l 选择提供哪种场景串联是根据系统的复杂性和需求缺陷的风选择提供哪种场景串联是根据系统的复杂性和需求缺陷的风险来确定的。险来

9、确定的。需求获取方法进行需求获取应注意的问题n识别真正的客户识别真正的客户n正确理解客户的需求正确理解客户的需求n具备较强的忍耐力和清晰的思维具备较强的忍耐力和清晰的思维n说明和教育客户说明和教育客户2、需求分析 chapter_423需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。 chapter_424需求分析模型3、需求规格编写 chapter_425需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书需求规格文档参考 chapter_226引言系统定义 应用环境功能规格 性能需求产品提交实现约束质量描述其它签字认证4、需求验证 chapter_4

10、27需求是正确的吗？需求是一致的吗？需求是完全的吗？需求是实际可行的吗？需求是必要的吗？需求是可检验的吗？需求是可跟踪的吗？最后的签字5、需求总在变化 chapter_428需求变更管理 chapter_429确定需求变更控制过程确定需求变更控制过程建立变更控制委员会建立变更控制委员会( (SCCB)SCCB)进行需求变更影响分析进行需求变更影响分析跟踪所有受需求变更影响的工作产品跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档建立需求基准版本和需求控制版本文档维护需求变更的历史记录维护需求变更的历史记录跟踪每项需求的状态跟踪每项需求的状态衡量需求稳定性衡量需求稳定性表4-3

11、 需求变更提交单软件基线产品修改提交单软件基线产品修改提交单申请人韩万江申请日期2002。1011项目名称项目管理系统阶段名称系统设计文件名称RCR-PM-01.doc, RCR-PM-02.doc,变更简述如下修改内容1 1）修改测试流程控制：将）修改测试流程控制：将2 2个角色，个角色，3 3个渠道流，改为个渠道流，改为3 3个角色，个角色，4 4个渠道流，详见个渠道流，详见RCR-PM-01.doc2 2）增加开发人员技能信息库管理，详见）增加开发人员技能信息库管理，详见RCR-PM-02.doc验证意见同意RCR-PM-01.doc变更。RCR-PM-02.doc的变更可以推迟到下一个

12、版本实施验证人杨炎泰验证日期20021011SCCB韩万江，姜岳尊，孙泉 填表人韩万江控制需求渐变的策略需求一定要与投入有显然的联系，在项目的开始双方都要明确：需求变化，成本也要变化。需求的变化要经过出资者的认可。小的需求变更也要经过正规的需求管理过程，否则积少成多。精确的需求和范围的定义并不会阻止需求的变更。这是两个层面的问题。变更控制过程需求变更处理流程提出变更变更评估实施变更 需求变更管理原则 （1） 建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。 （2） 制订简单、

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

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

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

16、户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。 选用适当的开发模型选用适当的开发模型采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。 需求变更应对之道用户参与需求评审用户参与需求评审作为需求的提出者

17、，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。 需求变更应对之道案例分析“School”项目的需求管理过程：q需求确认：原型法q需求变更：q变更控制系统q变更过程Infosys公司常用的变更管理过程（1）记录变更。（2）分析变更对工作产品的影响。（3）估计变更申请所需的工作量。（4）重新估计交付时间表。（5）执行累积的成本影响分析。（6）如果影响超出一定限度，则与高级主管一起评审影响。（7）客户不再提出变更申请。（8）修改工作产品。变更申请日记护一个变更申请日记，以跟踪变更

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

19、险是：尽管每种变更本身并不大，但是生命期中所有变更本身并不大，但是生命期中所有变更的累积影响却是很大的。因此，除更的累积影响却是很大的。因此，除了研究每个变更的影响并对它们进行了研究每个变更的影响并对它们进行跟踪外，还必须监督变更的累积影响。跟踪外，还必须监督变更的累积影响。Infosys公司的项目经理有时为处理变更申请预留一定的余地。 只要所有变更累积的工作量不超过这一预留的工作量，就不需要做任何特殊的处理。 然而，如果所有变更的累积工作量超过了这一预留的工作量，则再进行变更可能会对总成本和进度安排产生负面影响。在这种情况中，项目经理必须修改估计并使它们得到承认。课堂讨论面对客户的需求变更，

20、接受还是拒绝？ 在某公司的项目管理课堂上，小李，小王等人正在七嘴八舌地议论纷纷。原来，大家正在讨论小王的公司最近遇到的两个颇为有趣的项目。据小王介绍，这两个项目分别由两个项目经理来担任。其中，项目经理A属于“谦虚”型，对于客户提出的问题，无论大小都给与解决，客户对此非常满意，然而，项目进度却拖得比较长，而且，客户总想把所有的问题都改完再说，项目已经一再延期。相比之下，项目经理B显得稍有些“盛气凌人”，对于客户提出的问题，大多都不予理睬，客户对此不是很满意，不过，该项目的进度控制得比较好，基本能够按期完成项目。话刚一说完，小李就抢着说：“A比较像我，一般在和我的一些战略客户打交道的时候，我基本是

21、有求必应，与客户的关系处得如鱼得水，这样做肯定不会错。就像前天我连合同都写错了，找到客户，人家二话没说就同意改了。你说如果是B的话可能吗？”小王对此不以为然，“对项目经理来说，成本、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘考虑项目的各要素。对于用户的要求，应该在有限的范围内给与解决，但不可以做出太大的牺牲。一味的迁就用户将会使整个项目失败。”小林接着小王的话说：“当前，国内的项目一般情况下是由销售处面签单，再由项目经理接手后续的工作，因此客户关系多在事前已经搞定。发生新的情况后，可以由公司的公关部出面与客户进行协调，项目经理可以在此过程中坚持一下原则，与公司的公关部一个

22、红脸，一个白脸，唱出一出好戏。”小赵反驳道：“不管怎样，客户才是第一位的。客户可以给你带来收入，也可以给你带来更多的客户和工作，有什么道理不多配合一下他们呢？说实话我对B的做法蛮欣赏的，可惜行不通。因为客户是上帝，如果照B的做法，后果会造成做一次项目丢掉一个客户，太不划算了。” 问题：1、如果你的项目遇到需求变更问题，你会采用哪种方式去应对？ 2、分析这两种应对需求变更方式的优缺点。分析结果需求变更控制流程48变更申请忽略选择变更方式SCCB评估项目经理自行决定根据评估结果拒绝接受本次修改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划本章要点49软件需求定义软件需求管理过程需求建

23、模的基本方法案例分析 课程实践需求建模的基本方法介绍 chapter_450原型方法结构化分析法面向对象的用例分析法功能列表法 chapter_251需求建模的基本方法介绍 chapter_452原型方法结构化分析法面向对象的用例分析法功能列表法1、原型方法chapter_453需求分析原型开发原型评价原型实例54需求建模的基本方法介绍 chapter_455原型方法结构化分析法面向对象的用例分析法功能列表法2、结构化分析方法5620世纪70年发展起来的面向数据流的方法是一种自顶向下逐步求精的分析方法根据软件内部数据传递、变换的关系进行分析的 chapter_4结构化分析方法-技术 chapt

24、er_457数据流图(DFD)数据字典(DD)系统流程图 chapter_458学生管理系统-数据流图-顶层 chapter_459学管科学管科体检科体检科学籍科学籍科学生管理信息系统学生处领导学生基本信息学生健康信息学生成绩学生健康情况表学生成绩单查询要求不及格人数人数统计表学生管理系统-数据流图-0层 chapter_260学生管理系统-数据流图-1层 chapter_261学生管理系统-数据流图-1层 chapter_262学生管理系统-数据字典-数据流 chapter_463 学生基本信息：学号十姓名 学生健康信息：学号十健康情况 学生成绩：学号十课程名+成绩 查询要求：健康查询单 |平均成绩查询单 l不及格人数查询 学生健康情况表：优十良十一般十差 学生成绩单：学号十姓名十课程名+成绩+总成绩 不及格人数统计表：学号十成绩十不及格总人数需求建模的基本方法介绍 chapter_464原型方法结构化分析法面向对象的用例分析法功能列表法3、面向对象的用例分析 chapter_465基于面向对象的情景分析方法从用户角度出发考虑的功能需求用例是系统向用户提供一个有价值的结果的某项功能UML需求视图chapter_466用例视图（Use case Diagram）顺序图（Sequence Diagram）状态图（State Diagram）活动图（Activity Diagr