需求开发及管理【精品-ppt】.pptVIP

需求开发及管理;第六章 需求开发及管理;*;需求管理（REQM）;SG 1 Manage Requirements（管理需求），对需求进行管理，并识别需求与项目计划和工作产品之间的不一致项。 SP 1.1 Obtain an Understanding of Requirements（取得对需求的理解） SP 1.2 Obtain Commitment to Requirements（取得对需求的承诺） SP 1.3 Manage Requirements Changes（管理需求变更） SP 1.4 Maintain Bidirectional Traceability of Requirements（维护对需求的双向跟踪） SP 1.5 Identify Inconsistencies Between Project Work and Requirements（识别项目工作与需求之间的不一致项）;需求开发（RD）;SG 1 Develop Customer Requirements（开发客户需求），收集干系人（包括客户、最终用户、供应商、构造人员、测试人员、设备制造商、后勤支持人员等）的需要、期望、约束、接口，并把他们转化为客户需求。 SP 1.1 Elicit Needs（引出客户需要），引出在产品生命周期内所有阶段干系人的需要、期望、约束和接口。 SP 1.2 Develop the Customer Requirements（开发客户需求），把干系人的需要、期望、约束和接口转化为客户需求。;RD（二）;RD（三）;第六章 需求开发及管理;需求来源;需求开发及管理目的;需求开发及管理内容;在需求开发及管理准则;第六章 需求开发及管理;需求开发及管理流程;工作流程图 ;第六章 需求开发及管理;系统工程与需求工程的区别;需求来源;需求获取流程图;合同类项目 采取与用户会谈、现场调查等方法详细记录用户给定需求，形成《需求调研单》，然后进行需求风险识别、分类、筛选、优先排序，整理形成《用户需求列表》，并在此基础之上形成《用户需求说明书》； 研发部经理/项目经理组织会议讨论确认需求项，需要与用户方（/产品研发提出部门）就《用户需求说明书》的需求项达成一致意见，由用户或总工程师签字确认。;新产品研发项目 对市场上已存在的同类产品/或超前产品进行调研，或从行业标准、规则中提取需求信息 ，形成《需求调研单》，然后进行需求风险识别、分类、筛选、优先排序，整理形成《用户需求列表》 ，并在此基础之上形成《用户需求说明书》； 研发部经理/项目经理组织会议讨论确认需求项，需要与用户方就《用户需求说明书》的需求项达成一致意见，由用户或总工程师签字确认。;产品升级类项目 分析从技术支持部或实施服务人员处反馈的用户新需求、系统缺陷，进行需求分类、评估、识别优先级，并考虑系统升级问题，形成《用户需求列表》 ，并在此基础之上形成《用户需求说明书》。 研发部经理/项目经理组织、讨论确定《用户需求说明书》，由研发部经理审核签字。;基于用例的需求获取步骤;谁是主要参与者，次要参与者？ 参与者的目标是什么？ 做事开始前有什么前提条件？ 参与者完成的主要工作或功能是什么？ 按照故事/业务场景所描述的还可能需要考虑什么异常？ 参与者的交互中有什么可能的变化？ 参与者将获得、产生或改变哪些信息？ 参与者必须通知系统外部环境的改变吗？ 参与者希望从系统获取什么信息？ 参与者希望得知意料之外的变更吗？;太多的用例，注意合适的抽象级别。 用例冗余，使用“包含”关系，将公共部分分离出来写到一个单独的用例中。 用例中的用户界面设计，用例的重点就是用户使用系统做什么，而不是关心屏幕上是怎么显示的。 用例中包含数据定义，比如数据类型、长度、格式和合法值等，这些应当放到数据字典里。 试图把每一个需求与一个用例相联系，这是不可能的，需要使用规格说明书编写非功能需求、外部接口需求以及一些不能由用例得到的功能需求。;第六章 需求开发及管理;需求分析;需求分析（续）;需求分析流程图 ;*;需求分析包含的元素;第六章 需求开发及管理;需求评审步骤;第六章 需求开发及管理;需求变更控制;需求版本控制 为评审通过的软件需求文档确定版本号；每一个经过变更软件需求文档应在修订页中描述其修正版本的历史情况，包括已变更的内容，变更日期，变更人姓名和变更后的版本号；项目经理和质量保证工程师负责检查软件需求文档版本的一致性。 需求跟踪矩阵 在每次需求变更之后，必须更新需求跟踪矩阵；在每个阶段工作完成之后，亦需要更新需求跟踪矩阵。;*;需求开发及管理实训;本章结束，谢谢!;z3GaNhUn!u-B5IcPjWq%x0D7KeRlYs*z2G9MgTn#u)B4IbPiWp$w+D6KdRkYr*y1F8M