需求开发与管理过程(Req. Development Mgt. Process)

Req. Development & Mgt. Process 需求开发与管理过程

Prep分配需求ed by

拟制陈刚

Date

日期

2006-05-16

Reviewed by 评审人SEPG team

Date

日期

2007-4-20

Approved by

批准田松涛

Date

日期

2007-4-24

Revision Record 修订记录

Table of Contents 目录

1Purpose 目的 (5)

2Scope 范围 (5)

3Abbreviations and Acronyms 术语和缩略语 (5)

4Policy 方针 (5)

5Process Description 过程描述 (5)

5.1Roles and Responsibilities 角色和职责 (6)

5.2Entrance Criteria 入口准则 (6)

5.3Input 输入 (6)

5.4Activities 活动 (6)

5.4.1Summarize 总述 (6)

5.4.2Flow Chart 流程图 (7)

5.4.3Requirements Development and Validation 需求开发及确认 (8)

5.4.4Trace Requirements and Requirements Management 需求跟踪和管理 (10)

5.5Output 输出 (11)

5.6Exit Criteria 出口准则 (11)

6Resource and Tools 资源与工具 (11)

7Configuration Management and Assets 配置管理和资产 (11)

8Training 培训 (11)

9Process Measurement 过程度量 (11)

10Tailoring Guidelines 裁剪指南 (12)

11Verification 验证 (12)

12Related Process 相关过程 (12)

13Reference Materials 参考文献 (12)

Table List 表目录

表格1术语与缩略语 (5)

表格2角色和职责 (6)

Figure List 图目录

图表1需求开发与管理过程 (7)

1 Purpose 目的

为确保文思创新软件技术有限公司（简称文思创新）在软件开发项目中的工作产品质量稳定，对需求开发和需求管理过程进行规范化描述，特制定本文档。

需求开发是为了准确地获取客户方下发的需求，并对获取到的需求进行正确的理解和分析，最终形成明确的产品需求，以指导后续的设计工作。

需求管理是为了有序地对需求进行管理和控制，并确保需求之间的双向追溯性以及需求与项目计划和工作产品间的一致性。

2 Scope 范围

本文档适用于南京文思创新软件技术有限公司中采用瀑布、迭代软件开发模型的软件项目。

读者为项目组成员、项目管理人员和其它相关人员。

3 Abbreviations and Acronyms 术语和缩略语

4 Policy 方针

1、要确保项目的参与者理解需求，并获得项目的参与者对需求的承诺。

2、要有需求跟踪矩阵来维护需求的双向追溯性，并且当需求发生变更时，及时更新需求跟踪矩阵。

3、在整个需求开发管理过程中，项目经理需时时考虑关键任务和商业驱动，并在必要时调整工作；

5 Process Description 过程描述

5.1 Roles and Responsibilities 角色和职责

5.2 Entrance Criteria 入口准则

项目已启动

5.3 Input 输入（未定）

《项目启动报告》等任何与用户需求相关的材料

《产品设计规格》

5.4 Activities 活动

5.4.1 Summarize 总述

本文档包含需求开发和需求管理两大过程。其中需求开发过程从项目启动初期到所有需求文档开发结束；需求管理过程的启动略晚于需求开发过程，且和需求开发过程迭代进行，并延续至项目结束。两大过程的具体活动描述见如下文档。

5.4.2 Flow Chart 流程图

图表 1 需求开发与管理过程

5.4.3 Requirements Development and Validation 需求开发及确认

项目启动后，项目经理需识别该项目的需求来源并确定提供需求的客户方接口人，并与客户方接口人明确需求下发的方式及需求接收的准则并将其文档化，在获得双方认可之后纳入配置库，以作为我方人员对《产品设计规格》确认的准则。

5.4.3.1 需求澄清活动

项目经理获取《产品设计规格》之后，将其纳入配置库并邮件通知项目组成员。待项目组成员（包括开发、测试、资料）经过初步分析之后，客户方接口人需指定客户方人员进行需求澄清活动，以保证项目组成员对需求理解的正确性，一致性。

需求澄清的方式包含但不限于如下形式：

1）需求澄清会：由客户方人员在需求澄清会议上讲解需求功能点。我方对需求的疑问及需求答疑需以会议纪要的形式记录；

2）需求疑问的文档跟踪：我方人员需定期或事件驱动式整理并文档化需求疑问，并及时将需求疑问的答疑结果和客户方确认。

如上所有的文档需纳入配置库进行管理。

需求澄清活动的内容包含但不限于如下内容：

1）讲解《产品设计规格》中涉及到架构需求，以帮助我方人员理解所需实现的功能对架构需求的影响；

2）讲解功能性需求和质量属性需求（例如性能、效率、安全性、互操作性等）的具体描述，包括其中量化的功能需求是否合理，以保证我方人员对其中的操作概念和场景描述理解的正确性；

3）帮助我方人员理解对于性能、产品架构等有重大影响的关键性需求，并就需求的优先级达成共识；

4）讲解接口需求定义（包含内部接口和外部接口），保证接口定义的完整性和兼容性；

5）对于一些理解较困难或容易产生歧义的需求，客户方需进一步通过原型图，数据模拟图（包括数据流图、实体关系图、状态转换图等）等，来帮助我方进一步理解需求；

对于需求澄清活动中发现的需求类缺陷，待客户方修改完成后，项目经理需及时将最新的《产品设计规格》在配置库上予以更新。

5.4.3.2 评审及确认《产品设计规格》

需求澄清活动结束后，我方人员需对更新后《产品设计规格》进行进一步的评审，以保证需求的完整性，正确性，并确保该文档足以指导后期的需求开发活动。

《产品设计规格》评审活动结束后，项目经理按照项目前期确定的需求接收准则对《产品设计规格》进行确认，确认的内容可以包括但不限于如下内容：

1)《产品设计规格》是否按照双方约定的形式下发；