软件开发需求管理-东莞培训

1、中 国 联 通 需 求 管 理 实 施方法和工具王 颖二零零七年四月二十八日背景 需求管理是IT部门一直在做的工作，大家在一线工作中积累了丰富的经验。当前在信息系统越来越成为企业的神经中枢的时候，无论IT部门还是业务部门都对需求管理的价值有了新的认识。总部从去年开始，在需求管理方面进行了新的尝试，并逐渐摸索出一套适合于电信企业支撑系统的需求管理的工作方法。 2007年初，为了提升需求管理的水平、促进需求管理的标准化、提高需求管理效率，购置了一套成熟的管理工具。在实施过程中，引入了专业的需求管理专家，系统的梳理了联通的需求管理的整个文档体系，并进行了完善和标准化。 本次课程内容即建立在上述工作的

2、根底上。 课程目的理解和掌握联通需求管理的文档体系及其相互关系明确省分需要编制的文档和要求理解和掌握需求规格书的内容和编制方法熟悉主要文档之间的追踪关系了解如何使用工具来支持需求管理工作课程大纲中国联通需求管理文档体系用户需求书的主要内容和编制方法系统需求规格书的主要内容和编制方法需求文档与设计、测试文档之间的追踪关系需求管理系统介绍和演示系统需求用户需求书满足工程管理满足厂商设计(n个)测试计划集成商测试结果(n个)验证产品测试用例安排执行初验文档终验文档上线文档验证中国联通需求管理文档体系31省分补充需求规格说明书全国统一需求规格说明书补充标准规范指标体系指导和约束各项文档的管理主体文档类

3、型责任方参与方评审/审核方用户需求书总部市场部总部、省分业务部门信息化部总部、省分业务部门信息化部全国统一需求规格说明书总部信息化部省分信息化部总部、省分业务部门总部、省分信息化部总部业务部门省分补充需求规格说明书省分信息化部省分业务部门总部信息化部产品测试相关文档总部信息化部省分信息化部总部信息化部工程相关文档省分信息化部集成商总部信息化部标准规范总部信息化部省分信息化部集成商总部信息化部指标体系总部信息化部总部业务部门总部信息化部总部业务部门设计文档集成商省分信息化部总部、省分信息化部软件需求层次 业务需求 用户需求软件需求分不同的层次和阶段：业务需求、用户需求和系统需求 需求分析人员进行

4、需求开发用户语言转换成技术语言功能性需求非功能性需求环境和约束文档体系和软件需求层次的对应关系用户需求书 系统功能需求系统需求规格说明书课程大纲中国联通需求管理文档体系用户需求书的主要内容和编制方法系统需求规格书的主要内容和编制方法需求文档与设计、测试文档之间的追踪关系需求管理系统介绍和演示现有用户需求书情况总部市场部组织编制了新一代BSS系统用户需求书20册现有用户需求书的内容要素：名称及属性 目标及作用 内容/功能描述 收费结算 业务受理要求 权限及范围 界面要求 数据要素风险控制 用户需求书内容要素用户需求书功能性需求非功能性需求性能要求易用性要求安全性要求其他业务描述业务目标和作用业务

5、流程及描述业务权限及范围用户界面要求内控要求业务数据定义对业务本身的介绍和描述该项需求支持哪些业务上的目标需求需要支持的详细业务流程及描述该项业务向哪些角色/人员开放权限与该项业务相关的内控要求是什么？对于用户界面有何具体要求？（可选）业务数据定义、业务数据与流程的关系4 业务数据汇总用户需求书模板样例流程描述要求：图形与文字相结合 图形描述：使用泳道图 文字描述：逐个描述流程步骤 步骤任务 步骤中涉及的业务角色 步骤中涉及的业务规则 步骤中涉及的业务数据新的用户需求书模板对于现有用户需求书的完善专注于问题域：在用户需求书中以业务为主进行描述，专注于把业务讲清楚使业务人员将精力放到研究业务本身

6、，而不是研究解决方案，降低业务人员的理解和编写难度不限制系统实现，使设计人员可以采用更加适合的方法来解决业务问题对于编写的标准化程度提出更高的要求：对于流程的详细程度和编写标准提出了具体要求，作为编写人员共同遵守的标准，有利于文档质量的管理，防止不同组并行时文档质量、风格参差不齐增加业务数据汇总表业务数据字典:将用户需求书中的所有业务数据都汇总到统一的表格中进行管理，并与业务流程进行关联有利于保持业务数据的一致性，防止互相的冲突与重复定义用户需求书的标准化属性名称取值需求编号用DOORS系统定义的ID（可自动维护） 是否需求点是,否需求状态新创建、已变更、已接受、需澄清、已拒绝、重复、已规划、

