需求分析和管理.ppt

accenture 2008 all rights reserved,需求开发和管理,2019年4月6日星期六,质量和流程提高 (qpi),2,accenture 2008 all rights reserved,agenda,欢迎 / 介绍 需求开发 需求管理,3,accenture 2008 all rights reserved,介绍,姓名 职责 期望,4,accenture 2008 all rights reserved,课程目标,在接受此培训模块后，将具备以下能力： 收集需求 检查需求描述是否恰当 分析需求 实施恰当的需求审批，需求传递和需求交流 管理需求和范围变更 建立和维护交付件以满足干系人的要求,5,accenture 2008 all rights reserved,什么是需求?,需求是: 用户为了解决问题或实现目标所需要的条件或能力.* 我们期望系统实现的功能，此功能对性能的要求是什么.* 需求不是: 定义怎样具体实现功能的规范条件. * source: institute of electrical and electronics engineers-610,6,accenture 2008 all rights reserved,需求举例,以下是需求的例子： 系统必须允许用户通过汽车生产商进行搜索 系统必须能够支持30,000用户使用.* 以下则不是一个需求: 客户将能够使用单选按钮或输入框选择搜索标准. 描述需求的正确方式: 系统必须能够提供根据各种搜索标准进行的检索. * source: institute of electrical and electronics engineers-610,7,accenture 2008 all rights reserved,正确需求的益处,讨论: 是否有过需求没有很好的被管理或者描述？? 原因是什么？ 可以进行哪些改变? 影响怎样？,8,accenture 2008 all rights reserved,正确需求的益处,有效的需求开发和管理的益处包括: 降低项目成本: 修复需求缺陷比其它缺陷的成本高处10倍多 需求缺陷占据了软件项目所有缺陷中40%以上 需求缺陷很少的降低将得到很到的收益，因为避免了返工和进度延误 满足项目期限要求 维护项目范围 促进交流 满足客户需求,9,accenture 2008 all rights reserved,议程,欢迎 / 介绍 需求开发 需求管理 活动 wrap - up / final q&a,10,accenture 2008 all rights reserved,需求开发和系统开发生命周期,部署,分析,设计,开发,测试,计划,需求开发要求与干系人紧密联合，一起按照客户和业务需要进行收集，分析，设计，验证和签署.,系统开发生命周期,收集&记录,优先，校验&确认,签署&转化,支持,11,accenture 2008 all rights reserved,需求开发和系统开发生命周期,开发 (计划和分析) 需求开发活动需要进行多个反复，以持续澄清和加深对需求的定义. 需求定义过程在计划阶段根据初步信息提出，这一信息成为初始“模块”活动的基本. 这些活动支持后来的需求收集，并成为一个周期的开始，这一周期在分析阶段末期以应用被充分说明作为结束，同时可以被基线化.,12,accenture 2008 all rights reserved,收集和记录: 从干系人开始,干系人是新（改进）的系统将对其产生影响的人 干系人包括：项目主办方，项目组成员，关键用户（smes），终端用户（其它员工），外部用户和客户，其供应商. 从干系人获取的重要信息： 愿景 业务功能/任务 期望 对改变和承诺的态度 能力 对其它干系人的影响,收集&记录,签署&过度,优先，校验&确认,13,accenture 2008 all rights reserved,收集和记录: 获得高层需求,高层需求在计划阶段收集. 高层需求是最基本的业务需求，新系统需要实现的最低功能要求. 记录是确定高层需求的开始，记录的建议包括： 项目工作的阐明 rfp (对建议的请求) 建议 客户之前起草的高层需求 从干系人处获取的愿景及业务目标提取更多的高层需求,收集&记录,签署&过度,优先，校验&确认,14,accenture 2008 all rights reserved,收集和记录: 确定项目范围,项目团队需要在分析阶段之前明确需求的范围，在需求文档被进一步细化之前. 当澄清范围及其影响时，包括应用架构，技术架构，人力架构，部署经理. 强调在系统生命周期其它后续阶段更改范围的风险. 已经定义了项目范围并得到客户的签署，范围会成为将来变更的基线，将在分析阶段被转化,收集&记录,签署&过度,优先，校验&确认,15,accenture 2008 all rights reserved,收集和记录：确定详细需求,高层需求将被用逐步细化，在分析阶段会细化成为应用导向的需求. 随着项目团队对客户业务的不读了解，应用需求变得越来越具体. 在初始开发周期获取详细应用需求的记录建议包括： 解决方案蓝图 度量 目前能力评估 原型 项目范围定义,收集&记录,签署&过度,优先，校验&确认,16,accenture 2008 all rights reserved,收集和记录：引出需求的技巧,关注团体 联合应用设计(jad)会议 竞争者在线能力分析 抽样调查 访谈 观察 场景构建/呈现 原型 关键流程演示 变更请求,requirements gathering technique handout,收集&记录,签署&过度,优先，校验&确认,17,accenture 2008 all rights reserved,收集和记录：将信息转换为需求,说明: 将下述客户提供的陈述转化为需求： “目前无法从下级界面直接回到主页，只能不断的点击回退按钮以到达主页；同时，搜索功能不足，只能按照汽车制造商进行搜索，应当可以按照颜色和车型进行搜索?”,收集&记录,签署&过度,优先，校验&确认,18,accenture 2008 all rights reserved,收集和记录：将信息转换为需求,以下是怎样将客户陈述转换为需求的例子：,“目前无法从次级界面直接回到主页，只能不断的点击回退按钮以到达主页；同时，搜索功能不足，职能按照汽车制造商进行搜索，应当可以按照颜色和车型进行搜索?”,主页应该能够从任何下级界面直接进入 客户可以根据汽车制造商进行搜索 客户可以根据汽车模型进行搜索. 客户可以根据汽车颜色进行搜索.,收集&记录,签署&过度,优先，校验&确认,19,accenture 2008 all rights reserved,收集和记录: 分类和清楚记载需求,5 个关键需求类别: 功能: 用户可以在系统上干什么或说系统可以为用户提供什么. 内容: 内容的类型和任何陈述约束. 技术: 需要满足的任何技术约束 性能: 用以描述系统速度的衡量指标. 可用性: 用户完成一项任务的难度.,source: “requirements development guidelines job aid,” accenture delivery methods,收集&记录,签署&过度,优先，校验&确认,20,accenture 2008 all rights reserved,收集和记录：附加的需求类别,项目: 描述项目开展的方式. 数据: 获取历史数据转换和集成. 安全和控制: 包括安全，机密，数据分类策略和内部控制. 集成: 明确哪一个应用和数据源需要被统一到总体的业务流程中. 质量: “非功能需求” 包括适应性和可靠性. 服务: 归纳出干系人承诺的需求，以利于转换成系统上线第一天的运作应用需求。,source: “requirements development guidelines job aid,” accenture delivery methods,收集&记录,签署&过度,优先，校验&确认,21,accenture 2008 all rights reserved,收集和记录: 记录好需求的规则,每一个需求必须: 正确: 代表着干系人的要求. 完整: 完整的表达一个想法或陈述. 清晰: 不含糊的. 一致: 不和其它需求矛盾，与详细程度一致. 可测试的: 系统要满足这些需求. 可追踪的: 可以唯一确认的. 可行的: 可以在成本和进度内完成，技术和法律上是可行的. 模块化的:可以在没有过度影响的条件下进行变更.,收集&记录,签署&过度,优先，校验&确认,22,accenture 2008 all rights reserved,收集和记录: 记载需求的附加指导方针,附加的指导方针包括：: 整体的需求需要详细说明一个需求得到的目标或者结果. 确保已经陈述的需求与其它需求抵触或重叠. 只定义对系统/应用必须的需求 用”必须“或者”应该“进行描述,收集&记录,签署&过度,优先，校验&确认,23,accenture 2008 all rights reserved,收集和记录: 不好需求的特征,模糊 避免使用”或者“，”等等“的措辞 思索 危险的措辞包括”通常”，“一般”，“京城”，“典型的”，“正常的”. 可能性的建议 应当决绝使用“可能”，“应该”，“或许”，“大概”，“也许”等术语”. 制造了例外条款 应避免使用“如果”，“但是”，“什么时候”，“除了”，“虽然”等,使用模糊的术语 避免使用描述，如“客户友好的”，“高度通用的”，“流动性好”，“最大程度的”，“合适的”，“尽快的”. 如意算盘 不要要求不可能的事情 - “100% 可靠”, “安全”, “处理所有的失败”, “保证”, “完全可升级的”, “在所有平台上运行”. 设计系统 危险的信号包括：组件的名称，材料，如见目标，领域和记录等.,好的习惯是建立一个通用的词汇表（例如术语表）来在开发过程和客户业务中获取有代表性的术语。这可以降低与同事，用户和干系人交流过程中可能的误解,收集&记录,签署&过度,优先，校验&确认,24,accenture 2008 all rights reserved,收集和记录： 获取需求的工具,讨论: 在你的项目中使用的获取需求的工具有哪些？ 工具: 需求表 requisitepro 使用案例模块 需求追踪矩阵 (rtm),收集&记录,签署&过度,优先，校验&确认,25,accenture 2008 all rights reserved,优先级，校验和确认：理解优先，校验和确认,分析需求包括区分优先级，校验和确认. 优先级，校验和确认流程是并行的，因此并不必然是顺序进行实施的. 优先级，校验和确认不断的反复完成，在设计和分析阶段及系统生命周期的过程中.,引出&记录,优先，校验&确认,签署&转化,26,accenture 2008 all rights reserved,优先级，校验和确认: 确定需求的优先级,与干系人一起确定需求的优先级: 愿景 范围 质量 风险 进度表 预算 根据标准来评估每个需求，例如: 实施需要的成本及付出程度 进度表，风险分析, 与终端用户的关系 与商业目标的关系 澄清需求： 定量的或根据类别,确定那些可能需要临时“work-around” 解方案的需求，例如, : 需要的具体能力没有包括在本次版本发布要求中 根据成本，优先级，软件升级等需要包括在下一次版本中. 确保适应性，通过清楚地说明哪一个特征可以延迟,引出&记录,优先，校验&确认,签署&转化,27,accenture 2008 all rights reserved,优先，校验和确认: 校验和确认需求,校验: 确保交付件满足具体的需求. 询问“我们是否正确” 举例: 定义逐步的制造流程为了制造一个安全和高质量的摩托车. 确认: 表明产品可以实现其使用目标. 询问“我们是否开发了正确的事情” 举例：: 制造摩托车：模拟和原型是否是一个摩托车，而不是汽车或者飞机的模拟？,引出&记录,优先，校验&确认,签署&转化,28,accenture 2008 all rights reserved,优先，校验和确认: 摘要,这两个动作有时就是指“确认” adm的 v-model合并了以下概念:,提醒:校验和确认会在生命周期中频繁的发生!,引出&记录,优先，校验&确认,签署&转化,29,accenture 2008 all rights reserved,签署和转化: 有效地签署和转化的步骤,聚集所有已有的需求并确认需求是可以追踪的 收集其它相关的“分析”交付件 跨文件和同行评审交付件以检查一致性 与干系人进行最终需求/分析交付件评审会议. 必要时进行修正. 正式向客户递交交付件的最终版本.,引出&记录,优先，校验&确认,签署&转化,30,accenture 2008 all rights reserved,签署和转化: 有效地签署和转化的步骤,获取书面或者电子版的批准 根据批准的“基线”需求比较将来可能的需求变更. 存档需求列表. 确定会议对客户和项目成员进行培训. 遵循需求管理流程.,引出&记录,优先，校验&确认,签署&转化,31,accenture 2008 all rights reserved,议程,欢迎 / 介绍 需求开发 需求管理,32,accenture 2008 all rights reserved,什么是需求管理？,需求或者范围管理是一个系统的过程，包括：识别，组织，交流和管理应用需求变更的过程.* 需求管理是确保项目的工作是满足根据主办方的业务需求，与项目预算，投入和时间进度一致所产生需求的流程.* 需求管理是在系统开发生命周期中不断进行的过程.*,*source: “requirements overview: processes and deliverables,” justine chiang, vijay purugulla, kamal, sinha, andrew white, may 2001,33,accenture 2008 all rights reserved,变更控制委员会概述,变更控制委员会【change control board (ccb)】 是一个对项目或交付件提议进行变更请求做出决定的委员会 变更控制委员会做出的所有决定通常是最终的 变更控制委员会由项目干系人组成，包括: 项目经理 配置经理或变更请求 (cr) 经理 客户需求经理 (可选) 架构师 (功能的，技术的，数据库) 合同经理,*source: /wiki/change_control_board,34,accenture 2008 all rights reserved,合同管理概述,合同管理管理与客户，厂商，合作伙伴及员工间的合同.*,*source: /wiki/contract_management,35,accenture 2008 all rights reserved,需求和范围管理的关键点：,需求和范围变更管理流程主要包括：: 为定义步骤，角色和责任：: 需求/范围变更请求 协调变更可能带来的影响分析 同意变更并开始实施 识别什么组成一个范围变更，什么不是 当新需求或需求变更产生时，需要对基线进行变更. 项目计划/单位运行模块或者配置管理计划交付件里记录了进行范围变更决策时的变更管理流程和责任.,36,accenture 2008 all rights reserved,需求管理&系统开发生命周期,需求基线,识别可能的变更/错误,记录变更/错误,分析 cr,确定 cr的结果,实施和迁移变更,升级文档/rtm 工具,关闭cr,需求/范围管理,注释: 这一流程与配置管理课程所述的流程,部署,分析,设计,开发,测试,计划,系统开发生命周期,支持,37,accenture 2008 all rights reserved,识别可能的变更,范围变更和基本需求变更可能在很多地方产生. 微小的需求变更通常不需要一个范围的变更. 理解范围变更: 项目需要专注许多方面，例如：成本，进度和资源. 变更请求涉及到基线的需要经过正规的需求/范围管理流程. 干系人需要能够识别一个新的需求或者对现有需求进行变更. 对变更的请求被成为“变更请求” (cr) ，包括对现有系统基线任何组件的变更请求.,38,accenture 2008 all rights reserved,记录变更,对于一个cr，发起人应该: 完成cr模板的填写 提供变更的理由 在模板的恰当部分填写技术，进度，成本，质量或（和）风险的影响. 识别变更是对”新特征“还是对”已有特征“.,39,accenture 2008 all rights reserved,分析cr,执行gap影响分析，并且识别对实施对项目需求的变更或者调查所需要的批准类型 在交付件中对需求的优先级进行，项目管理团队需要审阅所有的需求，确保： 能够识别不完整或者丢失的需求 需求之间的逻辑性 需求可能与现存的已经审阅过的交付件存在冲突,40,accenture 2008 all rights reserved,分析 cr,建立评估项目cr的标准: 标准举例: 变更的大小 (影响时间) 对相关系统而言，变更的复杂度 变更需要的时间 变更对目前及后续工作在技术，质量，风险，成本和进度上的影响,41,accenture 2008 all rights reserved,决定 cr的结果,项目管理办公室 (pmo) 或者变更控制委员会(ccb) 需要在变更实施前对其进行批准. pmo/c