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

内部资料 注意保密中国联通中国联通需求管理方法培训需求管理方法培训业务支撑部 2009年8月目录一、需求管理内容三、用户需求分析二、用户需求编制方法1、文档体系2、需求管理现状四、系统需求编制方法2 2中国联通需求文档体系软件需求 层次业务需求 用户需求软件需求分不同的层次和阶段：业务需求、用户需求和系统需求 需求分析人员 进行需求开发用户语言转换 成技术语言功能性需求非功能性需求环境和约束用户需求书系统需求系统需求规格说明书满 足用例方法条目化语言描述条目化语言描述3 3目录一、需求管理内容三、用户需求分析二、用户需求编制方法1、文档关系2、需求管理现状四、系统需求编制方法4 4需求管理现状Ø需求管理方法ü总部统一管理，省分及厂家抽调专家参与配合需求编制工作；Ø需求编制方式：ü对年度需求，采用封闭集中编制的方式；ü对应急需求，省分通过需求管理系统填报，总部审核处理；Ø需求编制流程：Ø 需求编制问题管理机制：ü 对需求编制过程中存在的问题进行记录，并跟踪问题解决情况；Ø 链接机制：ü 在需求书之间及需求书与问题集之间建立链接，可追溯需求的来源和去向.5 5需求管理内容展示总体内容用 户 需 求共有用户需求书26本，涵盖了CRM、Billing、PRM、综合采集和客服等内容6 6需求管理内容展示（续）用 户 需 求 点 对 点 分 析7 7需求管理内容展示（续）需求书名称用例数CRM909 Billing110PRM297客服系统199综合采集8共1523个用例系统需求规格书8 8需求管理内容展示（续）系 统 需 求 规 格 书 主 文 档 状 态 视 图9 9目录一、需求管理内容三、用户需求分析二、用户需求编制方法1、用户需求书模板2、编制方法四、系统需求编制方法1010用户需求书模板组织 机构名称组织 机构职责组织 机构涉及角色角色职责省分市场部负责 卡的计划创 建库管人员管理卡的实物库 存 省分财务 部负责 卡的帐务 管 理帐管人员总部市场部总部财务 部……用户需求文档结构图例流程图应严 格按图例要求画制，如确实缺失，可统一申报业务规则进行该项业务 要遵守的业务规则涉及数据该业务 流程环节 涉及的业务实 体机数据项1111编制方法Ø 修订类文档编制过程：Ø 新增类文档编制过程：按照差异 对比表找到差异点专家进行差异解释对照原有文档 讨论差异处理方法记录处理结果 并修订原有文档文档审核形成文档对已有文档进行讲解传达最新修改意见讨论后，确认修改内容记录处理结果， 完成新增文档文档审核形成新增文档差异处理结果类型 1.统一 2.修改后统一 3.修改后保留 4.保留 5.删除编制工作在word修订模式下进行1212Ø 工作内容ü交叉评审ü专家评审ü各组根据评审意见，修订用户需求书Ø 工作方式ü评审过程中所遇问题填写“项目评审问题管理模板”Ø 工具、模板ü项目评审问题管理模板Ø 输出成果1.用户需求书用户需求书评审1313目录一、需求管理内容三、用户需求分析二、用户需求编制方法四、系统需求编制方法1414用户需求分析Ø用户需求分析：即工程实施应答，在用户需求书编制完成后，对用户需 求逐条进行分析，判断其是否为需求点，需要系统支撑实现； Ø在用户需求点对点分析视图下进行，该视图主要属性如下：是否需求点区分是需求书中描述性的语言，还是真正需要追踪的需求点 ，必填项版本号本次需求版本修订状态表明该需求和上一次下发相比现在的修订状态，枚举型（不变，删除 ，新增，修改 ），在下个版本前，重置为“不变”统一管理程度判断是统一需求，还是省分保留需求对应 系统需要涉及或影响的系统，可多选实施阶段实现 的阶段支持程度枚举型，判断是支持、细化支持、暂不支持工程实施说明需要特别说 明的事项1515点对点分析视图1616练习1717目录一、需求管理内容三、用户需求分析二、用户需求编制方法四、系统需求编制方法1、系统需求规格书主文档2、系统需求规格书3、用例识别及编制方法1818全国统一需求规格说明书主文档样例1919系统需求规格书主文档•系统需求规格书主文档：系统需求规格书的目录或索引 ，由用例名称、用例描述组成。

