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

中 国 联 通 需 求 管 理 实 施方法和工具王 颖,二零零七年四月二十八日,背景,需求管理是IT部门一直在做的工作，大家在一线工作中积累了丰富的经验。当前在信息系统越来越成为企业的神经中枢的时候，无论IT部门还是业务部门都对需求管理的价值有了新的认识。总部从去年开始，在需求管理方面进行了新的尝试，并逐渐摸索出一套适合于电信企业支撑系统的需求管理的工作方法。 2007年初，为了提升需求管理的水平、促进需求管理的规范化、提高需求管理效率，购买了一套成熟的管理工具。在实施过程中，引入了专业的需求管理专家，系统的梳理了联通的需求管理的整个文档体系，并进行了完善和规范化。 本次课程内容即建立在上述工作的基础上。,课程目的,理解和掌握联通需求管理的文档体系及其相互关系明确省分需要编制的文档和要求理解和掌握需求规格书的内容和编制方法熟悉主要文档之间的追踪关系了解如何使用工具来支持需求管理工作,课程大纲,中国联通需求管理文档体系用户需求书的主要内容和编制方法系统需求规格书的主要内容和编制方法需求文档与设计、测试文档之间的追踪关系需求管理系统介绍和演示,满足,中国联通需求管理文档体系,补充,各项文档的管理主体,软件需求层次,业务需求,用户需求,软件需求分不同的层次和阶段：业务需求、用户需求和系统需求,需求分析人员进行需求开发,用户语言转换成技术语言,功能性需求,非功能性需求,文档体系和软件需求层次的对应关系,系统功能需求,课程大纲,中国联通需求管理文档体系用户需求书的主要内容和编制方法系统需求规格书的主要内容和编制方法需求文档与设计、测试文档之间的追踪关系需求管理系统介绍和演示,现有用户需求书情况,总部市场部组织编制了新一代BSS系统用户需求书（20册）现有用户需求书的内容要素：名称及属性 目标及作用 内容/功能描述 收费结算 业务受理要求 权限及范围 界面要求 数据要素风险控制,用户需求书内容要素,用户需求书,用户需求书模板样例,新的用户需求书模板对于现有用户需求书的完善,专注于问题域：在用户需求书中以业务为主进行描述，专注于把业务讲清楚使业务人员将精力放到研究业务本身，而不是研究解决方案，降低业务人员的理解和编写难度不限制系统实现，使设计人员可以采用更加适合的方法来解决业务问题对于编写的规范化程度提出更高的要求：对于流程的详细程度和编写规范提出了具体要求，作为编写人员共同遵守的规范，有利于文档质量的管理，避免不同组并行时文档质量、风格参差不齐增加业务数据汇总表（业务数据字典）:将用户需求书中的所有业务数据都汇总到统一的表格中进行管理，并与业务流程进行关联有利于保持业务数据的一致性，避免互相的冲突与重复定义,用户需求书的规范化,管理粒度：最细一级业务需求 属性定义：针对每个需求点定义详细的属性，具体见右侧表格。 权限定义：总部市场部人员：文档正文的所有权限总部信息化部人员：文档正文的读取权限、属性的修改权限分公司、厂商人员：读取权限,课程大纲,中国联通需求管理文档体系用户需求书的主要内容和编制方法系统需求规格书的主要内容和编制方法系统需求规格书的构成用例方法介绍系统需求规格书模板样例需求文档与设计、测试文档之间的追踪关系需求管理系统介绍和演示,系统需求规格书的构成和描述方法,省分BSS系统需求规格书,全国统一需求规格书,省分补充需求规格书,统一功能性需求（统计查询除外）,统一非功能性需求,补充功能性需求（统计查询部分、统一需求扩展部分）,补充非功能性需求,环境和约束（接口、替代系统）,统一接口需求,以BSS系统为例，省分BSS系统的需求规格说明书由两部分组成。其中对于核心的功能要求，全部在全国的统一需求规格书中定义，对于允许省分扩展的部分，在省分补充需求规格书中定义。 无论是全国统一需求还是省分补充需求，都要遵循相同的需求编制方法。,全国统一需求与省分补充需求之间的关系示例,扩展,扩展,全国统一需求规格说明书,31个省份,省分A,省分 B,A省对该用例进行了扩展,B省没有对该用例进行扩展,根据总部统一需求规格书中统一管理程度的要求，省分对于一些需求可以进行扩展、细化和补充。这些省分的细化和补充需求统一纳入到总部的管理范围，与总部统一需求建立关联关系，作为统一版本由总部进行发布。,用例方法主要建模元素,用例（Use Case）:用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。参与者（Actor）:参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。事件流（Event flow）：对用例的具体描述是通过事件流来详细进行说明的。事件流反映了系统的使用者期望与系统交互的流程，事件流又分为基本流（系统正常使用下的流程）和备选流（系统在特定情况下的分支流），基本流和备选流的组合反映了系统在使用过程中的真实场景。前置条件：执行用例前，系统所处的状态。后置条件：执行用例之后，系统所处的状态。,用例描述样例,用例方法的特点和优势,用例具有以下的特点（优点）：给出了需求的上下文：谁使用，在什么条件下使用，如何使用。容易理解：尽量采用用户理解的语言。易于重用：是设计、测试及系统相关文档的基础。,编写用例的步骤,第一步：发现用例，通过对业务进行分析，提取系统所要完成的“事务性”的功能，并形成用例。第二步：简要描述，对该用例所要完成的功能进行简要描述。第三步：编写用例大纲，概括出系统处理的主要步骤（基本流），并进行编号。第四步：细化用例。针对基本流中的主要步骤，采用参与者与系统交互的语言进行详细描述，并增加备选流、前后置条件、特殊需求等。,用例方法介绍-发现参与者,系统的参与者定义了系统的边界，可从以下几方面发现系统的参与者：谁使用系统？谁从系统获取信息？谁向系统提供信息？系统在什么地方使用？谁支持或维护系统？有没有其它的系统使用该系统？,用例方法介绍-识别用例,从参与者的角度出发发现用例，以下问题有助于发现用例：参与者希望怎样使用该系统？参与者希望创建、存储、修改、删除系统的数据吗？当外部事件发生变化时，参与者需要通知系统吗？参与者希望被告知系统内部发生的变化吗？,识别参与者和用例举例,定义用例基本流和备选流,基本流与备选流：基本流是该用例的一个主要的使用场景，一个用例只有一个基本流。备选流是在基本流之上的有条件的分支，备选流结束后，要么该回到基本流，要么导致该用例结束。,定义用例基本流和备选流,编写用例纲要步骤,编写用例流程步骤要点：列出基本流的主要处理步骤。对基本流的处理步骤进行编号。列出可能的备选流。,定义用例场景（Scenario）,场景是指从流程的起点开始，直到某个终点的一串流程。,细化用例细化基本流,细化基本流要点：采用参与者与系统交互的语言进行描述。参与者与系统交互的行为要明确，包括交互的信息（数据），系统处理所要遵守的业务规则，系统处理过程中与其它系统的接口，当然，数据、规则、接口如果有地方统一描述的话，引用即可。,细化用例细化备选流,细化备选流要点：起始位置：写明备选流在基本流中的起始位置条件：写明分支的条件。动作：通过交互式语言写明备选流处理的动作。恢复：备选流结束后要么回到基本流的某一步，要么导致用例终止。（注：异常流也可视为一种特殊的备选流）,细化用例-前置/后置条件,前置条件是执行用例之间系统必须存在的一组状态，注意：前置条件不是触发该用例的事件。前置条件有助于减少事件流描述中的一些校验。前置条件不描述系统之外的事情，如“客户有一个有效的SIM卡”。前置是可选的。仅在需要时描述。后置条件是用例一执行完毕后系统可能处于的一组状态 ：后置条件也是可选的，仅在需要时描述。,基本流、备选流描述样例,基本流、备选流描述样例,用例描述样例,9. 后置条件订单生成，待订单处理生成定单。,细化用例要点总结,描述对参与者可见的事件（参与者做什么，系统做什么）。用例必须提供参与者可见的结果。用例有不同的精细程度，细化到所有涉众对需求有共同的理解为止。采用公用的术语和词汇。使用明确的语言。,基于联通需求 丰富用例方法,丰富事件流的描述方法，细化区分：系统功能需求系统的数据处理需求：展现数据、存储数据系统要处理的业务规则将后台处理需求统一到用例描述中使用与事件流相似的方式描述后台处理流程对于每个处理步骤，细化区分：功能输入数据输出数据业务规则,用例描述样例,结构化用例描述,用例之间的关系：包含关系（include）:基础用例会用到被包含的用例；也就是被包含的用例的事件流一定会插入到基础用例的事件流中。扩展关系（extend）:基础用例(Base)中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中 ，扩展用例的事件流会被有条件地引用。参与者之间的关系：参与者的继承,总部/省分统一需求规格书文档结构,全国统一需求规格说明书主文档样例,总部统一需求规格书的规范化,管理粒度：作为跟踪、管理的最小单位 功能性需求：需求用例说明； 非功能性需求：描述条目 属性定义：针对每个需求点定义详细的属性，具体见右侧表格。 权限定义： 总部市场部人员：文档正文的读取权限 总部信息化部需求分析人员：文档所有权限 分公司、厂商人员：读取权限,省分需求规格书主文档样例,省分需求规格书的规范化,管理粒度：需求用例说明； 属性定义：针对每个需求点定义详细的属性，具体见右侧表格。 权限定义：总部信息化部需求分析人员：文档读取权限、部分属性修改权限所属分公司：读、写、修改权限所属分公司实施厂商：读取权限,课程大纲,中国联通需求管理文档体系用户需求书的主要内容和编制方法系统需求规格书的主要内容和编制方法需求文档与设计、测试文档之间的追踪关系需求管理系统介绍和演示,扩展,总部统一需求,实施省1补充需求,既要满足总部统一需求，也要满足实施省分的补充需求,满足,满足,某厂商的设计文档,需求规格书与设计文档的关系,每个厂商提交统一的设计文档，既要满足总部统一需求，也要满足所实施省分的补充需求。但是要作为一个统一的版本进行维护。,实施省2补充需求,总部统一需求用例,需求规格书与产品测试文档的管理,产品功能测试用例以总部统一需求规格书作为依据，对于每项需求，对应到测试用例文档。根据每次测试的实际情况，可以对测试用例文档进行筛选，形成每轮测试的测试计划，针对每家厂商执行测试后，形成测试报告。由于测试可以进行多轮，因此测试计划和测试报可以有多套存在。,安排,测试用例（母板）,验证,执行,测试计划1,测试报告（厂家1）,测试报告（厂家2）,执行,执行,测试计划2,执行,测试报告（厂家1）,测试报告（厂家2）,安排,第一轮测试,第二轮测试,课程大纲,中国联通需求管理文档体系用户需求书的主要内容和编制方法系统需求规格书的主要内容和编制方法需求文档与设计、测试文档之间的追踪关系需求管理系统介绍和演示总体架构主要功能实施计划系统演示,需求管理系统总体架构,需求决策,需求分析,需求开发,系统验收,系统维护,需求启动,测试,DOORS软件文档管理,Synergy/CM代码/程序配置管理,MSS,Synergy/Change流程管理,上线,需求管理数据库结构,软件文档库,将所有IT项目的所有的软件文档有组织地,结构化地存放在需求管理数据库中,系统,跨系统公共文件夹,统一软件文档管理的主要功能,将软件文档规范化需求对象确定需求对象的颗粒度，作为需求管理的最小单位建立需求对象属性，用于记录需求的管理信息管理资产之间的关联关系追踪模型记录不同资产项之间的关联利用追踪模型进行覆盖分析、影响度分析、来源分析实现全公司信息系统建设的信息共享权限管理所有资产集中存储在统一的数据库中，通过权限管理控制不同角色的操作权限和使用范围统一版本管理基线固化阶段工作成果，作为下阶段的工作基础可扩展的基线集合管理，便于将系统建设生命周期全过程产品的各项资产进行统一的版本管理对修改历史进行自动记录，便于追踪资产不同版本之间的演变过程,需求流程管