信息系统项目管理师需求管理培训教材(PPT 108页).ppt

1、信息系统项目管理师需求管理,闫波,需求管理,用户需求是软件项目成败的关键 需求问题： 需求的隐含错误 需求不明确、含糊 用户刁难、用户不断增加需求 需求变更,本章要点,17.1 需求管理概述 17.2 制定需求管理计划 17.3 需求管理规格说明的版本控制 17.4 需求变更管理 17.5 需求跟踪,需求管理,需求：指的是由项目接受的或项目产生的产品和产品构件需求。包括由组织征集的对项目的需求。 Requirement Management 需求管理 确保各方对需求的一致理解，管理和控制需求的变更，从需求到最终产品的双向跟踪。,软件需求定义,需求是指用户对软件的功能和性能的要求，就是用户希望软

2、件能做什么事情，完成什么样的功能，达到什么性能。,软件需求,特征： 模糊性 不确定性 变化性 主观性,软件需求的层次,软件需求的类型,功能需求 性能需求 环境需求 用户界面需求 资源使用需求 成本消耗需求 开发进度需求 预先估计以后系统可能达到的目标,软件需求的重要性,需求管理与项目管理的关系,项目需求是制定项目计划，开发项目产品和从事项目活动的依据。 项目的计划、项目的开发活动及开发的产品应与项目需求保持一致，随需求的变化而调整。,需求工程（RE）,需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征一门学科。 需求开发 需求管理

3、,软件需求工程管理的过程,需求获取,扩展需求,需求获取,用户要求,基线需求,软件需求,通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。,获取需求的活动,了解用户类型及潜在类型 访谈和调研（要有记录） 对用户需求进一步整理和提取 将用户需求反馈用户,注意事项,识别真正的客户. 正确理解客户的需求 具备较强的忍耐力和清晰的思维 说服和教育客户,需求分析,定义：需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。 需求分析也称为需求建模,需求分析模型,需求分析的时间,设计方案的时候 项目开始的时候 接管一个项目的时候 需求变更的时候,需求分析基本

4、策略,头脑风暴 专家评审 焦点会议组 目的：进行具体的流程细化、数据项确认，必要时可以提供原型系统和明确的业务流程报告、数据项表，并能清晰的向用户描述系统的业务流设计目标。,需求分析的难点,问题的复杂性（不了解业务） 交流的障碍 不完备性和不一致性 需求的易变性,需求定义,需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书（SRS） 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。,软件需求规格说明的原则,从现实中分离功能，即描述要“做什么”而不是“怎样实现” 要求使用面向处理的规格说明语言（或称系统定义语言）

5、 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中 规格说明必须包括系统运行环境 规格说明必须是一个认识模型 规格说明必须是可操作的 规格说明必须容许不完备性并允许扩充,需求规格说明书文档参考,引言 系统定义 应用环境 功能规格 性能需求 产品提交 实现约束 质量描述 其它 签字认证,需求验证,开发方和用户方共同对需求文档进行评审，经双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。,需求验证,需求是正确的吗？ 需求是一致的吗？ 需求是完全的吗？ 需求是实际可行的吗？ 需求是客户需要的吗？ 需求是可检验的吗？ 需求是可跟踪的吗？ 最后的签字,需求验

6、证,快速原型法,需求管理,需求管理中要收集需求的变更和变更的理由，维持对原有需求和所有产品及产品构件需求的双向跟踪。,需求变更,项目失败主要的原因在于需求变更!,需求建模的方法,创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。,原型分析法,定义： 按照用户的需要，快速形成一个操作流程界面 可能只是一个框架，具体的功能没有实现，只是结果 静态的操作流程，以便与用户快速就需求达成一致 主要考虑系统的功能需求，很少考虑非功能需求,原型方法,需求分析,原型开发,原型评价,原型方法的类型,进化型 开发出来用于了解问题，并形成被交

7、付软件的部分或全部的基础 抛弃型 开发出来获以便更多地了解问题或探究可能的方案的灵活性或者合理性，是尝试性软件，不用于被交付软件的实际部分,结构化分析法,定义（SA,Structured Analysis） 20世纪70年发展起来的面向数据流的方法 是一种自顶向下逐步求精的分析方法 根据软件内部数据传递、变换的关系进行分析的,结构化分析方法技术,数据流图(DFD) 数据字典(DD) 系统流程图,数据流图,是一种描述软件系统逻辑模型的图形符号,表示数据的起始点和终点,表示对数据的加工处理,表示数据流,箭头表示数据的流动方向,表示对数据的存储,银行取款过程数据流图,数据流图的层次结构,为了表达数据

