中国联通需求管理方法培训

内 部 资 料 注 意 保 密 中国联通 需求管理方法培训 业务支撑部 2009年 8月 1 目录 一、需求管理内容 三、用户需求分析 二、用户需求编制方法 1、文档体系 2、需求管理现状 四、系统需求编制方法 2 中国联通需求文档体系 软件需求 层次 业务需求 用户需求 软件需求分不同的层次和阶段：业务需求、用户需求和系统需求 需求分析人员 进行需求开发 用户语言转换 成技术语言 功能性需求 非功能性需求 环境和约束 用户需求书 系统需求 系统需求规格说明书 满 足 用例方法 条目化语言描述 条目化语言描述 3 目录 一、需求管理内容 三、用户需求分析 二、用户需求编制方法 1、文档关系 2、需求管理现状 四、系统需求编制方法 4 需求管理现状 需求管理方法 总部统一管理 ， 省分及厂家抽调专家参与配合需求编制工作； 需求编制方式： 对年度需求 ， 采用封闭集中编制的方式； 对应急需求 ， 省分通过需求管理系统填报 ， 总部审核处理； 需求编制流程： 用 户 需 求 用 户 需 求 点 对 点 分 析 系 统 需 求 主 文 档 编 制 系 统 需 求 规 格 书 编 制 需求编制问题管理机制： 对需求编制过程中存在的问题进行记录 ， 并跟踪问题解决情况； 链接机制： 在需求书之间及需求书与问题集之间建立链接 ， 可追溯需求的来源和去向 . 5 需求管理内容展示 总体内容 用户需求 共有用户需求书 26本，涵盖了 CRM、 Billing、 PRM、综合采集和客服等内容 6 需求管理内容展示（续） 用户需求点对点分析 7 需求管理内容展示（续） 需求书名称 用例数 CRM 909 Billing 110 PRM 297 客服系统 199 综合采集 8 共 1523个用例 系统需求规格书 8 需求管理内容展示（续） 系统需求规格书主文档状态视图 9 目录 一、需求管理内容 三、用户需求分析 二、用户需求编制方法 1、用户需求书模板 2、编制方法 四、系统需求编制方法 10 用户需求书模板 组织机构名称 组织机构职责 组织机构涉及角色 角色职责 省分市场部 负责卡的计划创建 库管人员 管理卡的实物库存 省分财务部 负责卡的帐务管理 帐管人员 总部市场部 总部财务部 用户需求文档结构 图例 流程图应严格按图例要求画制 ， 如确实缺失 ， 可统一申报 业务规则 进行该项业务要遵守的业务规则 涉及数据 该业务流程环节涉及的业务实体机数据项 11 编制方法 修订类文档编制过程： 新增类文档编制过程： 按照差异 对比表找到差异点 专家进行差异解释 对照原有文档 讨论差异处理方法 记录处理结果 并修订原有文档 文档审核 形成文档 对已有文档进行讲解 传达最新修改意见 讨论后，确认修改内容 记录处理结果， 完成新增文档 文档审核 形成新增文档 差异处理结果类型 1.统一 2.修改后统一 3.修改后保留 4.保留 5.删除 编制工作在 word修订模式下进行 12 工作内容 交叉评审 专家评审 各组根据评审意见 ， 修订用户需求书 工作方式 评审过程中所遇问题填写 “ 项目评审问题管理模板 ” 工具 、 模板 项目评审问题管理模板 输出成果 用户需求书 用户需求书评审 13 目录 一、需求管理内容 三、用户需求分析 二、用户需求编制方法 四、系统需求编制方法 14 用户需求分析 用户需求分析：即工程实施应答 ， 在用户需求书编制完成后 ， 对用户需求逐条进行分析 ， 判断其是否为需求点 ， 需要系统支撑实现； 在用户需求点对点分析视图下进行 ， 该视图主要属性如下： 是否需求点 区分是需求书中描述性的语言 ， 还是真正需要追踪的需求点 ， 必填项 版本号 本次需求版本 修订状态 表明该需求和上一次下发相比现在的修订状态 ， 枚举型 （ 不变 ， 删除 ，新增 ， 修改 ） ， 在下个版本前 ， 重臵为 “ 不变 ” 统一管理程度 判断是统一需求 ， 还是省分保留需求 对应系统 需要涉及或影响的系统 ， 可多选 实施阶段 实现的阶段 支持程度 枚举型 ， 判断是支持 、 细化支持 、 暂不支持 工程实施说明 需要特别说明的事项 15 点对点分析视图 16 练习 17 目录 一、需求管理内容 三、用户需求分析 二、用户需求编制方法 四、系统需求编制方法 1、系统需求规格书主文档 2、系统需求规格书 3、用例识别及编制方法 18 全国统一 需求规格说明书主文档样例 19 系统需求规格书主文档 系统需求规格书主文档：系统需求规格书的目录或索引 ，由用例名称 、 用例描述组成 。 系统需求规格书主文档状态视图 20 系统需求规格书的构成 全国统一 BSS系统需求规格书 统一功能性需求 （统计报表除外） 统一非功能性需求 统一接口需求 用例方法 条目化 语言描述 条目化 语言描述 通过对用户需求书进行详细的需求分析，形成全国统一的 BSS系统需求规格书 21 系统需求规格书 系统需求规格书：由多个用例组成 ， 与主文档中的用例目录一一对应 。 22 目录 一、需求管理内容 三、用户需求分析 二、用户需求编制方法 四、系统需求编制方法 1、系统需求规格书主文档 2、系统需求规格书 3、用例识别及编制方法 23 用例方法：主要建模元素 用例 （ Use Case） :用例用于表示系统所提供的服务 ， 它定义了系统是如何被参与者所使用的 ， 它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 。 参与者 （ Actor） :参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统 ， 他们代表的是系统的使用者或使用环境 。 事件流 （ Event flow） ：对用例的具体描述是通过事件流来详细进行说明的 。事件流反映了系统的使用者期望与系统交互的流程 ， 事件流又分为基本流（ 系统正常使用下的流程 ） 和备选流 （ 系统在特定情况下的分支流 ） ， 基本流和备选流的组合反映了系统在使用过程中的真实场景 。 前臵条件：执行用例前 ， 系统所处的状态 。 后臵条件：执行用例之后 ， 系统所处的状态 。 用例方法：特点和优势 用例具有以下的特点（优点）： 给出了需求的上下文：谁使用，在什么条件下使用，如何使用。 容易理解：尽量采用用户理解的语言。 易于重用：是设计、测试及系统相关文档的基础。 用例方法：发现参与者 系统的参与者定义了系统的边界，可从以下几方面发 现系统的参与者： 谁使用系统？ 谁从系统获取信息？ 谁向系统提供信息？ 系统在什么地方使用？ 谁支持或维护系统？ 有没有其它的系统使用该系统？ 用例方法：识别用例 从参与者的角度出发发现用例，以下问题有助于发现 用例： 参与者希望怎样使用该系统？ 参与者希望创建、存储、修改、删除系统的数据吗？ 当外部事件发生变化时，参与者需要通知系统吗？ 参与者希望被告知系统内部发生的变化吗？ 定义用例：基本流和备选流 基本流与备选流： 基本流是该用例的一个主要的使用场景，一个 用例 只有一个基本流。 备选流是在基本流之上的有条件的分支，备选流结束后，要么返回到基本流，要么导致该用例结束。 定义用例：场景（ Scenario） 场景是指从流程的起点开始，直到某个终点的一串流程 细化用例：细化基本流 细化基本流要点： 采用参与者与系统交互的语言进行描述。 参与者与系统交互的行为要明确，包括交互的信息（数据），系统处理所要遵守的业务规则，系统处理过程中与其它系统的接口，当然，数据、规则、接口如果有地方统一描述的话，引用即可。 细化用例：细化备选流 细化备选流要点： 起始位置：写明备选流在基本流中的起始位置 条件：写明分支的条件。 动作：通过交互式语言写明备选流处理的动作。 恢复：备选流结束后要么回到基本流的某一步，要么导致用例终止。 （注：异常流也可视为一种特殊的备选流） 细化用例：前置 /后置条件 前置条件是执行用例之前系统必须存在的一组状态，注意： 前置条件不是触发该用例的事件。 前置条件有助于减少事件流描述中的一些校验 。 前置条件不描述系统之外的事情，如 “ 客户有一个有效的SIM卡 ” 。 前置是可选的。仅在需要时描述。 后置条件是用例一执行完毕后系统可能处于的一组状态 ： 后置条件也是可选的，仅在需要时描述。 细化用例：要点总结 描述对参与者可见的事件（参与者做什么，系统做什么）。 用例 必须提供参与者可见的结果。 用例 有不同的精细程度，细化到所有涉众对需求有共同的理解为止。 采用公用的术语和词汇。 使用明确的语言。 基于联通需求 丰富用例方法 丰富事件流的描述方法，细化区分 ： 系统功能需求 系统的数据处理需求：展现数据、存储数据 系统要处理的业务规则 将后台处理需求统一到用例描述中 使用与事件流相似的方式描述后台处理流程 对于每个处理步骤，细化区分： 功能 输入数据 输出数据 业务规则 34 结构化用例描述 用例之间的关系 ： 1) 包含关系 （ include） :基础用例会用到被包含的用例；也就是被包含的用例的事件流一定会插入到基础用例的事件流中 。 2) 扩展关系 （ extend） :基础用例 (Base)中定义有一至多个已命名的扩展点 ， 扩展关系是指将扩展用例 (Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例 (Base)中 ， 扩展用例的事件流会被有条件地引用 。 参与者之间的关系： 1) 参与者的继承 编写用例的步骤 第一步： 发现用例，通过对业务进行分析，提取系统所要完成