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

1、内 部 资 料内 部 资 料 注 意 保 密注 意 保 密业务支撑部业务支撑部2009年年8月月目录目录一、需求管理内容三、用户需求分析二、用户需求编制方法1、文档体系2、需求管理现状四、系统需求编制方法中国联通需求文档体系中国联通需求文档体系软件需求软件需求层次层次 业务需求业务需求 用户需求用户需求软件需求分不同的层次和阶段：业务需求、用户需求和系统需求软件需求分不同的层次和阶段：业务需求、用户需求和系统需求 需求分析人员进行需求开发用户语言转换成技术语言功能性需求功能性需求非功能性需求非功能性需求环境和约束环境和约束用户需求书用户需求书 系统需求系统需求系统需求规格说明书系统需求规格说明

2、书满满足足用例方法用例方法条目化语言描述条目化语言描述条目化语言描述条目化语言描述目录目录一、需求管理内容三、用户需求分析二、用户需求编制方法1、文档关系2、需求管理现状四、系统需求编制方法需求管理现状需求管理现状需求管理方法需求管理方法总部统一管理，省分及厂家抽调专家参与配合需求编制工作；总部统一管理，省分及厂家抽调专家参与配合需求编制工作；需求编制方式：需求编制方式：对年度需求，采用封闭集中编制的方式；对年度需求，采用封闭集中编制的方式；对应急需求，省分通过需求管理系统填报，总部审核处理；对应急需求，省分通过需求管理系统填报，总部审核处理；需求编制流程：需求编制流程：需求编制问题管理机制：

3、需求编制问题管理机制：对需求编制过程中存在的问题进行记录，并跟踪问题解决情况；对需求编制过程中存在的问题进行记录，并跟踪问题解决情况；链接机制：链接机制：在需求书之间及需求书与问题集之间建立链接，可追溯需求的来源和去向在需求书之间及需求书与问题集之间建立链接，可追溯需求的来源和去向.需求管理内容展示需求管理内容展示总体内容用户需求共有用户需求书26本，涵盖了CRM、Billing、PRM、综合采集和客服等内容需求管理内容展示（续）需求管理内容展示（续）用户需求点对点分析需求管理内容展示（续）需求管理内容展示（续）需求书名称需求书名称用例数用例数CRM909Billing110PRM297客服系

4、统199综合采集8共1523个用例系统需求规格书需求管理内容展示（续）需求管理内容展示（续）系统需求规格书主文档状态视图目录目录一、需求管理内容三、用户需求分析二、用户需求编制方法1、用户需求书模板2、编制方法四、系统需求编制方法用户需求书模板用户需求书模板组织机构名称组织机构名称组织机构职责组织机构职责组织机构涉及角色组织机构涉及角色角色职责角色职责省分市场部负责卡的计划创建库管人员管理卡的实物库存省分财务部负责卡的帐务管理帐管人员总部市场部总部财务部用户需求文档结构图例图例流程图应严格按图例要求画制，如确实缺失，可统一申报业务规则业务规则进行该项业务要遵守的业务规则涉及数据涉及数据该业务流

5、程环节涉及的业务实体机数据项编制方法编制方法 修订类文档编制过程：修订类文档编制过程： 新增类文档编制过程：新增类文档编制过程：按照差异对比表找到差异点专家进行差异解释对照原有文档讨论差异处理方法记录处理结果并修订原有文档文档审核形成文档对已有文档进行讲解传达最新修改意见讨论后，确认修改内容 记录处理结果，完成新增文档文档审核形成新增文档差异处理结果类型1.统一2.修改后统一3.修改后保留4.保留5.删除编制工作在word修订模式下进行 工作内容工作内容交叉评审交叉评审专家评审专家评审各组根据评审意见，修订用户需求书各组根据评审意见，修订用户需求书 工作方式工作方式评审过程中所遇问题填写评审过

6、程中所遇问题填写“项目评审问题管理模板项目评审问题管理模板” 工具、模板工具、模板项目评审问题管理模板项目评审问题管理模板 输出成果输出成果用户需求书用户需求书用户需求书评审用户需求书评审目录目录一、需求管理内容三、用户需求分析二、用户需求编制方法四、系统需求编制方法用户需求分析用户需求分析用户需求分析：即工程实施应答，在用户需求书编制完成后，对用户需用户需求分析：即工程实施应答，在用户需求书编制完成后，对用户需求逐条进行分析，判断其是否为需求点，需要系统支撑实现；求逐条进行分析，判断其是否为需求点，需要系统支撑实现；在用户需求点对点分析视图下进行，该视图主要属性如下：在用户需求点对点分析视图