8、处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统,分层数据流图,分层数据流图,顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据 底层流图是指其加工不需再做分解的数据流图，它处在最底层 中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。,数据字典,描述系统中涉及的每个数据,是数据描述的集合,通常配合数据流图使用,用来描述数据流图中出现的各种数据和加工. 组成： 数据项:数据元素 数据流:由数据项组成的数据流 数据文件:表示对数据

9、文件的存储,数据字典关系符号,数据流图需求分析实例,建立学生管理系统 学管科 体检科 学籍科 学生处,顶层数据流图,学管科,体检科,学籍科,学生管理 信息系统,学生处领导,学生基本信息,学生健康信息,学生成绩,学生健康情况表,学生成绩单,查询要求,不及格人数,人数统计表,第0层数据流图,第1层数据流图,系统流程图,系统包含的部分以及各个部分之间的关系 是描述物理系统的工具 用图形符号表示系统中的元素 表达了系统中各个元素之间的信息流动情况,系统流程图符号,用例分析法,面向对象的软件工程（OOSE） OOA OOD OOP (object oriented programming ) OOT .

10、,用例（User Case）,表示一个动作序列的定义，包括执行的变量和外界交互的过程。 提款机取款用例,OOA,是OO软件工程的第一项技术活动 将现实世界的“视图”转化为用对象来描述的模型 描述对象之间的各种关系，以满足软件系统的要求。,用例需求分析,用例需求分析方法采用一种面向对象的情景分析方法 用例是系统向用户提供一个有价值的结果的某项功能 所有的用例结合起来就构成了用例模型 从用户角度出发考虑的功能需求,用例需求分析,从前：问用户希望系统为他做什么？ 现在：问用户利用系统做什么？,UML,Unified Modeling Language统一建模语言，是一种通用的模拟语言。 Booch,

11、Rumbaugh 和Jocobson 基础上发展起来的。 1997年11月国际对象管理组织OMG批准将UML作为基于面向对象技术的标准建模语言。 UML制定了一整套完整的面向对象的标记和处理方法。,UML需求视图,用例视图（Use case Diagram） 顺序图（Sequence Diagram） 状态图（State Diagram） 活动图（Activity Diagram）,USE CASE视图,用例视图主要是展示了外部行为者所观察到的系统将提交的功能.即:各类外部行为者与系统所提供的用例的连接 用例（Use case）：系统所提供的功能描述 角色（Actor）：可能使用用例的人或者外

12、部系统,UML图符,USER CASE实例,序列（Sequence）图,顺序图展示了几个对象之间的动态协作关系，主要用来显示对象之间发送消息的顺序，还显示对象之间的交互，即系统执行某一特定时间点所发生的事。,Sequence实例,状态视图,状态图是对类描述的补充，它说明该类的对象所有可能的状态以及那些事件将导致状态的改变。 它是一个类对象所可能经历的所有历程的模型图。,活动（Activity）视图,活动图用来描述执行工作流程中涉及的活动，展示了连续的活动流,活动图例,Use Case需求分析方法综述,识别出系统的Actor 描述主要的Use case 实现用例视图 实现顺序视图，活动视图,状态

13、视图等,功能列表法,对项目的功能需求进行详细说明，既可以单独使用，也可以作为用例分析方法的附加说明来详细说明用例的具体功能。,为什么会有需求变更？,与用户交互不够，对问题理解有差异 模糊的需求 用户需求增加 开发方需求人员重视程度不够 开发人员理解偏差,有效控制变更合理的方法,需求阶段尽可能采用原型或用例法明确用户需求。 采用严格的需求管理变更流程。 采用良好的体系结构 采用面向对象思想,需求变更处理,CMMI中的需求管理流程,1 制定需求管理计划 2 求得对需求的理解 3 求得对需求的承诺 4 管理需求变更 5 维护对需求的双向跟踪性 6 识别项目工作与需求之间的不一致,CMMI中的需求管理

