手机需求工程

CMM系列教程 EPG 手机需求工程新员工培训 手机事业部 陈平 2005年 3月 EPG 2 一个关于需求的著名的图 EPG 3 提纲 需求工程的意义 需求工程与过程 需求开发的主要活动 需求管理的主要活动 如何做好手机需求工作 EPG 4 需求是项目成功的核心 需求 制定项目计划 过程 项目跟踪和 控制过程 变更控制过程 系统测试过程 编制用户文档 过程 构造过程 作为输入 基线确定前 缩小范围 跟踪状态 请求范围 缩减 进行变更 作为基线 作为参考 验证实现的正确性 基础 工作产品 可追溯到 基础 EPG 5 令人沮丧的数字 美国 Standish Group（ 1994）的调查结果显示： 31%的项目被中途取消 52%的项目超支 89% 大公司 91%的项目不能按时按预算完工 小公司 84%的项目不能按时按预算完工 EPG 6 需求规格5 0管理顾客需求45产品需求管理和测试3 2项目管理3 0编码7项目出麻烦的主要原因 需求缺陷修改成本占返工成本总额的 70% 需求缺陷可轻易消耗 25%-40%的项目预算 EPG 7 造成项目失败的需求原因 主要因素： 缺少用户输入（ 13），不完备的需求（ 12），需求的变更（ 12） 在需求阶段发现错误与在维护阶段发现错误的费效比是 1： 200 需求错误往往是项目中发现的最大一类错误 占 41 56 返工所需开销一般占项目总费用的 45 EPG 8 什么是需求？ 系统必须具有的能力 IEEE软件工程标准词汇表中的定义 (1997)： 用户解决问题或达到目标所需的条件和能力 （ Capability）； 系统和系统部件要满足合同、标准、规范和其他正式规定文档所需具有的条件或能力； 及满足以上条件或能力的文档说明。 另解 需求是指“被描述对象（待研发对象）”做什么（功能需求）及“做什么”时的水平（非功能需求，如性能需求、质量属性需求、外部接口需求、其它需求） EPG 9 客户 customer 指个人或组织 ， 他们为产品开发提供资金 ， 通常还提出各种需求 。 客户和开发者也可能是同一个组织的成员 。 用户 user 使用可操作的系统完成一项特定的功能的个人或机构（可以是买主和需方的同义词。） 用户与客户 EPG 10 需求的层次 原始需求 :未经分析或规格化的来自用户或者外部环境等的需求。 业务需求 : 表示组织或客户高层的目标 用户需求 指用户、客户以及其他对项目或者系统有兴趣的组织和个人的期望、要求、约束（标准规范、行业产品惯例等）等 用于反映市场、客户需要，作为和客户沟通、签订合同、定义项目职责、权限和范围的基础。 用户使用产品必须要完成的任务 产品需求 对产品应具有的形状、功能、性能以及其他需求的详细说明 定义了开发人员必须实现的功能，使得用户能完成他们的任务 作为设计、编码、测试等产品开发活动的基础。 传统上产品需求包括系统需求和子系统需求，如软硬件需求和结构需求等。 EPG 11 需求的种类 产品需求 功能需求 开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。 系统展现给用户的行为和执行的操作等。 质量属性需求（非功能需求） 产品必须满足的质量和能力要求。如性能、可靠性等等。 非技术需求 时间、资源、人、财、物等 EPG 12 提纲 需求的意义 需求工程与过程 需求的概念 需求开发的主要活动 需求管理的主要活动 如何做好手机需求工作 EPG 13 需求工程 需求开发 需求收集 需求论证、分析 需求描述 需求验证 需求管理 需求版本管理（基线化、版本控制） 需求追踪 需求状态跟踪 需求变更控制 EPG 14 需求工程的目的 做出高质量而非完美的需求 用户解决问题或达到目标 EPG 15 需求工程主要过程关系 需求开发过程域 需求分析 产品需求定义 原始需求收集 用户需求说明书 研制规范、子系统需求文档 需求管理过程域 需求追踪、需求状态跟踪跟踪 需求确认（基线化） 需求变更控制 用户需求定义 需求追踪矩阵、需求状态跟踪表 $ 复用库 需求验证 基线化的需求文档 EPG 16 需求过程不当会带来什么？ 产品很难被接受 过度耗费和产品质量的降低 时间的浪费和返工 遗漏某些关键需求 忽略用户分类导致众多客户不满 项目计划和跟踪无法准确进行 EPG 17 好的需求过程又会带来什么？ 明显减少在开发后期和整个维护阶段的返工工作量 需求渠道畅通，工作效率高 方法和技术的有效应用 降低了需求变更的负面影响 利于系统测试，确保产品质量。 EPG 18 提纲 需求工程的意义 需求工程与过程 需求的概念 需求开发的主要活动 原始需求收集 需求论证与分析 需求描述 需求验证 需求管理的主要活动 如何做好手机需求工作 EPG 19 原始需求收集 确定和理解不同用户类的需要和限制的过程 需要 高度合作的 活动 具有应用领域知识的用户（客户） 具有实现领域知识的开发者 在问题及其最终解决方案之间架设桥梁的第一步 由总工组织，所有项目干系人都参与的活动 EPG 20 收集需求的步骤 确定需求的来源 确定客户代表 选择需求收集方法 收集需求 记录需求 EPG 21 提纲 需求工程的意义 需求工程与过程 需求的概念 需求开发的主要活动 原始需求收集 需求论证与分析 需求描述 需求验证 需求管理的主要活动 如何做好手机需求工作 EPG 22 需求论证与分析 需求论证 通过对需求的关键程度、资源、重要性、可行性、风险等属性的分析确认 需求分析 需求转换的过程。 7+4原则 由项目经理、系统工程师或开发组长组织 EPG 23 提纲 需求工程的意义 需求工程与过程 需求的概念 需求开发的主要活动 原始需求收集 需求论证与分析 需求描述 需求验证 需求管理的主要活动 如何做好手机需求工作 EPG 24 需求描述的重要性 需求描述是 支持有效沟通的必要手段 需求开发的结果 需求管理的对象 系统设计 /概要设计的基础与依据 系统测试的依据 由项目经理、系统工程师或开发组长组织 EPG 25 好的需求说明书应具有的特征 1 完整性。不能遗漏任何必要的需求信息。注重用户的任务而不是系统的功能将有助于提高完整性。在通过评审前，必须解决需求中所有的 TBD（ to be defined）项 *。 2 一致性。一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在评审通过前必须解决所有需求间的不一致部分。 3 可修改性。在必要时或为维护每一需求变更历史记录时，应该修订需求文档。这就要求每项需求要 独立 标出，并与别的需求区别开来；每项需求只应在需求文档中出现一次，这样更改时易于保持一致性。 4 可追踪性。应能在每项需求与它的根源和设计元素、源代码、测试用例之间建立起追踪关系，这种可追踪性要求每项需求以一种结构化的，粒度好（ fine-grained）的方式编写并单独标明，而不是大段大段的叙述。 EPG 26 好的单条需求的描述应具有的特征 完整性。每一项需求都必须将所要实现的功能描述清楚，以使设计与开发人员获得设计和实现这些功能所需的所有必要信息。 正确性。每一项需求都必须准确地陈述其要开发的功能，判断依据为用户或系统需求说明。 可行性。每一项需求都必须是在已知系统和环境的能力(capability)和限制范围内可以实施的。 必要性。每一项需求都应能追踪到某项客户的输入，如 use case或别的来源。这就要求我们将客户真正所需要的和最终系统所需遵从的标准记录下来以便跟踪。 划分优先级。给每项需求分配一个优先级以指明它在特定产品中所占的分量。 无二义性。对所有需求说明的读者都只能有一个明确统一的解释。 可验证性。检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。 EPG 27 提纲 需求工程的意义 需求工程与过程 需求的概念 需求开发的主要活动 原始需求收集 需求论证与分析 需求描述 需求验证 需求管理的主要活动 如何做好手机需求工作 EPG 28 基本概念 确认 在开发的整个过程或者过程结束时，评估系统或者组件，确定它是否满足给定的需求的过程。（ IEEE1012-1986) “做正确的事” 验证 评估一个系统或模块以决定其在特定阶段的产出物满足在该阶段开始时的初始条件的过程 “正确的做事” EPG 29 验证与确认 时间 系统测试用例 集成测试用例 单元测试用例 详细设计和单元测试计划 体系结构和集成测试计划 产品需求和系统测试计划 用户需求和验收测试计划 验收测试 用例 需求验证 验证需求本身的正确性 需求确认 确认最终的产品是否适当地满足了需求 由项目经理、系统工程师或开发组长组织，委托 QA监督，各测试实施部门执行 EPG 30 需求验证 验证 需求是完整的和高质量的 所有需求都是一致的 所描述的需求对继续产品设计、构造和测试提供了足够的基础 需求是可验证的 主要验证技术 正式和非正式的评审 注意事项 不仅仅是一个独立的阶段 进入审查的工作产品应该有进入条件 EPG 31 提纲 需求工程的意义 需求工程与过程 需求的概念 需求开发的主要活动 需求管理的主要活动 如何做好手机需求工作 EPG 32 需求管理 目的： 维护需求 保持计划、产品和活动与指定给的需求一致 需求管理活动 建立需求的基线 确保需求作为开发、计划和工作产品的基础 控制需求变更 EPG 33 需求管理详细活动 制定需求管理计划 建立并维护需求基线 需求追踪 跟踪需求状态 处理需求变更 EPG 34 制定需求管理计划 需求管理 配置管理 开发过程 评审 保证需求管理所需的人力、时间和资源 在项目计划中规划需求管理 主要包括如下内容： 产品的需求管理范围 需求管理活动具体安排及其责任人 被管理的工作产品以及产品元素 需求的状态定义和状态转换条件 需 求管理工具 注意需求管理和其他管理活动的重叠 EPG 35 需求基线 描述 将 需求文档作为配置项纳入配置管理。 当需求通过评审后，为之建立基线 需求文档经过正式批准或同意 作为下一步开发的基础 只有通过正式管理步骤才能修改 EPG 36 需求追踪 描述 在需求、设计、实现、单元测试、集成测试、系统测试等工作产品间建立追踪关系，以判断上下游工作产品间有无遗漏与“镀金”，即验证相互间的一致性、“匹配性”。 提示 是衡量下游工作产品完成程度的一个重要工具。 是实现工作产品彼此间保持一致的重要手段。 是变更影响分析中确定波及范围的重要依据。 EPG 37 需求追踪 需求号 描述 设计 实施 单元测例 系统测例 验收测例 FR1.1.2 数据集合加亮显示 5.3.2 PB405 #12 #46 #11 SQL203 #32 #47 #11 TRACING AND TRACABILITY 需求和需求，需求和设计，实施，测试等环节的对应关系。 EPG 38 定义追踪关系 (Links) 业务需求 系统需求 软件需求 硬件需求 体系结构 单元设计 单元测例 集成测例 原理图 PCB图 系统测例 直接追踪 间接追踪 前向追踪 后向追踪 EPG 39 需求状态跟踪 描述 定义项目生命周期中所关心的需求状态； 定期或事件驱动地跟踪每个需求的状态、状态分布及其变化趋势。 提示 需求状态跟踪结果是判断项目进展的很客观的依据。 正确的需求追踪矩阵可大幅减少需求状态跟踪的工作量，并提高跟踪结果的正确性。 EPG 40 需求的状态 (STATUS) 已建议 已批准 已拒绝 已实现 已 确认 已交付 已删除 每个状态的背后都有一个驱动事件。 推荐的需求状态 已挂起 EPG 41 需求状态跟踪的输出 需求状态记录 在 项目状态跟踪报告 中报告 需求状态分布 需求变更（增、删、改）数量 关键或受关注的需求的状态及近期变更历史 EPG 42 需求变更需求为什么会变化？ 外部原因： 问题变化了； 用户的想法变化了； 外部环境变化了； 出现了新系统 内部原因 我们没能在正确的时间向正确的人提出正确的问题； 我们没能创建一个实用的过程来管理需求变更 EPG 43 典型的失控变更 我们遇到了敌人，但他们是我们自己。 顾客直接对程序员提需求 出于对领导意见的尊重 错误被交付给用户，不得不支持 对竞争对手的“膝跳反应” 程序员添加的“对顾客有宝贵好处”的产品行为 程序员为调试、提高技艺或者解闷而加入的功能 EPG 44 管理需求变更 识别不可避免的变更，为之制定计划 建立需求基线 建立唯一的变更通道 利用变更控制系统 建立严谨的变更结构 EPG 45 唯一的变更通道 变更必须有“官方”批准。 成立配置控制委员会（ CCB）来批准变更 这些人足够代表各方利益 这些人有较大责任 这些人有足够的权威 这些人有足够的技术能力批准变更 CCB可能只包括项目经理或技术领头人 EPG 46 变更控制流 变更防火墙 变更申请系统 实施决策 需求 设计 代码 测试 顾客和用户 市场 开发 测试 其他 计划 CCB职责 EPG 47 实施需求变更 更改计划 指派实施人和验证人 实施变更 验证变更 定期跟踪 结束 是否不了了之？ 是否敷衍了事？ 是否资源充足？ 是否自生自灭？ 建立新基线 EPG 48 建议的变更是否与基线中现有需求冲突 ? 建议的变更是否与其他未处理完的需求相冲突 ? 如不采纳这一变更 , 会有什么样的业务和技术后果 ? 采纳变更可能有什么样的负面影响或其他风险 ? 建议的变更是否对性能需求或其他质量属性产生不利的影响 ? 建议的变更在目前的技术约束和技术能力下是否可行 ? 建议的变更是否对开发 , 测试或运行环境的计算机资源提出了不能接受的要求 ? 实现和测试这些变更是否要额外的工具 ? 项目计划中 , 建议的变更如何影响任务的执行顺序 , 依赖性 , 工作量或进度 ? 建议的变更是否要制作原型或提供其他的用户意见 ? 接受 变更会浪费多少已在项目中投入的工作量 ? 变更是否会使产品的单位成本增加 ? 如增加了第三方产品使用许可证的费用 变更是否会影响任何市场 , 生产 , 培训或客户支持计划 ? EPG 49 提纲 需求工程的意义 需求工程与过程 需求的概念 需求开发的主要活动 需求管理的主要活动 如何做好手机需求工作 EPG 50 个性化、时尚化、面向普通消费者、受消费心理影响大、对外观造型需求难以把握 市场化程度高、需求易变、需求离散度较大 项目小，同类型号手机需求关联性大（产品队列特点） 没有纯软件项目、结构和软硬件一样重要 研发周期短，对需求开发质量要求高 需求持续化，没有明显的需求集中收集过程，更注重日常收集与跟踪 手机事业部需求特点 EPG 51 流程 了解 : 手机需求工程资产 手机需求流程 CMM系列教程 EPG 资产 EPG 53 资产 公司有关需求的一些模板等在 : NOTES21上的“公司企业标准”上 : NOTES_SVR21/COMMON/企业标准 .nsf “ 05研发 /05研发项目管理 /一般项目”下的 : 研发项目管理 -需求开发与管理 标准编号 : Q/ZX 73.1090. 4-2004 发布日期 : 2004-10-12 实施日期 : 2004-10-15 EPG 54 资产 包括以下文档和模板 : 7310904-2004 研发项目管理 需求开发与管理 7310904-2004 附件 2 研制规范 7310904-2004 附件 3 软件需求说明书 7310904-2004 附件 1 用户需求说明书 QR 7310904-2004-01 用户需求说明书检查单 QR 7310904-2004-02 研制规范评审检查单 QR 7310904-2004-03 软件需求说明书评审检查单 EPG 55 资产 研发项目管理 需求开发与管理 本标准规定了公司研发产品的需求开发与管理过程 。 本标准适用于公司产品的需求开发和管理过程 定义了 : 术语和定义 脚色和职责 总则 工作流程 规程详述 剪裁说明 EPG 56 资产 用户需求说明书检查单 研制规范评审检查单 软件需求说明书评审检查单 说明了评审准则 ,重点关注和技巧 EPG 57 资产 手机需求文档分为以下几大类 : 组织策略 手机事业部需求工程指导书 需求工作检查单 计划 需求管理计划 项目计划 用户需求 手机用户需求说明书 固定台用户需求说明书 网卡用户需求说明书 系统需求 手机研制规范 研制规范评审检查单 手机造型 /结构设计需求说明书 EPG 58 资产 子系统需求 软件需求说明书 软件接口说明书 软件需求说明书检查单 部件需求说明书 手机充电器新项目开发需求表 追踪 XX手机需求追踪表模板 培训 需求工程 .PPT EPG 59 资产 手机原始需求库 : NOTES_SVR4/appdb/CMM_RMCollect.nsf 参考文档 : 手机事业部原始需求库设计说明 .doc 手机事业部原始需求库使用参考 .doc 原始需求库处理 .ppt 事业部奖励政策 : 中兴通讯手机 2004 技字第 004号 EPG 60 资产 奖励措施：每季度，由技术部组织系统工程组对库中提交的需求进行评选。按季度分别设立一等奖 1个；二等奖 2个；三等奖 5个。奖励基金由受益的产品线承担，无受益产品线的由事业部承担。 特别奖 :奖金额为 3000元 l 一等奖：奖金额为 1000元。 l 二等奖：奖金额为 500元。 l 三等奖：奖金额为 200元。 奖金总额控制在 3000元（不计特等奖）。 对部