7、下进行，该视图主要属性如下：是否需求点是否需求点区分是需求书中描述性的语言，还是真正需要追踪的需求点区分是需求书中描述性的语言，还是真正需要追踪的需求点 ，必填项，必填项版本号版本号本次需求版本本次需求版本修订状态修订状态表明该需求和上一次下发相比现在的修订状态，枚举型（不变，删除，表明该需求和上一次下发相比现在的修订状态，枚举型（不变，删除，新增，修改新增，修改 ），在下个版本前，重置为），在下个版本前，重置为“不变不变”统一管理程度统一管理程度判断是统一需求，还是省分保留需求判断是统一需求，还是省分保留需求对应系统对应系统需要涉及或影响的系统，可多选需要涉及或影响的系统，可多选实施阶段实施

8、阶段实现的阶段实现的阶段支持程度支持程度枚举型，判断是支持、细化支持、暂不支持枚举型，判断是支持、细化支持、暂不支持工程实施说明工程实施说明需要特别说明的事项需要特别说明的事项点对点分析视图点对点分析视图练习练习目录目录一、需求管理内容三、用户需求分析二、用户需求编制方法四、系统需求编制方法1、系统需求规格书主文档2、系统需求规格书3、用例识别及编制方法全国统一全国统一需求规格说明书主文档样例需求规格说明书主文档样例系统需求规格书主文档系统需求规格书主文档系统需求规格书主文档：系统需求规格书的目录或索引，系统需求规格书主文档：系统需求规格书的目录或索引，由用例名称、用例描述组成。由用例名称、用

9、例描述组成。系统需求规格书主文档状态视图系统需求规格书的构成系统需求规格书的构成全国统一全国统一BSSBSS系统需求规格书系统需求规格书统一功能性需求统一功能性需求（统计报表除外）（统计报表除外）统一非功能性需求统一非功能性需求统一接口需求统一接口需求用例方法用例方法条目化条目化语言描述语言描述条目化条目化语言描述语言描述通过对用户需求书进行详细的需求分析，形成全国统一的BSS系统需求规格书系统需求规格书系统需求规格书 系统需求规格书：由多个用例组成，与主文档中的系统需求规格书：由多个用例组成，与主文档中的用例目录一一对应。用例目录一一对应。目录目录一、需求管理内容三、用户需求分析二、用户需求

10、编制方法四、系统需求编制方法1、系统需求规格书主文档2、系统需求规格书3、用例识别及编制方法用例方法：主要建模元素用例方法：主要建模元素用例（用例（Use Case）:用例用于表示系统所提供的服务，它定义了系统是如何用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。能而与系统之间发生的一段对话。参与者（参与者（Actor）:参与者是指存在于被定义系统外部并与该系统发生交互参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代

11、表的是系统的使用者或使用环境。的人或其他系统，他们代表的是系统的使用者或使用环境。事件流（事件流（Event flow）：对用例的具体描述是通过事件流来详细进行说明的。）：对用例的具体描述是通过事件流来详细进行说明的。事件流反映了系统的使用者期望与系统交互的流程，事件流又分为基本流事件流反映了系统的使用者期望与系统交互的流程，事件流又分为基本流（系统正常使用下的流程）和备选流（系统在特定情况下的分支流），基（系统正常使用下的流程）和备选流（系统在特定情况下的分支流），基本流和备选流的组合反映了系统在使用过程中的真实场景。本流和备选流的组合反映了系统在使用过程中的真实场景。前置条件：执行用例前，

12、系统所处的状态。前置条件：执行用例前，系统所处的状态。后置条件：执行用例之后，系统所处的状态。后置条件：执行用例之后，系统所处的状态。用例方法：特点和优势用例方法：特点和优势用例具有以下的特点（优点）：用例具有以下的特点（优点）： 给出了需求的上下文：谁使用，在什么条件下使用，如何使用。给出了需求的上下文：谁使用，在什么条件下使用，如何使用。 容易理解：尽量采用用户理解的语言。容易理解：尽量采用用户理解的语言。 易于重用：是设计、测试及系统相关文档的基础。易于重用：是设计、测试及系统相关文档的基础。用例方法：发现参与者用例方法：发现参与者系统的参与者定义了系统的边界，可从以下几方面发系统的参与