14、流程,1 制定需求管理计划 确定需求管理的软硬件资源、需求跟踪矩阵、需求变更请求表。,CMMI中的需求管理流程,2 求得对需求的理解 需求确认。避免需求蔓延和遗漏,CMMI中的需求管理流程,3 求得对需求的承诺 为实现需求活动所需的活动人员之间达成一致和建立承诺。,CMMI中的需求管理流程,4 管理需求变更 5 维护对需求的双向跟踪性 6 识别项目工作与需求之间的不一致,需求的属性,创建需求的时间 需求的版本号 需求创建的作者 负责认可需求的人员 需求状态 已建议；已批准；已实现； 需求涉及到的子系统 需求的稳定性 ,本章要点,17.1 需求管理概述 17.2 制定需求管理计划 17.3 需求

15、管理规格说明的版本控制 17.4 需求变更管理 17.5 需求跟踪,1 建立并维护需求管理的组织方针,对需求进行管理，确定项目计划与工作产品之间需求不一致之处。,2 确定需求管理需使用的资源,人力、财力、物力,3 分配责任,确定需求管理负责人及其责任 确认需求管理员的权限责任,4培训计划,对需求人员的培训 应用领域、需求分析、分析、审查和管理、需求管理工具、配置管理,5 确定需求管理的项目干系人,解决对需求的共识问题，评估需求变更的影响，通报双向跟踪情况，识别项目工作与需求不一致的情况。,6 制定判断项目工作与需求不一致的准则和纠正规程,依据此判断项目工作与需求不一致；不一致时启动纠正规程。,

16、7 制定需求跟踪性矩阵,正向跟踪、逆向跟踪 该矩阵保存了需求与后续工作成果的对应关系,8 制定需求变更审批程序,为保证项目顺利进行和产品质量，必须严格控制需求的变更。,9 制定审批规程,需求管理计划的审批规程,本章要点,17.1 需求管理概述 17.2 制定需求管理计划 17.3 需求管理规格说明的版本控制 17.4 需求变更管理 17.5 需求跟踪,版本管理,版本 Check out Check in,本章要点,17.1 需求管理概述 17.2 制定需求管理计划 17.3 需求管理规格说明的版本控制 17.4 需求变更管理 17.5 需求跟踪,需求变更,仔细评估已建议的变更 挑选合适的人选对

17、变更做出决定 变更应及时通知所有涉及的人员 项目按一定的程序来采纳需求变更,控制项目范围的扩展,扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大的改动。 需求变更不可避免，但必须控制。,变更控制过程,1 变更控制策略 达成一个策略，如何控制需求 所有需求变更必须遵循的过程； 未获批准的变更，不做过多工作； CCB决定实现哪些变更 项目风险承担者应了解变更数据库的内容； 不能从数据库中删除或修改变更请求的原始文档；,变更控制过程,2 变更控制步骤 开始条件 Entry Criteria 通过合适渠道接受一个合法的变更请求； 过程和步骤 验证任务正确完成的步骤 Verify 结束条件

18、 Exit Criteria,变更控制过程,3 变更控制状态报告 用报告、图表方式来总结变更控制数据库的内容和按状态分类的变更请求数量。,变更控制过程,4 变更控制工具 自动工具帮助有效的执行变更控制过程。,InfoSys公司对需求变更的处理,处理步骤： 1. 记录变更 2. 分析变更对工作产品的影响 3. 估计变更申请所需的工作量 4. 重新估计交付时间表 5. 执行累积的成本影响分析 6. 如果影响超出一定的限度，则与高级主管一起 评审影响 7. 客户不再提出变更申请 8. 修改工作产品,示例,变更日志跟踪累积变更影响,变更度量活动,接收、未作决定、结束处理的变更请求的数量； 已实现的变更需求的合计数量； 每个方面发出的变更请求数量； 每个已应用的需求建议变更和实现变更的数量； 投入处理变更的人力、物力；,本章要点,17.1 需求管理概述 17.2 制定需求管理计划 17.3 需求管理规格说明的版本控制 17.4 需求变更管理 17.5 需求跟踪,需求跟踪,编制每个需求同系统元素之间的联系文档。如需求、体系结构、源代码、测试用例、