文档编号:XM-202-2008 文档版本:第一版发布日期:2008-3-5实施日期:2008-3-5适用范围:公司软件开发项目密 级:普密北京天阳宏业软件技术有限公司项目管理规范：软件需求管理北京天阳宏业软件技术有限公司二○○八年二月TS 102-2008目 录1概述 (1)1.1术语定义 (1)1.2本规范的“原型” (2)1.3本规范的使用说明 (2)2软件需求管理模型 (3)2.1需求开发 (4)2.2需求变更 (4)3需求开发 (5)3.1需求获取 (7)3.1.1 通过项目立项启动会获取初步需求 (7)3.1.2 通过需求调研收集基本需求 (7)3.1.3 通过技术验证充实需求 (8)3.2需求分析 (8)3.3软件需求说明书编制及项目组内审 (9)3.4需求验证 (10)3.4.1 技术验证 (10)3.4.2 需求评审 (10)3.4.3 测试 (10)3.4.4 验收 (10)4需求变更 (11)4.1项目组需求变更 (11)4.2公司需求变更 (12)附件A1：项目需求概要表 (13)附件A2：用例表述单 (14)1 概述需求分析奠定了软件工程和项目管理的基础，公司目前在软件需求管理方面普遍存在如下问题：1）对需求管理的重视程度不够，缺少完备的需求收集、整理汇总和分析机制；2）项目执行中需求工作持续时间短，需求分析不充分，需求没有有效地分层分级；3）需求表达缺乏结构化，直接影响了项目团队对需求理解的一致性和成果的质量；4）项目人员关注技术，不关注客户和应用；5）没有需求基线，需求变更控制缺乏依据。

上述这些问题是导致项目延期、成本增大、客户投诉的重要因素，也是项目后期遗留问题“越来越多”的直接诱因。

本规范是北京天阳宏业软件技术有限公司（以下简称公司）项目管理规范系列之软件需求管理分册，用于指导项目软件需求管理，属公司保密文件。

本规范适用于公司所有的软件开发项目（以下简称项目）。

本规范不是一成不变的，它会随着公司发展和企业项目管理实践进行修订。

1.1 术语定义本节对所涉及到的与需求管理相关的术语予以定义，其他术语参见《XM-201-2008 项目管理规范：总体框架和操作平台》。

1) 系统内部和系统外部对软件系统而言，系统内部是指属于本软件系统范围内的工作，而系统外部则特指超出本软件系统的所有工作。

例如，系统外部接口就是指与其他软、硬件系统的数据交互通道、数据格式和交互规则等。

2) 需求需求是指从软件系统外部能发现系统所具有的、满足用户的特点、功能和属性，需求为开发者指明了系统的功能行为和质量特性，是对开发者进行软件开发的要求。

本文的需求等同于软件需求。

3) 需求层次软件需求包括三个密切相关的层次：业务需求、用户需求和功能需求（含非功能需求）。

4) 特性特性（Feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

