CSI_01_需求开发及管理过程

项目管理体系文件需求开发与管理过程编撰人：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.流程图 (5)
6.主要活动 (5)
6.1.需求开发准备 (6)
6.1.1.明确项目目标和范围 (6)
6.1.2.识别需求来源 (6)
6.1.3.选择调研方法和技术 (7)
6.1.4.制订需求调研计划 (7)
6.1.5.编制需求调研问卷 (8)
6.2.需求调研 (9)
6.2.1.进行需求调研 (9)
6.2.2.编写用户需求调研报告 (9)
6.3.需求分析 (10)
6.3.1.需求分析方法 (10)
6.3.2.功能需求分解 (12)
6.3.3.标识需求 (12)
6.3.4.定义需求的优先级 (13)
6.4.编写需求规格说明书 (13)
6.5.评审需求规格说明书 (14)
6.6.需求确认 (14)
6.6.1.客户确认 (14)
6.7.需求变更管理 (15)
6.8.需求跟踪 (15)
6.8.1.建立需求跟踪矩阵 (16)
6.8.2.需求跟踪矩阵的维护与使用 (16)
7.出口准则 (17)
8.输出 (17)
9.引用过程 (17)
1.引言
1.1.目的
规范公司项目的需求开发和管理活动，以保证对客户需求的正确理解，确保项目产物与需求的一致性。

1.2.适用范围
适用于公司合同开发类项目、产品研发类项目的需求开发和需求管理活动。

1.3.术语和缩略语
表 1术语和缩略语
1.4.相关文件
无
2.角色和职责
表 2角色和职责
3.入口准则
1)项目启动会
4.输入
1)项目合同
2)项目计划
5.流程图
图 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需求标识方法
6.3.4.定义需求的优先级
责任设计师应确定每个需求的优先级并写入《需求规格说明书》（模板详见：“3.需求\CSI_06_需求规格说明书.doc”）中，需求的优先级的评价标准如下：
表 5优先级级别定义
优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，正确地对需求实现的范围或实现的优先程度做出取舍。

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.需求跟踪
对一个项目来说，当需求确定下来以后，应该保证在设计过程中每个需求都被实现，且项目的其它工作产品与需求保持一致。

因此，一个比较好的方法就是建立一种需求双向跟踪机制。

双向跟踪即：
●横向跟踪：当发生需求变更时，通过从需求向后追溯到下游相关工作产
品，可分析出这些关联项是否需要变更，从而达到追溯的目的；
●纵向跟踪：通过需求和需求之间的关系，可以了解需求的变更对其它需
求的影响。

进行需求横向跟踪的一个简单的方法是建立一个映射，从需求到设计，从设计到编码，以及从编码到测试用例，把每个需求都映射到对应的位置。

这个映射可以用需求跟踪矩阵来实现。

进行需求纵向跟踪的一个有效的方法是建立需求和需求之间的有向关系图，以便可以方便的了解需求变化的影响范围。

6.8.1.建立需求跟踪矩阵
当《需求规格说明书》（详见：“3.需求\CSI_07_需求跟踪矩阵.xls”）通过评审之后，责任设计师应根据确定的需求跟踪的粒度编制《需求跟踪矩阵》。

PM 指定人员对需求跟踪矩阵进行检查，确保跟踪粒度合理、跟踪项适用。

6.8.2.需求跟踪矩阵的维护与使用
随着设计、开发、以及测试工作的不断推进，应保证每个需求都被实现，且与需求保持一致。

1)PM应指定专人对设计、编码、测试阶段产生的工作产品与需求建立对
应关系，建议在各段执行过程中实时进行，最迟应在各个阶段动结束时
完成：
(1)责任设计工程师负责完成设计文档与需求的对应关系；
(2)工程师负责完成代码与需求的对应关系；
(3)测试工程师负责完成测试用例与需求的对应关系；
(4)责任设计师应负责对其完整、正确、一致性进行确认，并将确认结果
通知PM。

2)对于已纳入需求跟踪矩阵的相关工作产品产生的变更，则由责任设计师
在每次变更完成后根据变更修改需求跟踪矩阵的对应关系。

3)在每个里程碑时责任设计师应负责对跟踪矩阵的完整、正确、一致性进
行确认，并将确认结果通知PM。

在项目过程中，项目组可以利用需求跟踪矩阵实施相关的控制，如：
●审核所有定义的需求是否已经在相关产品中得到实现；
●当发生需求变更时，检查受需求变更影响的其它需求和工作产品，确保
不忽略每个受到影响的系统元素；
●当相关的工作产品产生变更时，可以向前追溯到与其相关的需求与其它
工作产品，从而判断是否需要对这些关联产品进行变更；
在开发过程中，可以对所有定义的需求的当前开发状态进行跟踪。

7.出口准则
1)项目验收
8.输出
1)《需求调研计划》
2)《需求调研问卷》
3)《需求调研记录》
4)《用户需求调研报告》
5)《用户需求调研报告评审报告》
6)《需求规格说明书》
7)《需求规格说明书评审检查单》
8)《需求规格说明书评审报告》
9)《需求变更申请单》
10)《需求跟踪矩阵》
9.引用过程
1)《变更管理规程》（详见：“11.配置管理\CSI_03_变更管理规程.doc”）
2)《评审过程》（详见：“13.评审\CSI_01_评审过程.doc”）
3)。