需求分析和管理.pptVIP

?Accenture 2008 All Rights Reserved 需求开发和管理 * Agenda 欢迎 / 介绍 需求开发 需求管理 介绍 姓名 职责 期望 课程目标 在接受此培训模块后，将具备以下能力： 收集需求 检查需求描述是否恰当 分析需求 实施恰当的需求审批，需求传递和需求交流 管理需求和范围变更 建立和维护交付件以满足干系人的要求 什么是需求? 需求是: 用户为了解决问题或实现目标所需要的条件或能力.* 我们期望系统实现的功能，此功能对性能的要求是什么.* 需求不是: 定义怎样具体实现功能的规范条件. * Source: Institute of Electrical and Electronics Engineers-610 需求举例 以下是需求的例子： 系统必须允许用户通过汽车生产商进行搜索 系统必须能够支持30,000用户使用.* 以下则不是一个需求: 客户将能够使用单选按钮或输入框选择搜索标准. 描述需求的正确方式: 系统必须能够提供根据各种搜索标准进行的检索. * Source: Institute of Electrical and Electronics Engineers-610 正确需求的益处 讨论: 是否有过需求没有很好的被管理或者描述？? 原因是什么？ 可以进行哪些改变? 影响怎样？ 正确需求的益处 有效的需求开发和管理的益处包括: 降低项目成本: 修复需求缺陷比其它缺陷的成本高处10倍多 需求缺陷占据了软件项目所有缺陷中40%以上 需求缺陷很少的降低将得到很到的收益，因为避免了返工和进度延误 满足项目期限要求 维护项目范围 促进交流 满足客户需求 议程 欢迎 / 介绍 需求开发 需求管理 活动 Wrap - Up / Final QA 需求开发和系统开发生命周期 需求开发和系统开发生命周期 收集和记录: 从干系人开始 干系人是新（改进）的系统将对其产生影响的人 干系人包括：项目主办方，项目组成员，关键用户（SMEs），终端用户（其它员工），外部用户和客户，其供应商. 从干系人获取的重要信息： 愿景 业务功能/任务 期望 对改变和承诺的态度 能力 对其它干系人的影响 收集和记录: 获得高层需求 高层需求在计划阶段收集. 高层需求是最基本的业务需求，新系统需要实现的最低功能要求. 记录是确定高层需求的开始，记录的建议包括： 项目工作的阐明 RFP (对建议的请求) 建议 客户之前起草的高层需求 从干系人处获取的愿景及业务目标提取更多的高层需求 收集和记录: 确定项目范围 项目团队需要在分析阶段之前明确需求的范围，在需求文档被进一步细化之前. 当澄清范围及其影响时，包括应用架构，技术架构，人力架构，部署经理. 强调在系统生命周期其它后续阶段更改范围的风险. 已经定义了项目范围并得到客户的签署，范围会成为将来变更的基线，将在分析阶段被转化 收集和记录：确定详细需求 高层需求将被用逐步细化，在分析阶段会细化成为应用导向的需求. 随着项目团队对客户业务的不读了解，应用需求变得越来越具体. 在初始开发周期获取详细应用需求的记录建议包括： 解决方案蓝图 度量 目前能力评估 原型 项目范围定义 收集和记录：引出需求的技巧 关注团体 联合应用设计(JAD)会议 竞争者在线能力分析 抽样调查 访谈 观察 场景构建/呈现 原型 关键流程演示 变更请求 收集和记录：将信息转换为需求 说明: 将下述客户提供的陈述转化为需求： “目前无法从下级界面直接回到主页，只能不断的点击回退按钮以到达主页；同时，搜索功能不足，只能按照汽车制造商进行搜索，应当可以按照颜色和车型进行搜索?” 收集和记录：将信息转换为需求 以下是怎样将客户陈述转换为需求的例子： 收集和记录: 分类和清楚记载需求 5 个关键需求类别: 功能: 用户可以在系统上干什么或说系统可以为用户提供什么. 内容: 内容的类型和任何陈述约束. 技术: 需要满足的任何技术约束 性能: 用以描述系统速度的衡量指标. 可用性: 用户完成一项任务的难度. 收集和记录：附加的需求类别 项目: 描述项目开展的方式. 数据: 获取历史数据转换和集成. 安全和控制: 包括安全，机密，数据分类策略和内部控制. 集成: 明确哪一个应用和数据源需要被统一到总体的业务流程中. 质量: “非功能需求” 包括适应性和可靠性. 服务: 归纳出干系人承诺的需求，以利于转换成系统上线第一天的运作应用需求。 收集和记录: 记录好需求的规则 每一个需求必须: 正确: 代表着干系人的要求. 完整: 完整的表达一个想法或陈述. 清晰: 不含糊的. 一致: 不和其它需求矛盾，与详细程