5) 软件需求说明书 / 软件需求规格说明软件需求说明书，也叫软件需求规格说明(Software Requirements Specification，SRS），是对软件需求的中说明性文档，在开发、测试、质量保证、项目管理以及相关项目功能中起着十分重要的作用。

1.2 本规范的“原型”本规范以机械工业出版社2001年5月出版的《软件需求》（美国Karl E. Wiegers著）为“原型”，结合天阳宏业公司项目管理环境和项目实际问题，并在模型、分类和实用层面进行了提炼和创新，成为公司软件需求管理规范。

本规范中有多处引用了《软件需求》中的图表和文字，像图“软件需求层次”、“软件需求和其他项目工作的关系”等。

需要注意的是，本规范有很多与《软件需求》不同的地方，有的概念甚至相差很大。

1.3 本规范的使用说明如同所有其他项目管理规范一样，软件开发项目中的需求管理也需要项目经理根据项目特点和约束条件对本规范采用的模型进行剪裁，以适应项目的实际需要。

诸如推广实施等非开发类项目“需求获取”工作可能很少，如果客户要求明确、具体，可能不需要进行需求调研并编制《需求调研报告》。

即使有部分开发工作，需求获取、需求分析占用的时间也较少。

由客户把握需求并进行管理的项目，对项目组而言，客户提出需求的行为可能是“不完整”、“缺乏分析”的，这种情况下要对客户每次提出的需求进行书面记录，并汇总之前已经提出的需求和已经完成的开发成果，进行需求分析，找出存在的问题并跟客户进一步沟通、澄清，以保证最终成果的一致性和完整性。

这种项目尤其要注意的是，尽管客户不断提出需求和要求，项目经理要时刻保持对“项目范围”的清醒认识——我司项目经理虽然不是实际意义上的项目主管，但却对交办任务的执行负责。

譬如，客户提出与“ERP系统对接”的要求，项目经理和项目组就应该主动跟客户和ERP开发厂商进行沟通，以确定对接内容、数据格式和传输要求等。

项目类型是多样的，剪裁是必须的——对一个具体的项目而言，最适合的即为最好。

2 软件需求管理模型总体上看，软件开发项目管理包括技术和管理两个层面，“做什么”属于需求管理范畴，“怎么做”属于技术实现范畴，项目计划则是二者之间的“桥梁”，是“做什么”的具体落实，是“怎么做”的整体规划。

因此，从软件开发项目的整体管理层面看，需求管理和计划管理无疑是整个项目管理的“源头”和重中之重。

图2-1 公司软件需求管理模型软件需求管理由需求开发和需求变更两部分组成，覆盖整个项目生命周期的所有阶段，也是项目控制的重要内容——从项目生命周期管理角度看，需求开发属于项目组管理的范畴，而需求变更中的部分工作与组织项目管理环境相关，像定义需求变更过程、建立控制机构都是由部门或公司层面完成的，评估、评审则需要二者的共同参与。

2.1 需求开发需求开发包括需求获取、需求分析、需求说明书编制及项目组内审、需求验证四部分。

需求获取：为软件产品的用户（使用人）进行分类，指定用户类代表，获取每个用户类的需求，收集每类实际用户的作业程序以及这些作业所支持的业务需求。

需求分析：对用户提供的信息进行标识，与已收集内容汇总、整理，对用户作业需求、业务规则、功能需求、非功能需求（软件质量属性）及用户建议等信息进行归纳、分析，刻画软件产品组成结构，对组件重要程度予以描述。

准备需要继续澄清的问题，进一步获取需求信息并分析，直到获得较为满意的结果为止。

软件需求说明书编制及项目组内审：将所收集的需求编写成《软件需求说明书》，对软件模型、组件间关系进行描述；组织项目组成员对编制完成的文档进行讨论、审查；由项目经理发起评审申请，按要求提交《软件需求说明书》、技术验证说明及相关资料。

需求验证：包括需求评审、进一步技术验证、测试和验收。

评审人对需求说明书的评审，要确保在评审会议召开前就用户需求达成基本的理解与共识——最终实现需求基线的定义。

技术验证可能从需求分析开始，并持续到项目验收。

《软件需求说明书》是测试和验收的依据。

2.2 需求变更需求变更包括定义需求变更过程、建立控制机构、评估变更影响、审批四部分。

定义需求变更过程：为公司正式需求变更定义工作程序，保证能沿着预先规定的程序执行下去，并实现需求变更的审批。

建立控制机构：成立正式需求变更的机构，对备选评审人进行定义和分类。

评估变更影响：对需要变更内容的工作量、影响大小（正影响和负影响）予以评估，为审批决策提供依据。

审批：做出决策：同意变更或拒绝变更。

3 需求开发如图3-1所示，需求开发包括需求获取、需求分析、需求说明书编制和需求验证四部分。

图3-1 需求开发总图软件需求包括三个不同的层次：业务需求、用户需求和功能需求，功能需求中还包含对非功能需求的描述。

业务需求（Business Requirement，简称BR），是反映客户（个体或组织）对软件产品高层次的目标性要求，反映了客户方面业务改进的设想和系统建设的企盼，是其他层次需求必须遵从的方针和准则。

用户需求（User Requirement，简称UR），是对用户未来通过使用软件（产品）必须完成任务的描述，反映了客户对业务流程和业务操作层面的改进期望。

功能需求（Functional Requirement，简称FR），是对软件开发者必须实现的软件功能的定义，反映了客户对软件产品开发行为的约束。

非功能需求（Non-Functional Requirement，简称NFR）是一类“特殊的”功能需求，一般在功能需求中专门描述——非功能需求一般采用软件质量特性进行分析，并根据项目实际情况进行权衡，给出说明。

图3-2 软件需求层次需求说明书中对功能需求的描述指出了软件系统应具有的外部行为，对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集——以系统观点看待软件需求对系统确保软件开发项目的成功十分重要，因为所有的软件系统都不是完全孤立运行的。

作为功能需求的补充，软件需求说明书还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。

它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。

所谓约束是指对开发人员在软件产品设计和构造上的限制。

质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。

本文附件A1给出了《项目需求概要表》，供项目组参考使用。

3.1 需求获取需求获取来自于项目立项启动会、需求调研和审前技术验证三个方面。

3.1.1 通过项目立项启动会获取初步需求立项启动会为项目经理或项目组提供了初次了解项目的机会，让项目组对商务启动期工作成果和客户要求有个较为系统的掌握，对启动会要完成的工作内容的详细描述参见《XM-201-2008 项目管理规范：总体框架和操作指南》的4.4节。

3.1.2 通过需求调研收集基本需求需求调研是需求获取的主要手段。

随着时间的推移，客户先前提出的想法和建议可能会出现变化，公司之前编制的方案建议和商务承诺也可能需要一些改变……项目经理应对此有清醒的认识，要保持跟客户的继续接触和进一步沟通——通过需求调研完成对业务需求、用户需求和功能需求（非功能需求）的收集。

需求获取要求对用户进行分类，指定用户代表，收集用户代表的作业程序以及为实现这些作业程序所要求的功能需求。

实际工作中，项目组经常会碰到三类问题：无法与最终用户交流；客户缺乏耐心；陌生的业务领域。

无法与最终用户交流：客户和用户的分离或用户不配合是造成无法与最终用户交流的原因，项目组要对客户施加影响，争取与用户见面——根据形势判断无法实现时，要“以客代用”积极跟客户进行交流，收集需求。

客户缺乏耐心：项目经理带领项目组先行编制需求（草稿）文档，列出项目约束条件和待澄清问题清单，邀请客户一同进行讨论——具体形式可采用非正式的交流，也可根据情况邀请客户参与正式评审。