该帖子同步发自：(yangxuep的博客  访问该博客)

需求管理规程（发布稿）

1. 概述
1.1 编写目的
本规程详细描述了XXX公司的需求管理规范和流程，为规范需求管理过程提供统一标准。本规程制定了在需求分析、需求评审、需求开发、需求跟踪、需求变更控制和需求验收等各子过程的具体操作步骤和控制方法，为项目经理对项目的需求进行有效的管理提供标准方法。

1.2 适用范围
本需求管理规程适用于XXX公司所有销售和合作运营类型项目的需求管理过程，在项目管理的整个生命周期内有效。
本规范从2007年X月X日起正式执行。

1.3 相关术语和缩略语
本规程中使用的名词术语和缩略语见下表。
图表 1：相关术语和缩略语
序号 名词术语或缩略语 详细说明 备注
1 Requirement Management 需求管理 
2 Requirement status 需求状态 
3 Requirement Analyzing 需求分析 
4 Requirement Review 需求评审 
5 Requirement Development 需求实现 
6 Requirement Tracking 需求跟踪 
7 Requirement Change Control 需求变更控制 
8 Requirement User Acceptance Testing 需求验收 
   #此前在首页部分显示#
   2. 需求管理概要
本规程按照需求的生命周期，将需求管理过程划分为：“需求分析”、“需求评审”、“需求实现”、“需求跟踪”、“需求变更控制”和“需求验收”六个子过程域。各子过程域即可以相对独立，又密切相关，共同构成需求管理全过程。

2.1 需求管理相关概念
2.1.1 需求概念
客户为解决某一问题或达到某一目标所需的软件功能。也可以说是系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。

2.1.2 需求管理概念
一种获取、组织并记录系统需求的系统化管理方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。

2.1.3 需求管理过程
需求管理过程是指从需求分析开始到需求验收结束的全过程，在贯于整个项目生命周期中，对需求管理活动的总和。

2.2 需求管理目标
圣诺项目管理规程的创建，主要为实现以下四主要目标：
1. 规范圣诺需求管理流程，减少需求开发费用，缩短需求开发进度，加强需求开发质量。
2. 减少并控制需求的变更，增强需求稳定性，为项目成功提供帮助。
3. 加强项目团队与客户之间建立对需求的共同理解，保证需求管理过程的规范性和合理性。
4. 为整理产品需求提供参考和帮助。

2.3 需求分类
需求分类有多种不同的方法，本规程根据需求的性质和需求功能两种方法来对需求进行分类。按照需求性质划分，将需求分为：“原始需求”、“项目需求”和“新需求”三种类型；按照需求功能划分，将需求分为： “功能需求”、“性能需求”、“环境需求”、“UI需求”、“业务流程需求”、“接口需求”和“其它需求”七种类型。以下是根据需求性质和需求功能进行分类的方法来划分的需求类型。
2.3.1 需求性质类型
根据需求性质，将需求分为以下三种类型：
1. 原始需求：“原始需求”是指项目售前移交时，由售前提供的需求清单中的需求。原始需求是销售和售前在项目售前阶段和客户沟通，双方认可的对项目范围的共同理解。原始需求也可以用于做项目成本估算的依据。   
2. 项目需求：“项目需求”是指在原始需求范围之外，在确认需求基准之前产生，且经项目经理和客户沟通后，双方共同认可属于项目范围内的需求。原始需求加项目需求是项目成本预算的依据。项目需求的多少，可以反应出项目售前交接的质量，也可以反应出项目经理对项目范围边界控制的能力。
3. 新需求：“新需求”是指在确认需求基准后提出，经项目经理和客户沟通后，双方共同认可不属于项目范围内的需求。新需求也可以作为项目经理业绩考核的依据。.  
2.3.2 需求功能类型
1. 功能需求：功能需求是指软件具体功能性的相关需求。
2. 性能需求：性能需求是指系统性能级需求。包括系统的相应时间、资源限制、数据精确性、系统适应性等。
3. 环境需求：环境需求是指为使系统稳定运行所需的软、硬件环境、网络环境、系统软件环境、第三方软件环境等。
4. UI需求：界面需求是指系统和用户交互的界面需求。
5. 业务流程需求：包括各种受理渠道的用户注册、注销、变更、续费等业务流程，及相关业务处理策略，如用户状态处理、计扣费策略等。
6. 接口需求：接口需求是指系统和第三方系统的接口需求。
7. 特殊需求：无法归入以上六类需求的其它相关需求。包括安全性、可靠性、可维护性、可移植性、可扩展性相关需求等。

2.4 需求状态
2.4.1 需求状态定义
本需求管理规程将需求定义为以下9种状态，各状态的定义描述如下：
1. Open：对于原始需求或接收到的正式需求，但未正式进行需求分析之前的需求状态统一定义为“Open”状态。
2. Analyzed：对需求状态为“Open”的需求，若已完成需求分析过程，但还未正式通过需求评审前，其状态统一定义为“Analyzed”状态。
3. Reviewed：对需求状态为“Analyzed”的需求，若已正式通过需求评审，但还未完成测试，或测试结果为不合格之前，其状态统一定义为“Reviewed”状态。
4. Resolved：对需求状态为“Analyzed”或“Reviewed”的需求，若已完成需求设计和编码，且已通过单元测试，其状态统一定义为“Resolved”状态。
5. Passed：对需求状态为“Resolved”的需求，如果已通过正式测试，其状态统一定义为“Passed”状态。
6. Unresolved：对需求状态为“Resolved”的需求，如果未通过正式测试，其状态统一定义为“Unresolved”状态。
7. Closed：对需求状态为“Resolved”的需求，若需求已正式上线商用，且得到客户和项目团队的共同认可后，其状态统一定义为“Closed”状态。
8. Cancel：当原定义的某些需求被取消时（包括上线前取消和上线后取消），其需求状态统一定义为“Cancel”状态。
9. Failed: 对需求状态为“Closed”的需求，若需求在上线商用后发现问题或存在缺陷，需要对其进行修正时，其需求状态统一定义为“Failed”状态。

更详尽内容，请参见附件！

/blog/UploadFiles/2009-5/57582310.rar

/blog/UploadFiles/2009-5/57771522.rar

/blog/UploadFiles/2009-5/57382276.rar