软件需求管理过程

1、软件需求管理过程目录14>>. 目的 22>. 范围 23>. 职责 24>. 工作程序 34>.1 软件需求收集、分析和文档化过程 34>.1>.1 需求收集和编制特征需求说明 34>.1>.2 下达软件项目任务书 44>.1>.3 制定需求分析计划 44>.1>.4 需求的分析过程 44>.1>.5 编制软件需求说明书 44>.1>.6 制定软件验收计划 54>.2 需求变更管理过程（包括增加、删除和修改） 54>.2>.1 需求更改申请的提出 64>.2&g

2、t;.2 影响分析阶段 64>.2>.3 申请评审、批准阶段 74>.2>.4 修改需求说明书 74>.2>.5 评审、批准 74>.3 需求追踪 75>参考资料 8Toc401135011目的明确需求管理全过程的主要工作和内容，具体包括以下方面： 保证客户、客户经理和软件开发项目组之间对客户需求具有共同的理解， 并 且在项目的整个生命周期内都是有效的通过 系统工程 组 编写 特征需 求说明 FRS( Feature Requirements Specification )，将系统需求中的软件、 硬件和其它系统成分的工作分开， 软件 需求以外的工

3、作由软件组之外的人员完成软件项目经理明确定义软件需求说明书 SRS( Software Requirements Specification )中要求的内容并文档化软件需求说明书必须完整、正确、及时地反映客户的需求，要仔细进行 分析、消化并详细描述，尽量做到所有相关人员都能正确理解软件需求说明书 经评审后存档， 即作为软件开发计划和活动进行管理和 控制的基线一旦软件需求说明书经过双方签字认可后，每当用户需求发生变更时， 必须进行需求变更，受其影响的项目计划、 活动和工作产品必须进行相应的修正， 并通告所有受影响的组织和个人。确保最终的软件工作产品成、 活动和计划与软件需求说明书相一致， 并能通

4、 过软件项目经理对软件需求的可追踪性进行管理。_Toc401135012范围本过程适用于以下范围：新的软件开发项目原有软件系统升级、维护自有工具软件的开发软件项目开发过程中的需求变更_Toc401135013职责1）系统工程组（产品经理、研发经理、客户经理）负责编制特征需求说明 书。2）研发经理下达 软件项目任务书，指定软件项目经理， 协助软件项目经 理成立软件项目小组3）软件项目经理负责组织进行软件需求的收集、分析（必要时编制需求分 析计划）；负责制定软件需求说明书、软件验收计划等，并对需求实现情况进行 跟踪、检查。4）软件项目经理负责组织相关人员进行评审工作5）高级管理者负责批准对外承诺，

5、并定期审查需求管理活动 _Toc4011350144>. 工作程序_Toc4011350154>.1 软件需求收集、分析和文档化过程_Toc4011350164>.1>.1 需求收集和编制特征需求说明 与客户有了合作意向或合同签定后及产品研发部确定开发产品时， 系统工程 组收集项目的需求（过程可参见软件需求收集指南 ），分析项目系统需求，并 将其分配为软件、 硬件和其它系统成分， 决定每一个需求的特征和需要修改的缺 陷，形成特征需求说明书 ，以作为软件项目小组工作的先决条件， 特征需求 说明书必须经过评审（评审的方式根据需要选择适当的方式举行，可参见评 审过程）以确保其

6、内容准确、完整地反映了客户的需求，同时它成为制定软件 需求说明书的基础；评审通过才能进入下一阶段。说明：对于纯软件的项目，可以不制定特征需求说明书 ，进入下一 阶段。_Toc4011350174>.1>.2 下达软件项目任务书研发经理发出软件项目任务书 ，初步指定项目开发人员和软件项目经理， 明确提供项目开发的可用资源， 并将软件项目任务书 提交到技术管理组织评 审（评审的方式根据需要选择适当的方式举行，可参见评审过程 ），作为项目 正式立项，以确认项目的正式启动。_Toc4011350184>.1>.3 制定需求分析计划如果项目规模较大， 需求收集超过二个月的， 软件