系 统 需 求 规 格 书 主 文 档 状 态 视 图2020系统需求规格书的构成全国统一BSS系统需求规格书统一功能性需求（统计报表除外）统一非功能性需求统一接口需求用例方法条目化语言描述条目化语言描述通过对用户需求书进行详细的需求分析，形成全国统一的BSS系统需求规格书2121系统需求规格书Ø 系统需求规格书：由多个用例组成，与主文档中的 用例目录一一对应2222目录一、需求管理内容三、用户需求分析二、用户需求编制方法四、系统需求编制方法1、系统需求规格书主文档2、系统需求规格书3、用例识别及编制方法2323用例方法：主要建模元素Ø用例（Use Case）:用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话Ø参与者（Actor）:参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境Ø事件流（Event flow）：对用例的具体描述是通过事件流来详细进行说明的事件流反映了系统的使用者期望与系统交互的流程，事件流又分为基本流（系统正常使用下的流程）和备选流（系统在特定情况下的分支流），基本流和备选流的组合反映了系统在使用过程中的真实场景。

Ø前置条件：执行用例前，系统所处的状态Ø后置条件：执行用例之后，系统所处的状态2424用例方法：特点和优势用例具有以下的特点（优点）：Ø 给出了需求的上下文：谁使用，在什么条件下使用，如何使用Ø 容易理解：尽量采用用户理解的语言Ø 易于重用：是设计、测试及系统相关文档的基础用例方法：发现参与者系统的参与者定义了系统的边界，可从以下几方面发现系统的参与者：Ø谁使用系统？Ø谁从系统获取信息？Ø谁向系统提供信息？Ø系统在什么地方使用？Ø谁支持或维护系统？Ø有没有其它的系统使用该系统？用例方法：识别用例从参与者的角度出发发现用例，以下问题有助于发现 用例： Ø 参与者希望怎样使用该系统？ Ø 参与者希望创建、存储、修改、删除系统的数据吗？ Ø 当外部事件发生变化时，参与者需要通知系统吗？ Ø 参与者希望被告知系统内部发生的变化吗？定义用例：基本流和备选流基本流与备选流： Ø 基本流是该用例的一个主要的使用场景，一个用例只有一个基 本流 Ø 备选流是在基本流之上的有条件的分支，备选流结束后，要么 返回到基本流，要么导致该用例结束定义用例：场景（Scenario）场景是指从流程的起点开始，直到某个终点的一串流程细化用例：细化基本流细化基本流要点： •采用参与者与系统交互的语言进行描述。

•参与者与系统交互的行为要明确，包括交互的信息 （数据），系统处理所要遵守的业务规则，系统处 理过程中与其它系统的接口，当然，数据、规则、 接口如果有地方统一描述的话，引用即可细化用例：细化备选流细化备选流要点： •起始位置：写明备选流在基本流中的起始位置 •条件：写明分支的条件 •动作：通过交互式语言写明备选流处理的动作 •恢复：备选流结束后要么回到基本流的某一步，要 么导致用例终止注：异常流也可视为一种特殊的备选流）细化用例：前置/后置条件•前置条件是执行用例之前系统必须存在的一组状态，注 意： • 前置条件不是触发该用例的事件• 前置条件有助于减少事件流描述中的一些校验 • 前置条件不描述系统之外的事情，如“客户有一个有效的 SIM卡” • 前置是可选的仅在需要时描述• 后置条件是用例一执行完毕后系统可能处于的一组状态 ： •后置条件也是可选的，仅在需要时描述细化用例：要点总结•描述对参与者可见的事件（参与者做什么，系统做什么 ） •用例必须提供参与者可见的结果 •用例有不同的精细程度，细化到所有涉众对需求有共同 的理解为止 •采用公用的术语和词汇 •使用明确的语言基于联通需求 丰富用例方法•丰富事件流的描述方法，细化区分： •系统功能需求 •系统的数据处理需求：展现数据、存储数据 •系统要处理的业务规则 •将后台处理需求统一到用例描述中 •使用与事件流相似的方式描述后台处理流程 •对于每个处理步骤，细化区分： • 功能 • 输入数据 • 输出数据 • 业务规则结构化用例描述•用例之间的关系： –包含关系（include）:基础用例会用到被包含的用 例；也就是被包含的用例的事件流一定会插入到 基础用例的事件流中。

–扩展关系（extend）:基础用例(Base)中定义有一 至多个已命名的扩展点，扩展关系是指将扩展用 例(Extension)的事件流在一定的条件下按照相应 的扩展点插入到基础用例(Base)中 ，扩展用例的 事件流会被有条件地引用•参与者之间的关系： –参与者的继承3535编写用例的步骤•第一步：发现用例，通过对业务进行分析，提取系统所要完 成的“事务性”的功能，并形成用例 •第二步：简要描述，对该用例所要完成的功能进行简要描述 •第三步：编写用例大纲，概括出系统处理的主要步骤（基本 流），并进行编号 •第四步：细化用例针对基本流中的主要步骤，采用参与者 与系统交互的语言进行详细描述，并增加备选流、前后置条 件、特殊需求等编写用例纲要步骤编写用例流程步骤要点： •列出基本流的主要处理步骤 •对基本流的处理步骤进行编号 •列出可能的备选流。