13、者定义了系统的边界，可从以下几方面发现系统的参与者：现系统的参与者：谁使用系统？谁使用系统？谁从系统获取信息？谁从系统获取信息？谁向系统提供信息？谁向系统提供信息？系统在什么地方使用？系统在什么地方使用？谁支持或维护系统？谁支持或维护系统？有没有其它的系统使用该系统？有没有其它的系统使用该系统？用例方法：识别用例用例方法：识别用例从参与者的角度出发发现用例，以下问题有助于发现从参与者的角度出发发现用例，以下问题有助于发现用例：用例： 参与者希望怎样使用该系统？参与者希望怎样使用该系统？ 参与者希望创建、存储、修改、删除系统的数据吗？参与者希望创建、存储、修改、删除系统的数据吗？ 当外部事件发生

14、变化时，参与者需要通知系统吗？当外部事件发生变化时，参与者需要通知系统吗？ 参与者希望被告知系统内部发生的变化吗？参与者希望被告知系统内部发生的变化吗？定义用例：基本流和备选流定义用例：基本流和备选流基本流与备选流：基本流与备选流： 基本流是该用例的一个主要的使用场景，一个基本流是该用例的一个主要的使用场景，一个用例用例只有一个只有一个基本流。基本流。 备选流是在基本流之上的有条件的分支，备选流结束后，要备选流是在基本流之上的有条件的分支，备选流结束后，要么返回到基本流，要么导致该用例结束。么返回到基本流，要么导致该用例结束。定义用例：场景（定义用例：场景（Scenario） 场景是指从流程的

15、起点开始，直到某个终点的一串流程场景是指从流程的起点开始，直到某个终点的一串流程细化用例：细化基本流细化用例：细化基本流细化基本流要点：采用参与者与系统交互的语言进行描述。参与者与系统交互的行为要明确，包括交互的信息（数据），系统处理所要遵守的业务规则，系统处理过程中与其它系统的接口，当然，数据、规则、接口如果有地方统一描述的话，引用即可。细化用例：细化备选流细化用例：细化备选流细化备选流要点：起始位置：写明备选流在基本流中的起始位置条件：写明分支的条件。动作：通过交互式语言写明备选流处理的动作。恢复：备选流结束后要么回到基本流的某一步，要么导致用例终止。（注：异常流也可视为一种特殊的备选流）

16、细化用例：前置细化用例：前置/后置条件后置条件前置条件是执行用例之前系统必须存在的一组状态，注前置条件是执行用例之前系统必须存在的一组状态，注意：意： 前置条件不是触发该用例的事件。 前置条件有助于减少事件流描述中的一些校验。 前置条件不描述系统之外的事情，如“客户有一个有效的SIM卡”。 前置是可选的。仅在需要时描述。后置条件是用例一执行完毕后系统可能处于的一组状态后置条件是用例一执行完毕后系统可能处于的一组状态 ：后置条件也是可选的，仅在需要时描述。细化用例：要点总结细化用例：要点总结描述对参与者可见的事件（参与者做什么，系统做什么）。用例必须提供参与者可见的结果。用例有不同的精细程度，细

17、化到所有涉众对需求有共同的理解为止。采用公用的术语和词汇。使用明确的语言。基于联通需求基于联通需求 丰富用例方法丰富用例方法丰富事件流的描述方法，细化区分丰富事件流的描述方法，细化区分：系统功能需求系统的数据处理需求：展现数据、存储数据系统要处理的业务规则将后台处理需求统一到用例描述中将后台处理需求统一到用例描述中使用与事件流相似的方式描述后台处理流程对于每个处理步骤，细化区分： 功能 输入数据 输出数据 业务规则结构化用例描述结构化用例描述用例之间的关系：1) 包含关系（包含关系（include）:基础用例会用到被包含的基础用例会用到被包含的用例；也就是被包含的用例的事件流一定会插入用例；也就是被包含的用例的事件流一定会插入到基础用例的事件流中。到基础用例的事件流中。2) 扩展关系（扩展关系（extend）:基础用例基础用例(Base)中定义有一中定义有一至多个已命名的扩展点，扩展关系是指将扩展用至多个已命名的扩展点，扩展关系是指将扩展用例例(Extension)的事件流在一定的条件下按照相应的事件流在一定的条件下按照相应的扩展点插入到基础用例的扩展点插入到基础用例(Base)中中 ，扩展用例的，扩展用例的事件流会被有条件地引用。事件流会被有条件地引用。参与