7、已开发、已取消、已上线 反馈意见分类枚举类型取值：需求定义重复，需求功能点定义模糊，需求功能点无法测试，等多值反馈意见描述取值：文字描述 需求来源总部或省份实施阶段一期，二期，。需求优先级 高、中、低 统一程度功能，流程，数据，规则需求联系人上线省分总部+31省，多选属性 管理粒度：最细一级业务需求 属性定义：针对每个需求点定义详细的属性，具体见右侧表格。 权限定义：总部市场部人员：文档正文的所有权限总部信息化部人员：文档正文的读取权限、属性的修改权限分公司、厂商人员：读取权限课程大纲中国联通需求管理文档体系用户需求书的主要内容和编制方法系统需求规格书的主要内容和编制方法系统需求规格书的构成用

8、例方法介绍系统需求规格书模板样例需求文档与设计、测试文档之间的追踪关系需求管理系统介绍和演示系统需求规格书的构成和描述方法省分BSS系统需求规格书全国统一需求规格书省分补充需求规格书统一功能性需求统计查询除外统一非功能性需求补充功能性需求统计查询局部、统一需求扩展局部补充非功能性需求环境和约束接口、替代系统统一接口需求用例方法用例方法条目化语言描述条目化语言描述条目化语言描述条目化语言描述 以BSS系统为例，省分BSS系统的需求规格说明书由两局部组成。其中对于核心的功能要求，全部在全国的统一需求规格书中定义，对于允许省分扩展的局部，在省分补充需求规格书中定义。 无论是全国统一需求还是省分补充需

9、求，都要遵循相同的需求编制方法。全国统一需求与省分补充需求之间的关系例如 扩展扩展全国统一需求规格说明书31个省份省分A省分 B第n用例A省对该用例进行了扩展B省没有对该用例进行扩展 根据总部统一需求规格书中统一管理程度的要求，省分对于一些需求可以进行扩展、细化和补充。这些省分的细化和补充需求统一纳入到总部的管理范围，与总部统一需求建立关联关系，作为统一版本由总部进行发布。用例方法主要建模元素用例Use Case:用例用于表示系统所提供的效劳，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。参与者Actor:参与者是指存在于被定义

10、系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。事件流Event flow：对用例的具体描述是通过事件流来详细进行说明的。事件流反映了系统的使用者期望与系统交互的流程，事件流又分为根本流系统正常使用下的流程和备选流系统在特定情况下的分支流，根本流和备选流的组合反映了系统在使用过程中的真实场景。前置条件：执行用例前，系统所处的状态。后置条件：执行用例之后，系统所处的状态。用例描述样例参与者事件流用例方法的特点和优势用例具有以下的特点优点：给出了需求的上下文：谁使用，在什么条件下使用，如何使用。容易理解：尽量采用用户理解的语言。易于重用：是设计、测试及系统相关文档的根

11、底。编写用例的步骤第一步：发现用例，通过对业务进行分析，提取系统所要完成的“事务性的功能，并形成用例。第二步：简要描述，对该用例所要完成的功能进行简要描述。第三步：编写用例大纲，概括出系统处理的主要步骤根本流，并进行编号。第四步：细化用例。针对根本流中的主要步骤，采用参与者与系统交互的语言进行详细描述，并增加备选流、前后置条件、特殊需求等。用例方法介绍-发现参与者系统的参与者定义了系统的边界，可从以下几方面发现系统的参与者：谁使用系统？谁从系统获取信息？谁向系统提供信息？系统在什么地方使用？谁支持或维护系统？有没有其它的系统使用该系统？用例方法介绍-识别用例从参与者的角度出发发现用例，以下问题

12、有助于发现用例：参与者希望怎样使用该系统？参与者希望创立、存储、修改、删除系统的数据吗？当外部事件发生变化时，参与者需要通知系统吗？参与者希望被告知系统内部发生的变化吗？识别参与者和用例举例定义用例根本流和备选流根本流与备选流：根本流是该用例的一个主要的使用场景，一个用例只有一个根本流。备选流是在根本流之上的有条件的分支，备选流结束后，要么该回到根本流，要么导致该用例结束。定义用例根本流和备选流编写用例纲要步骤编写用例流程步骤要点：列出根本流的主要处理步骤。对根本流的处理步骤进行编号。列出可能的备选流。定义用例场景Scenario 场景是指从流程的起点开始，直到某个终点的一串流程。细化用例细化

13、根本流细化根本流要点：采用参与者与系统交互的语言进行描述。参与者与系统交互的行为要明确，包括交互的信息数据，系统处理所要遵守的业务规那么，系统处理过程中与其它系统的接口，当然，数据、规那么、接口如果有地方统一描述的话，引用即可。细化用例细化备选流细化备选流要点：起始位置：写明备选流在根本流中的起始位置条件：写明分支的条件。动作：通过交互式语言写明备选流处理的动作。恢复：备选流结束后要么回到根本流的某一步，要么导致用例终止。注：异常流也可视为一种特殊的备选流细化用例-前置/后置条件前置条件是执行用例之间系统必须存在的一组状态，注意：前置条件不是触发该用例的事件。前置条件有助于减少事件流描述中的一