7、项目经理负责制定 需求 分析计划，否则，可以不进行需求分析计划的制订。_Toc4011350194>.1>.4 需求的分析过程对于初次进行软件需求收集、 分析和管理的人员， 软件项目小组安排进行必 要的培训，以便他们能按照公司的标准要求完成需求分析和管理活动。项目小组通过分析、收集、标识、细化和评审等方式鉴别出不完备的、遗漏 的或多余的用户需求， 以尽可能详细的描述来表达客户对软件的功能要求， 以及 对软件界面、系统运行环境、安全、稳定性、可扩展性等方面的要求。该要求需 在软件需求说明书中描述并由客户代表（客户经理）签字确认。对需求的描 述详尽程度应满足软件设计和开发的基本要求。

8、适当的变更和修改将使用需求变 更管理过程 4>.2 。需求指出的是，在现实工作中，需求的定义应服务于公司的 商务过程的要求，并以达成商务谈判的目标为原则。说明：需求定义、项目策划和设计可能会有所重叠。_Toc4011350204>.1>.5 编制软件需求说明书1）软件项目经理组织编写 软件需求说明书，编制完成后必须组织软件工 程组、有影响的组或人员评审 （评审方式根据需要选择适当的方式举行， 可参见 评审过程），评审出问题的需求必须做出更改，经过评审的软件需求经 SCCB、 高级管理者和客户 （客户经理） 批准后入基线库进行管理并作为制定开发计划的 基础。2）软件需求说明书批

9、准后，由有关人员讨论协商，确定由软件需求引 起的相应职责和活动，这些人员可能包括：客户经理、计划制定人员、软件设计 人员、软件开发人员、软件系统测试人员、质量保证人员、配置管理人员等。_Toc40113509><>214>.1>.6 制定软件验收计划 软件项目经理在软件需求说明书编制过程中或编制完成后应组织制订 软件 验收计划，该验收计划需经过评审 （评审方式要根据需要选择适当的方式举行， 可参见评审过程）、SCCB批准，并取得客户的认可，以便在项目结束时按计 划验收，验收结束后应填写软件验收报告_Toc4011350224>.2 需求变更管理过程（包括增加

10、、删除和修改）_Toc4011350234>.2>.1 需求更改申请的提出1）客户提出的修改请求，如果是以口头的方式，软件项目小组人员或客户 经理应对顾客的请求进行记录，请客户进行确认后，填写需求变更申请表 提交软件项目经理。2）如果请求是由公司内部人员提出的，提出者应填写需求变更申请表 提交软件项目经理。_Toc4011350244>.2>.2 影响分析阶段软件项目经理接到需求变更申请表 后，应对需求的变更情况进行登记 （记 录于软件需求与软件需求变更跟踪表 ），对于紧急的变更应及时进入影响分析 阶段；而其他的变更应进行汇总，统一进行分析。影响分析包括以下方面：审查

11、必要性、可靠性和合理性；影响或（技术、进度、资源、成本、系统结构等）评 估；规模和工作量的估算；标识、规范；文档化。对于小的变更应予记录并累计 工作量， 当累计的工作量将达到预定的工作量时， 应及时通知客户方， 超出的部 分有可能计算成本并收取相应的费用，但须客户确认后实施。_Toc4011350254>.2>.3 申请评审、批准阶段 如果变更请求涉及紧急事项，则应由有关部门和个人立即组织评审并由SCCB审核批准，而后由责任人负责实施。如果是非紧急事项，由软件项目经理 集中组织评审、批准（SCCB）（评审的方式根据需要选择适当的方式举行，可参见评审过程），评审人员应包括受影响的组和

12、人，以便与他们协商更改。若此变更涉及组织外部， 则应有组织的高级管理者确认， 并得到客户的确认 后实施更改；若此更改仅涉及组织内部，由SCCB比准后实施更改。_Toc4011350264>.2>.4 修改需求说明书更改时，如果软件项目经理安排项目组的其他人员实施更改， 软件项目经理 应填写任务通知单 ，通知更改人进行更改，并对更改情况进行监督。_Toc4011350274>.2>.5 评审、批准更改结束后，软件项目经理应组织对更改后的 软件需求说明书 进行评审， 并通过SCC呛议批准并得到高级管理者和客户的确认后，才可入基线库进行管 理，配置管理员应及时填写变更通知单通知受影响的组和个人_Toc4011350284>.3需求追踪1）关于软件需求说明书中所描述的所有需求 （包括变更的需求），由软件项 目经理根据软件需求与软件需求变更追踪表跟踪至完成状态。2）高级