CSI_01_需求开发及管理过程.doc

项目管理体系文件项目管理体系文件 需求开发与管理过程需求开发与管理过程 编 撰 人：TMO 审 核 人： 批 准 人： 批准日期：2010-9-1 保密级别：机密 文档版本：0.0.1 北京中软国际信息技术有限公司北京中软国际信息技术有限公司 版本历史版本历史 日期日期版本版本说明说明作者作者 目目 录录 1.引言引言.4 1.1. 目的.4 1.2. 适用范围.4 1.3. 术语和缩略语.4 1.4. 相关文件.4 2.角色和职责角色和职责 .4 3.入口准则入口准则.5 4.输入输入.5 5.流程图流程图.6 6.主要活动主要活动.7 6.1. 需求开发准备.7 6.1.1.明确项目目标和范围.8 6.1.2.识别需求来源.8 6.1.3.选择调研方法和技术.8 6.1.4.制订需求调研计划.9 6.1.5.编制需求调研问卷.10 6.2. 需求调研.10 6.2.1.进行需求调研.10 6.2.2.编写用户需求调研报告.11 6.3. 需求分析.11 6.3.1.需求分析方法.12 6.3.2.功能需求分解.14 6.3.3.标识需求.14 6.3.4.定义需求的优先级.15 6.4. 编写需求规格说明书.15 6.5. 评审需求规格说明书.16 6.6. 需求确认.16 6.6.1.客户确认.16 6.7. 需求变更管理.17 6.8. 需求跟踪.17 6.8.1.建立需求跟踪矩阵.17 6.8.2.需求跟踪矩阵的维护与使用.18 7.出口准则出口准则.18 8.输出输出.19 9.引用过程引用过程.19 1.引言引言 1.1.目的目的 规范公司项目的需求开发和管理活动，以保证对客户需求的正确理解，确 保项目产物与需求的一致性。 1.2.适用范围适用范围 适用于公司合同开发类项目、产品研发类项目的需求开发和需求管理活动。 1.3.术语和缩略语术语和缩略语 表 1 术语和缩略语 术语、缩略语术语、缩略语解解 释释 PD 项目总监 TD 技术总监 PM 项目经理 1.4.相关文件相关文件 无 2.角色和职责角色和职责 表 2 角色和职责 角色角色职责职责 PM 1） 负责跟客户的沟通和协调工作； 2） 负责需求开发和需求管理工作的策划和管理，保证需求开发工作的 进度和质量。 责任设计师1） 负责需求开发的组织和管理工作，完成用户需求调研报告和需求规 格说明书，并获得客户的确认； 2） 负责需求管理。 工程师（高、中级）1） 协助需求调研与分析， 对需求的实现可行性进行验证； 2） 参与需求评审活动。 PD 1） 指导并监控需求开发和管理过程。 TD 1) 参与需求评审并对评审内容进行核准 3.入口准则入口准则 1) 项目启动会 4.输入输入 1) 项目合同 2) 项目计划 5.流程图流程图 需求开发和管理过程 需求开发准备需求调研需求分析和确认需求变革需求跟踪 工程师输出 客户方 负责人 PDPM 责任 设计师 输入 制订需求调研计划 需求调研计划 项目合同 项目计划 开始 编制调研问卷 调研问卷 需求调研 编写用户需求调研报告 需求调研记录 用户需求调研报告 内部评审 客户确认 编写需求规格说明书 内部评审 客户确认 签字证据 需求变更 需求跟踪 结束 需求变更申请单 需求跟踪矩阵 需求规格说明书评 审报告 需求评审检查单 项目问题跟踪表 用户需求调研报 告评审报告 项目问题跟踪表 签字证据 需求分析 需求规格说明书 图 1 需求开发与管理过程流程图 6.主要活动主要活动 需求开发和需求管理是需求工程的两个组成部分。 需求开发的主要活动包括：需求开发准备、需求调研、需求分析、编写需 求规格说明书和需求确认。需求开发是通过与用户沟通，收集用户资料，理解 用户的术语、概念、视点和目的，经过分析、建模和验证，确认获取正确、完 整和一致的需求的过程。这些活动在实际应用中不是线性的、顺序的完成的， 而是交叉的、递增的和反复的，需求开发是一个迭代的过程，如下图所示： 需需求求调调研研需需求求分分析析 编编写写需需求求规规格格 说说明明书书 需需求求确确认认 重重新新评评估估 重重写写 证证实实 重重新新调调研研 需需求求开开发发准准备备 需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求 与其它工作成果的一致性，并控制需求的变更。需求管理的主要活动包括：需 求变更和需求跟踪管理。 PD 应监督需求开发和管理过程，管控项目执行情况，并指导 PM 对执行过 程中产生的偏差进行修正。 6.1.需求开发准备需求开发准备 需求开发准备阶段的工作主要包括以下几个方面： 一是明确项目目标和范围； 二是识别需求的来源，为需求获取准备相关资料，例客户需求调研问卷等； 三是根据项目规模和特点，选择调研方式； 四是收集需求开发过程可用的知识，充分利用已有的知识和经验策划整个 需求开发过程，制定需求调研计划。 6.1.1. 明确项目目标和范围明确项目目标和范围 项目目标和范围通常在项目合同中有定义，在需求开发工作开始之前，PM 应要求所有参与需求开发工作的人员明确项目目标和范围，以便相关人员对产 品的业务目标和范围有共同的理解，控制项目范围。 6.1.2. 识别需求来源识别需求来源 识别需求来源是需求开发的一项重要工作，在需求调研开始之前 PM 应组 织参与需求调研的人员进行清楚的识别。需求的来源主要有： 1) 组织或用户高层次的目标：这些目标是软件系统开发的动因，但是通常 描述不够清晰，需要需求开发人员特别的关注； 2) 用户业务领域的知识：领域知识帮助需求开发人员推断一些用户当作默 认的而没有说明的需求，或者平衡需求之间的冲突； 3) 各层次的用户：不同层次的用户对系统的需求不同，这也是需要需求开 发人员要重点获取的需求。用户的积极参与是需求开发成功的关键，因此，在 进行需求调研时，要解决一个重要的问题-确定哪些人是需求获取的合适对象， 哪些人对系统的开发和应用具有发言权和决策权； 4) 系统的运行环境：系统的运行环境影响软件的可行性、成本和设计方案 的选择； 5) 组织所处的环境：软件通常支持组织的业务流程，必需考虑组织的机构 划分、文化背景、内部的政治目的，不能强迫要求组织因为软件进行非计划的 业务改变，同时还要考虑国家政策、法律法规以及相关行业标准等； 6) 竞争对手的产品：通过对竞争对手产品的研究，获取有竞争力的需求。 6.1.3. 选择调研方法和技术选择调研方法和技术 需求调研是一个困难的过程，对于需求开发调研人员来说，需求获取不是 被动的活动，而应该主动的根据不同的需求来源采取不同的需求获取方法进行 需求收集。需求获取的方法和技术多种多样，针对不同的项目和不同的调研对 象范围，可以采用不同的方法，也可以多种方法配合使用。责任设计师应根据 项目情况负责选择合适的调研方法和技术。需求调研的参考方法如下： 表 3 需求调研方法 方法方法内容内容输出输出 面谈与用户面对面的访谈，可以一对一或者一对多， 要求准备一个问题列表，用来获得有关用户问 题和潜在解决方案的整体特征的信息； 需求调研记录 调查问卷使用设计好的调查问卷，以书面的形式收集用 户需求； 调研问卷 相关业务资料 集体讨论头脑风暴会议，提出对现在问题的理解和思考， 涉众提出问题、愿望和潜在解决方案的建议； 会议纪要 需求调研记录 在用户环境中工作需求调研人员在用户的实际环境中与用户共同 工作一段时间，以更加深入的了解用户的问题、 要求以及应用环境； 需求调研记录 原型演示展示类似系统的功能，以揭示用户需要需求调研记录 6.1.4. 制订需求调研计划制订需求调研计划 制定需求调研计划 （模板详见：“03.需求CSI_02_需求调研计划.doc” ） 的目的是为了规划项目中需求调研活动的开展，其内容主要包括需求调研的对 象、调研的内容、准备采用的技术和方法、输出产物、人力安排和时间进度等。 需求调研计划应该开展需求调研活动之前完成，由 PM 和责任设计师 共同完成策划，责任设计师完成制订，在由项目经理跟客户方项目经理一起讨 论确定，并提前通知所有参加需求调研的人员。 针对不同类别的项目，需求调研工作过程基本一致，但侧重点有所不同， 在制定调研计划的时候要分别考虑： 一、一、业务流程开发类项目业务流程开发类项目 业务流程开发类项目的需求调研工作重心是要充分理解业务相关的信息： 1） 系统需要实现的业务功能范围； 2） 业务相关的组织、人员、岗位及相关职能； 3） 业务处理的流程； 4） 关键业务数据及数据分布及流向； 5） 相关的业务表单。 二、二、数据中心类项目数据中心类项目 数据中心类项目的需求调研工作重心是要弄清楚业务数据的结构和来源以 及相关数据分析的需求： 1)基础数据代码标准及管理需求； 2)业务数据的来源及相关系统特征； 3)业务数据的结构、范围、内容和质量； 4)数据及元数据管理的需求； 5)相关指标及管理； 6)报表需求； 7)数据分析与决策支持需求。 三、产品研发类产品研发类 产品研发类项目侧重点与业务流程开发类基本一致。 6.1.5. 编制需求调研问卷编制需求调研问卷 如果采用面谈、调查问卷、集体讨论的调研方法，参与需求调研的人员应 事先学习相关的业务知识，收集相关的资料并进行分析，在对客户需求有一定 了解的基础上提前准备需要问的问题，形成需求调研问卷 （模板详见：“03.需 求CSI_03_需求调研问卷.doc” ） ，以便系统、全面、高效的获取客户的需求。 需求调研问卷中列的问题与业务领域相关，不同的项目需要根据项目涉及 的业务领域设计调研问卷中的问题，问题列的越详细对需求调研的帮助越大， 如果以前有类似的项目，可复用以往类似项目的成果。 6.2.需求调研需求调研 责任设计师负责按照需求调研计划执行需求调研活动，在需求调研过 程中，应及时记录、整理需求调研记录 （模板详见：“03.需求CSI_04_需 求调研记录.doc” ） ，根据需求调研记录编写需求调研报告 （模板详见： “03.需求CSI_05_用户需求调研报告.doc” ）并请客户进行确认。 6.2.1. 进行需求调研进行需求调研 在进行需求调研时，应基于需求调研问卷有效引导客户提出需求，这个过 程的重点工作是： 1) 进一步识别并选定用户代表，避免遗漏重要客户； 2) 明确业务流程、业务数据、业务规则以及每个业务活动涉及的岗位，同 时识别出核心业务流程等； 3) 除了听取客户提出的需求以外，还要积极参与讨论，引导客户提出需求 和问题，对于有歧义的需求要充分讨论，对于客户提出的超出范围的或者不现 实的需求要积极跟客户协商，在共赢的基础上达成共识； 4) 在调研过程中要及时记录客户提出的需求，形成需求调研记录 ； 5) 调研过程中还要注意收集与产品相关的资料，例如：组织机构、部门及 岗位职责、规章制度、业务流程、业务单据及统计报表等，对于业务单据和统 计报表，最好是收集带有历史数据的，而不是空的表格，便于后续对数据的需 求进行分析。 6.2.2. 编写用户需求调研报告编写用户需求调研报告 责任设计师应根据需求调研的记录和收集到的资料，组织整理、编写用 户需求调研报告 。 调研报告编写完成进行内部评审，执行评审过程 ，TD 应负责最终的审 核和确认。内部评审完成后，须提交客户并请客户审阅，在客户审阅过程中可 能还会提出问题，需要进行进一步的调研并及时修改完善调研报告，最后获得 用户认可和签字。 6.3.需求分析需求分析 在完成需求调研后，设计师应对产品的原始需求进行分析，建立各需求元 素之间的关系，明确需求的标识、需求的分类、需求的优先级等。 需求分析的方法种类繁多，但常见的需求分析方法主要是结构化分析方法 和基于用例的需求分析方法。 6.3.1. 需求分析方法需求分析方法 6.3.1.1.结构化分析方法结构化分析方法 结构化分析方法的主要特点是“自顶向下、逐层分解” ，它把系统看作一个 过程的集合体，利用图形等半形式化的描述方式表达需求，对问题进行分析， 描述方式有： 1) 数据流图（Data Flow Diagram，DFD）： 数据流图是一种图形化的系统模型，它在一张图中展示信息系统的主要需 求，即输入、输出、处理过程、数据存储。 2) 数据字典（Data Dictionary，DD）： 数据字典技术是一种有效表达数据格式的手段，它是对所有与系统相关的 数据元素的一个有组织的列表和精确、严格的定义，从而使用户和设计师对于 输入、输出、数据存储和处理过程有共同的理解。 3) 结构化语言： 结构化语言是结构化编程语言与自然语言的有机结合，可以采用顺序结构， 分支机构、循环结构等机制，来说明业务的处理流程。 4) 实体-关系图（Entity Relationship Diagram，E-R 图）： E-R 图可以用来描述数据的存储需求，包括数据实体，数据实体的属性以及 它们之间的关系等。 结构化分析方法从总体上看是一种强烈依赖数据流图的自上而下的建模方 法，它是完成需求规格化的有效技术手段，使用结构化分析方法时可遵循下列 活动： （1） 、建立系统的物理模型 画出系统的数据流图，说明系统的输入、输出数据流，说明系统的数据流 情况，以及经历了哪些处理过程。在这个数据流图中，可以包括一些非计算机 系统中数据流及处理过程的名称，如部门、岗位、报表等。这个过程可以帮助 分析人员有效地理解业务环境。 （2） 、建立系统的逻辑模型 在物理模型建立之后，接下来的工作就是画出相对于真实系统的等价逻辑 数据流图。将所有自然数据流图转换为等价的逻辑流。 （3） 、划清人机界限 最后，确定在系统逻辑模型中，哪些部分将采用自动化完成，哪些部分仍 然保留手工操作，从而清晰的划清系统的范围。 6.3.1.2.基于用例的分析方法基于用例的分析方法 用例是由一组用例实例组成的，是用户使用系统的一个实际的、特定场景。 用例是应用程序开发中的一个关键技术，主要用来捕获系统的高层次用户功能 性需求。用例分析技术是一种需求合成技术，它利用现有的需求调研技术从客 户、原有系统、文档中找到需求，记录下来，然后从这些零散的需求、特性中 进行整理、提炼，从而建立用例模型。 使用用例分析方法时可遵循以下步骤： 1)识别系统参与者，确定谁会直接使用该系统。参与者是同系统交互的所 有事物，该角色不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时 钟。 2)合并需求获得用例。找到所有参与者之后，根据需求调研所得到的用户 需求，定义每个参与者希望系统做什么，参与者希望系统作的每件事将成为一 个用例。 3)绘制用例图。将所识别的参与者以及所定义的用例通过用例图的形式整 理出来，以获得用例模型的框架。 4)细化用例描述。用例描述包括以下几个部分： 用例名称； 参与者； 用自然语言对用例进行简要的描述； 描述参与者何时使用该用例，即用例的触发条件； 描述在一般情况下，参与者使用该用例时会发生什么事情，即用例的基 本过程； 在基本过程的基础上，考虑一些可变情况，把他们创建为扩展用例。 6.3.2. 功能需求分解功能需求分解 需求分析过程一个很重要的工作就是对就是对需求的分解（WBS） ，设计师 应依据业务特点分解功能需求，并形成功能需求列表，如下表： 功能需求功能需求子功能需求（可多级）子功能需求（可多级） 6.3.3. 标识需求标识需求 为了确保需求的易跟踪、易修改，责任设计师应通过需求编号的方式唯一 标识每一个需求，明确需求的跟踪粒度，并体现于需求规格说明书中。 表 4 需求标识方法 方法方法说明说明优、缺点优、缺点 序列号例如 U R - 2 或 S R S 1 3； 序列号的前缀代表了需求类型； 例如 U R 代表“用户需求” 。 序列号不能重用。 这种简单的编号方法并不能提供任 何相关需求在逻辑上或层次上的区 别，而且需求的标识不能提供任何 有关每个需求内容的信息。 层次化编码如果功能需求出现在软件需求 规格说明中第 3 .2 部分，那么 它们将具有诸如 3 . 2 . 4 . 3 这样的标识号。标识号中的数 字越多则表示该需求越详细， 属于较低层次上的需求。 这种方法简单且紧凑，你使用的字 处理程序可能可以自动编排序号。 但是当插入、删除或移去一个需求， 那么该需求所在部分其后所有需求 的序号将要减少，这些变化将破坏 系统其它地方需求的引用。 层次化文本标签基于文本的层次化标签方案来 标识单个需求。 层次化文本标签是结构化的，具有 语义上的含义，并且不受增加、删 除或移动其它需求的影响。它们的 主要缺点是文本标签比层次化数字 标识码复杂。 自定义如：SRS_模块缩写+序列号 SRS 表示需求，示例： SRS_SZAG01、SRS_SZAG01.01、 SRS_SZAG01.01.02 灵活。 6.3.4. 定义需求的优先级定义需求的优先级 责任设计师应确定每个需求的优先级并写入需求规格说明书 （模板详见： “3.需求CSI_06_需求规格说明书.doc” ）中，需求的优先级的评价标准如下： 表 5 优先级级别定义 级别定义级别定义判断标准判断标准 高必须被实现的需求，这类需求通常可以从以下几个方面判断： 1) 客户核心的业务流程； 2) 强制性的国家或行业法律法规、标准要求的； 3) 明确或隐含的对用户使用会造成重要影响的。 中应该被实现的需求，这类需求往往具有以下特征： 1) 客户隐含要求，对正常业务影响程度不大； 2) 不影响用户正常使用，但为了更易用而提出来的一些需求； 3) 支持必要的系统操作，实现这些需求将增强产品的性能，是产品最终所要 求的。 低可以被实现的需求，这些需求一般为装饰性的要求，如： 1) 功能或质量上的附加需求； 2) 实现这些需求会使产品更完美，若不实现也不影响产品的功能与性能。 优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关 制约因素之间产生冲突时，正确地对需求实现的范围或实现的优先程度做出取 舍。 6.4.编写需求规格说明书编写需求规格说明书 编写需求规格说明书应遵循以下规则： 1) 相关的需求都得到了识别与描述，以确保需求的完整性； 2) 各个需求之间不冲突，算法之间不相互矛盾，以确保需求的一致性； 3) 正确描述系统需求，引用的资料有正规的出处，以确保需求的正确性； 4) 定义必要的术语，适当结合图形、结构图等方式进行描述，以确保需求 无二义性； 5) 使用较好的文档结构与需求标识，使需求能够方便地与其它工作产品相 对应，以确保需求易于追溯； 6) 考虑了各个层次的需求，确定了需求的优先级，以确保需求的可行性。 需求规格说明书主要内容包括： 1) 项目概述； 2) 业务流程； 3) 数据描述； 4) 功能需求； 5) 非功能需求； 6) 界面要求； 7) 接口要求。 6.5.评审需求规格说明书评审需求规格说明书 项目组内部对所形成的需求规格说明书文档进行评审，以便作为下一 阶段工作的基础，评审执行评审过程 ，应根据评审检查单 （模板详见： “13.评审CSI_02_评审检查单.doc”）模板形成需求规格说明书评审检查单 ， TD 应负责最终的审核和确认。 6.6.需求确认需求确认 6.6.1. 客户确认客户确认 PM 与客户方项目经理组织客户对需求进行确认。需求确认的目的是获得 客户对需求的认可并签字。 1) 需求确认前，PM 应组织与相关客户进行沟通，确认需求是否满足其需 要，必要时辅以原型演示的方式帮助客户进行需求理解，取得客户对需 求的理解和认同。这是一个迭代的过程，需要 PM 与客户进行良好的沟 通，才能取得好的效果。 2) 需求的最终确认一般采取会签或者评审会议的方式。 需求评审会：一般由客户组织，项目经理配合客户准备相关资料（具体 准备哪些资料需要跟客户方负责人协商。一般需准备评审会议 PPT 文 件和需求评审报告） ，通过会议完成对需求的评审并签字确认。 会签主要是相关客户直接对需求进行签字确认。 在会签或者会议评审的过程中，PM 应详细记录在评审过程中发现的问题， 明确遗留问题处理措施。 3) 获取客户提供确认证据后，结束需求确认工作。 6.7.需求变更管理需求变更管理 在需求并获得确认后，需求可能还会因为多种原因导致变更，导致变更的 原因可能是客户方遗漏、表述不清，也可能是项目组理解有误。需求的变更可 能导致项目范围的变化，带来额外的工作量，尤其是在设计、开发、实施阶段 发生的需求变化，会造成更大的影响。但需求变更也是不可避免的，因此应建 立需求跟踪机制（见下一节）并对需求的变更加以严格的管理和控制，尽可能 减少需求变更和降低需求变更带来的影响。 需求的变更应严格遵照变更管理规程执行。 6.8.需求跟踪需求跟踪 对一个项目来说，当需求确定下来以后，应该保证在设计过程中每个需求 都被实现，且项目的其它工作产品与需求保持一致。因此，一个比较好的方法 就是建立一种需求双向跟踪机制。双向跟踪即： 横向跟踪：当发生需求变更时，通过从需求向后追溯到下游相关工作产 品，可分析出这些关联项是否需要变更，从而达到追溯的目的； 纵向跟踪：通过需求和需求之间的关系，可以了解需求的变更对其它需 求的影响。 进行需求横向跟踪的一个简单的方法是建立一个映射，从需求到设计，从 设计到编码，以及从编码到测试用例，把每个需求都映射到对应的位置。这个 映射可以用需求跟踪矩阵来实现。 进行需求纵向跟踪的一个有效