14、些校验。前置条件不描述系统之外的事情，如“客户有一个有效的SIM卡。前置是可选的。仅在需要时描述。后置条件是用例一执行完毕后系统可能处于的一组状态 ：后置条件也是可选的，仅在需要时描述。根本流、备选流描述样例根本流、备选流描述样例用例描述样例9. 后置条件订单生成，待订单处理生成定单。 细化用例要点总结描述对参与者可见的事件参与者做什么，系统做什么。用例必须提供参与者可见的结果。用例有不同的精细程度，细化到所有涉众对需求有共同的理解为止。采用公用的术语和词汇。使用明确的语言。基于联通需求 丰富用例方法丰富事件流的描述方法，细化区分：系统功能需求系统的数据处理需求：展现数据、存储数据系统要处理的

15、业务规那么将后台处理需求统一到用例描述中使用与事件流相似的方式描述后台处理流程对于每个处理步骤，细化区分：功能输入数据输出数据业务规那么用例描述样例结构化用例描述用例之间的关系：包含关系include:根底用例会用到被包含的用例；也就是被包含的用例的事件流一定会插入到根底用例的事件流中。扩展关系extend:根底用例(Base)中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到根底用例(Base)中 ，扩展用例的事件流会被有条件地引用。参与者之间的关系：参与者的继承总部/省分统一需求规格书文档结构业务资源管理用例1用例n客户

16、问题管理用例1用例n全国统一需求规格说明书主文档样例总部统一需求规格书的标准化 管理粒度：作为跟踪、管理的最小单位 功能性需求：需求用例说明； 非功能性需求：描述条目 属性定义：针对每个需求点定义详细的属性，具体见右侧表格。 权限定义： 总部市场部人员：文档正文的读取权限 总部信息化部需求分析人员：文档所有权限 分公司、厂商人员：读取权限属性取值需求状态新创建、已变更、审核通过、已发布、已取消、已上线 审核意见分类通过、不通过审核意见描述取值：文字描述实施阶段一期、二期需求类型枚举类型取值：功能性需求、非功能性需求、非需求需求负责人 需求编写人 统一管理程度统一需求、推荐需求、补充需求功能统一

17、程度统一要求、不统一要求流程统一程度所有流程、仅正常流程、不统一要求规则统一程度配置、仅列举、不统一要求数据统一程度统一要求、不统一要求省分需求规格书主文档样例省分需求规格书的标准化 管理粒度：需求用例说明； 属性定义：针对每个需求点定义详细的属性，具体见右侧表格。 权限定义：总部信息化部需求分析人员：文档读取权限、局部属性修改权限所属分公司：读、写、修改权限所属分公司实施厂商：读取权限属性取值需求状态新创建、已变更、审核通过、已发布、已取消、已上线 总部审核结果通过、未通过审核意见描述取值：文字描述统一管理类型全国统一需求、总部推荐需求、省分新增需求、省分补充需求流程是否扩展是/否流程扩展说

18、明 文字描述规则是否扩展是/否规则扩展说明 文字描述数据是否扩展是/否数据扩展说明 文字描述需求编写人需求负责人课程大纲中国联通需求管理文档体系用户需求书的主要内容和编制方法系统需求规格书的主要内容和编制方法需求文档与设计、测试文档之间的追踪关系需求管理系统介绍和演示扩展总部统一需求实施省1补充需求既要满足总部统一需求，也要满足实施省分的补充需求 满足满足某厂商的设计文档需求规格书与设计文档的关系 每个厂商提交统一的设计文档，既要满足总部统一需求，也要满足所实施省分的补充需求。但是要作为一个统一的版本进行维护。实施省2补充需求扩展总部统一需求用例需求规格书与产品测试文档的管理 产品功能测试用例

19、以总部统一需求规格书作为依据，对于每项需求，对应到测试用例文档。根据每次测试的实际情况，可以对测试用例文档进行筛选，形成每轮测试的测试方案，针对每家厂商执行测试后，形成测试报告。由于测试可以进行多轮，因此测试方案和测试报可以有多套存在。安排测试用例母板验证执行测试方案1测试报告厂家1测试报告厂家2执行执行测试方案2执行测试报告厂家1测试报告厂家2安排第一轮测试第二轮测试课程大纲中国联通需求管理文档体系用户需求书的主要内容和编制方法系统需求规格书的主要内容和编制方法需求文档与设计、测试文档之间的追踪关系需求管理系统介绍和演示总体架构主要功能实施方案系统演示需求管理系统总体架构需求决策需求分析需求开发系统验收系统维护需求启动测试用户需求需求规格设计测试用例文档模板文档模板文档模板DOORS软件文档管理测试计划原始需求Synergy/CM代码/