软件开发统一标准化工作作业流程V.docx

目录
1 引言 3
1.1 编写目的 3
1.2 适用范围 3
1.3 定义 3
1.4 流程图 3
2 需求调研 4
2.1 概述 4
2.2 需求调研 4
2.3 注意事项 4
3 可行性分析 5
4 需求分析 5
4.1 概述 5
4.2 产物/成果 6
4.3 需求分析任务 6
4.4 需求分析方法 6
4.4.1 原型化 6
4.5 需求报告 7
4.6 划分需求的优先级 7
4.7 评审需求文档和原型 7
5 系统设计 7
5.1 概述 8
5.2 产物/成果 8
5.3 产品设计 8
5.3.1 概述 8
5.3.2 流程图 9
5.4 软件设计 9
5.4.1 概述 9
5.4.2 流程图 9
5.4.3 概要设计 9
5.4.3.1 数据库系统设计 10
5.4.4 详细设计 11
6 软件开发 11
6.1 建立项目开发团队 11
6.2 实施项目开发测试 11
6.3 工作内容 12
6.4 产物/成果 12
7 项目测试 13
7.1 软件测试阶段 13
7.2 概述 13
7.3 流程 13
7.4 软件测试准备 13
7.5 软件测试执行 14
8 内部验收 14
8.1 文档准备 14
8.2 内部验收测试 14
8.3 内部评审 14
9 项目试运行与验收 15
9.1 验收前的准备 15
9.2 用户测试 15
9.3 用户确认 15
10 项目维护 15
10.1 错性维护 15
10.2 完善性维护 15
11 需求变更流程 16
11.1 目的 16
11.2 适用范围 16
11.3 作业流程 17
11.4 流程描述 17
11.4.1 内部项目 18
11.4.2 外部项目 18
11.5 提交需求变更 18
11.6 审核评审 18
11.6.1 工作内容 18
11.6.2 相关角色 19
11.7 反馈 19
12 附录 20
12.1 附录1《软件需求说明书》 20
12.2 附录2《概要设计说明书》 20
12.3 附录3《数据库设计说明书》 20
12.4 附录4《详细设计说明书》 20
12.5 附录5《用户使用手册》 20
12.6 附录6《软件测试说明》 20
12.7 附录7《项目开发计划》 20
12.8 附录8《软件测试计划》 20
12.9 附录9《软件测试方案》 20
12.10 附录10《测试用例文档》 20
12.11 附录11《缺陷报告》 20
12.12 附录12《软件测试报告》 20
12.13 附录13《需求变更申请表》 20

软件开发标准化工作步骤
1 引言
1.1 编写目标
说明编写这份软件开发标准化工作步骤目标，指出预期读者。
1.2 适用范围
互联网开发中心全部项目。
1.3 定义
列出本文件中用到专门术语定义、外文首字母组词原词组。
1.4 步骤图
需求调研
系统设计
软件开发
软件测试
内部验收
用户验收
系统维护
需求分析阶段

概要设计阶段

具体设计阶段

系统编码阶段

系统测试阶段

集成测试阶段

系统测试阶段
项目管理过程
评审过程
软件监督和审核过程
软件配置管理过程
软件需求管理过程
变更控制过规程
文档控制规程
文档开发和管理规范
项 目 流 程
项目开发各阶段
过程管理思想
需求分析

2 需求调研
2.1 概述
需求调研对于一个应用软件开发来说，是一个系统开发开始阶段，需求调研质量对于一个应用软件来说，是一个极其关键阶段，它质量在一定程度上来说决定了一个软件交付结果。怎样从用户中听取用户需求、分析用户需求就成为调研人员最关键任务。
2.2 需求调研
总体而言，需求调研可根据业务步骤、业务规则、表单数据、贯穿系统关系四个方一直进行调研。
l 业务规则
各个步骤、功效点等事项办理，全部会有相关约束或条件，那么需要对其前置条件、后置条件、数据验证、条件判定等进行分析调研。调研对象通常为操作员。
l 表单数据
对各个功效点业务数据、数据项、表单格式、查询条件和其它相关数据进行明确分析调研。调研对象通常为操作员。
l 贯穿系统关系
各个模块或科室之间数据交换、传输和数据共享等，需要我们调研人员和各个模块或科室相关责任人进行多方沟通，确定一个多方满意需求调研结果。
2.3 注意事项
l 调研过程中，用户说很快，不可能等我们全部统计以后，再讲下一个问题。所以，只能在笔记本上速记，有时只能统计1、2个关键字。所以，天天调研结束以后，当日晚上必需整理当日调研情况，写成一份调研日志。整理当日调研统计时，还要整理出待明确问题，下一次再找机会和用户再沟通、确定。
l 调研各个阶段，必需出具相关文档或文件，比如调研计划、步骤图、表单样式、报表格式、背景图片、数据项列表、讨论统计、问题列表等。
l 全部疑问必需等到明确回复，不能出现相互矛盾、似是而非需求。需正确了解用户讲解，假如有问题先做统计，以后将整理问题向用户问询，得到明确结果。需求必需是用户接收和确定，不能有臆测需求。
l 要合理安排好时间和进度。有时候用户还有自己要做事情，不一定能立即对应。所以必需提前预约好时间，确保整个需求调研进度。
l 能主动引导用户。当用户出现疑虑，而调研人员能明白且能做好用户想要东西时候，调研人员能立即主动引导用户，具体讲解我们所知道东西，并能让用户接收和确定。
l 如遇企业有相关原型或产品，调研人员需先具体了解企业相关原型和产品，依据成品，找出当地化差异化需求。
3 可行性分析
这个阶段要回复关键问题：“对于上一个阶段所确定问题有行得通处理措施吗？”为了回复这个问题，系统分析员需要进行一次大大压缩和简化了系统分析和设计过程，也就是在较抽象高层次上进行分析和设计过程。
可行性研究应该比较简短，这个阶段任务不是具体处理问题，而是研究问题范围，探索这个问题是否值得去解，是否有可行处理措施。
在问题定义阶段提出对工程目标和规模汇报通常比较含糊。可行性研究阶段应该导出系统高层逻辑模型（通常见数据流图表示），而且在此基础上更正确、 更具体地确定工程规模和目标。然后分析员更正确地估量系统成本和效益，对提议系统进行仔细成本／效益分析是这个阶段关键任务之一。
可行性研究结果是使用部门责任人做出是否继续进行这项工程决定关键依据，通常说来，只有投资可能取得较大效益那些工程项目才值得继续进行下去。可行性研究以后那些阶段将需要投入更多人力物力。立即中止不值得投资工程项目，能够避免更大浪费。
4 需求分析
4.1 概述
这个阶段任务仍然不是具体地处理问题，而是正确地确定“为了处理这个问题，目标系统必需做什么”，关键是确定目标系统必需含有哪些功效。
用户了解她们所面正确问题，知道必需做什么，不过通常不能完整正确地表示出她们要求，更不知道怎样利用计算机处理她们问题；软件开发人员知道怎样使用软件实现大家要求，不过对特定用户具体要求并不完全清楚。所以系统分析员在需求分析阶段必需和用户亲密配合，充足交流信息，以得出经过用户确定系统逻辑模型。通常见数据流图、数据字典和简明算法描述表示系统逻辑模型。
在需求分析阶段确定系统逻辑模型是以后设计和实现目标系统基础，所以必需正确完整地表现用户要求。系统分析员通常全部是计算机软件教授，技术教授通常全部喜爱很快着手进行具体设计，然而，一旦分析员开始谈论程序设计细节，就会脱离用户，使她们不能继续提出她们要求和提议。较件工程使用结构分析设计方法为每个阶段全部要求了特定结束标准，需求分析阶段必需提供完整正确系统逻辑模型，经过用户确定以后才能进入下一个阶段，这就能够有效地预防和克服急于着手进行具体设计倾向。
需求分析是软件工程中一个关键步骤。是关乎软件开发成败关键原因。现在软件项目中返工开销几乎占了总开发二分之一，而造成返工关键原因是需求分析不明确。从而引发软件开发中部分列更改。这些更改可能造成浪费大量资源、软件项目无法按时完成等严重问题，所以需求分析是软件设计和实现基础，是软件项目迈向成功重中之重。
4.2 产物/结果
项目阶段/角色
项目经理
产品团体
(BA/BAS/Product M）
开发团体
TTL/Developer）
测试团体
(Test Lead /Tester）
需求阶段
活动：
1、建立CQ/QC中项目目录；
2、在SVN中建立项目目录；
1、分析项目所需资源，风险等
2、预估项目周期

产出：
1、项目计划(大致时间计划)
活动：
1、搜集整理需求

产出：
1、需求说明书
参与：
1、需求分析
2、环境分析
参与：
1、需求分析
2、环境分析
4.3 需求分析任务
简言之，需求分析任务就是处理“做什么”问题，就是依据需求调研，全方面了解用户各项要求并正确表示所接收用户需求。
4.4 需求分析方法
4.4.1 原型化
原型就是软件一个早期可运行版本，它实现了目标系统一些或全部功效。原型化方法就是尽可能快地建造一个粗糙系统，这系统实现了目标系统一些或全部功效，不过这个系统可能在可靠性，界面友好性或其它方面上存在缺点。建造这么一个系统目标是为了考察某首先可行性，如算法可行性，技术可行性，或考察是否满足用户需求等。如，为了考察是否满足用户需求，能够用一些软件工具快速建造一个原型系统，这个系统只是一个界面，然后听取用户意见改善这个原型。以后目标系统就在原型系统基础上开发。原型关键有三种类型：
l 探索型
目标是要搞清楚对目标系统要求，确定所期望特征，并探讨多个方案可行性。
l 试验型
用于大规模开发和实现前，考评方案是否适宜，规格说明是否可靠。
l 进化型
目标不在于改善规格说明，而是将系统建造得易于改变，在改善原型过程中，逐步将原型进化成最终系统。
在使用原型方法是有两种不一样策略。
l 废弃策略
先建造一个功效简单而且质量要求不高模型系统，针对这个系统反复进行修改，形成比很好思想，据此设计出比较完整，正确，一致，可靠最终系统。系统构建完成后，原来模型系统被废弃不用。探索型和试验型属于这种策略。
l 追加策略
先结构一个功效简单而且质量要求不高模型系统，最为最终系统关键，然后经过不停地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。
4.5 需求汇报
需求汇报及软件需求说明书，作用在于便于用户、开发人员进行了解和交流，反应出用户问题结构，能够作为软件开发工作基础和依据，并作为确定测试和验收依据。
经过从用户那里取得全部信息进行整理，以区分业务需求及规范、功效需求、质量目标、处理措施和其它信息。经过这些分析，形成一份《软件需求说明书》 ，此份说明书使开发人员和用户之间针对要开发产品内容达成协议。用户需要评审此文档，以确保内容正确完整表示其需求。一份高质量“需求说明书”有利于开发人员开发出真正需要产品。
输出：
《软件需求说明书》，格式参考 附录1《软件需求说明书》
4.6 划分需求优先级
绝大多数项目没有足够时间或资源实现功效性每个细节。决定哪些特征是必需，哪些是关键，是需求开发关键部分，这只能由用户负责设定需求优先级，因为开发者不可能根据用户见解决定需求优先级。开发人员将为确定优先级提供相关每个需求花费和风险信息。
在时间和资源限制下，相关所需特征能否完成或完成多少，开发人员必需给出意见。
4.7 评审需求文档和原型
用户评审需求文档，是给分析人员带来反馈信息一个机会。假如用户人为编写“需求分析汇报”不够准去，就有必需尽早通知分析人员并为改善提供提议。愈加好措施是先为产品开发一个原型。这么用户就能提供更有价值反馈信息给开发人员，是她们愈加好了解需求。
原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功效齐全系统。
5 系统设计
制订项目计划
软件项目计划是一个用来协调全部其它计划，以指导项目实施和控制可操作文件。它表现了对用户需求了解，是开展项目活动基础，也是软件项目跟踪和监控依据。 
确定开发过程
依据软件项目和项目组实际情况，建立起一个稳定、可控软件开发过程模型，并根据该过程来进行软件开发。 
加强过程控制
过程控制关键包含过程管理、变更控制和配置管理。
5.1 概述
此阶段关键是依据需求分析结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。
5.2 产物/结果
项目阶段/角色
项目经理
产品团体
(BA/BAS/Product M）
开发团体
TTL/Developer）
测试团体
(Test Lead /Tester）
设计阶段
活动：
1、监控项目进度，
2、组织安排本阶段评审
1、任务分解，责任到人
2、细化项目计划

产出：
1、 项目计划（具体到各功效）
参与：
1、系统功效设计

产出：
1、 界面原型
活动：
1、系统功效技术设计
2、数据库设计

产出：
1、 系统功效技术设计
2、 数据库设计说明书
活动：
1、组织测试计划评审

产出：
1、项目测试估量测试计划书

5.3 产品设计
5.3.1 概述
产品设计是专业技术人员依据软件项目需求分析结果来对整个软件系统进行定制、开发、设计一个过程。
5.3.2 步骤图

5.4 软件设计
5.4.1 概述
软件设计阶段关键工作可分为软件概要设计、具体设计两个分阶段。对于复杂程度不高、规模较小或关键性等级较低软件，可将概要设计和具体设计合并为一个阶段实施。
5.4.2 步骤图

5.4.3 概要设计
在概要设计阶段，项目组应依据软件总体框架、软件模型和软件工程实现要求，提出软件设计方法，建立软件总体结构，划分功效模块（软件部件），确定总体结构和部件间关系，定义各个软件功效模块功效、数据接口和控制接口，设计全局数据库/数据结构，要求设计限制，编写《概要设计说明》，由研究室或项目组责任人审批。
对于复杂软件，研究室或项目组应组织对软件概要设计进行评审，以确保软件结构、全局数据结构、关键算法、模块划分、接口关系和软件模型合理性、正确性、完整性，和软件需求一致性。项目组应保持评审结果及任何须需方法统计。
输出：
《软件概要设计说明书》（概要设计部分）,格式参考 附录2《软件概要设计说明书》
5.4.3.1 数据库系统设计
此数据库设计可单独成册，尤其对大型数据库应用系统，即有一个单独《数据库设计说明书》。
输出：
《数据库设计说明书》,格式参考 附录3《数据库设计说明书》
5.4.3.1.1 信息模型设计
　　确定系统信息类型（实体或视图），确定系统信息实体属性、关键字及实体之间联络， 具体描述数据库和结构设计，数据元素及属性定义，数据关系模式，数据约束和限制。
5.4.3.1.2 数据库设计
5.4.3.1.2.1 设计依据
　　说明数据被访问频度和流量，最大数据存放量，数据增加量，存放时间等数据库设计依据。
5.4.3.1.2.2 数据库种类及特点
　　说明系统内应用数据库种类、各自特点、数量及怎样实现互联，数据怎样传输。
5.4.3.1.2.3 数据库逻辑结构
　　说明数据库概念模式向逻辑模式转换所采取方法论及工具，完成数据库概念模式向逻辑模式转换。 具体列出所使用数据结构中每个数据项、统计和文件标识、定义、长度及它们之间相互关系。此节内容为数据库设计关键部分。
5.4.3.1.2.4 物理结构设计
　　列出所使用数据结构中每个数据项存放要求、访问方法、存取单位和存取物理关系等。建立系统程序员视图，包含： 数据在内存中安排，包含对索引区、缓冲区设计； 所使用外存设备及外存空间组织，包含索引区、数据块组织和划分；访问数据方法方法。
5.4.3.1.2.5 数据库安全
　　说明数据共享方法，怎样确保数据安全性及保密性。
5.4.3.1.2.6 数据字典
　　编写具体数据字典。 对数据库设计中包含到多种项目，如数据项、统计、系、文卷模式、子模式等通常要建立起数据字典，以说明它们标识符、同义名及相关信息
5.4.4 具体设计
在具体设计阶段，项目组应对概要设计中产生软件部件进行方法和过程描述，对程序单元内部细节(算法模型、数据结构、具体接口信息等)进行设计，为源代码提供必需说明，并编写《软件具体设计说明》，由研究室或项目组责任人审批。具体设计过程中开始编制《软件测试计划》初稿。
研究室或项目组应组织对具体设计说明进行评审（用户参与），以确保程序单元功效、控制结构、数据结构和算法模型正确性、合理性，程序单元接口明确性、一致性。项目组应保持评审结果及任何须需方法统计。
输出：
《软件具体设计说明书》（具体设计部分）格式参考 附录4《软件具体设计说明书》

6 软件开发
6.1 建立项目开发团体
依据业务需求开发任务书中，对项目完成时间、费用要求，确定项目开发团体人员数量，明确项目经理，建立以项目经理为项目责任人开发团体。团体组建完成后，项目经理组织团体人员进行交流学习和相互熟悉，说明项目任务、目标、规模、人员组成、规章制度和行为准则，个人岗位和责任，建立团体和外界初步联络及相互关系，确立团体权限，建立团体绩效管理机制，争取企业各方面支持，依据团员特点分配职责，搜集相关项目信息。
6.2 实施项目开发测试
依据企业软件项目设计开发制度要求和软件项目管理规范，根据需求实现方案为项目具体开发做好准备。
① 技术人员在项目实现方案框架下
② 依据项目实际要求准备好开发环境和测试环境;
③ 程序员编写程序代码，测试人员设计测试方案和应用案例;
④ 是对需求实现功效说明书和测试计划、测试案例进行评审;
⑤ 撰写测试问题汇报，更正软件Bug;
⑥ 根据要求定时提交相关项目管理信息资料。
6.3 工作内容
软件实现阶段关键工作是依据软件设计结果，进行软件代码编制、调试、代码审查和程序单元测试，验证程序单元和设计说明一致性。本阶段代码审查和单元测试应以开发人员自查自测为主。
实现过程中应要求编码实现规则、编程语言、数据结构、命名约定和注释规则等并遵守这些规则；尽可能使用辅助设计工具；尽可能地重用已经有软件实现规范、实现方法、代码片段、数据结构、标准函数等。进行规范化编程，采取统一编码风格；实现过程中应全方面考虑软件测试工作；充足地考虑到软件可维护性。
软件实现过程中，项目组应组织程序调试、代码自查和程序单元自测，关键包含对软件各功效模块编码正确性、程序设计准则符合性、程序单元测试过程和结果合理性和正确性和测试辅助程序合理性和充足性进行审查和验证，以确保交付测试软件和软件设计说明完全符合。和外部存在多系统交联时，需要组织或参与联合调试试验，以验证接口正确性。
软件实现阶段应开始编写《用户使用手册》和《软件测试说明》文档。
输出：
1、《用户使用手册》，格式参考 附录5《用户使用手册》
2、《软件测试说明》，格式参考 附录6《软件测试说明》
6.4 产物/结果
项目阶段/角色
项目经理
产品团体
(BA/BAS/Product M）
开发团体
TTL/Developer）
测试团体
(Test Lead /Tester）
开发阶段
活动：
1、监控项目进度
2、调整人员安排
3、跟踪处理技术难点

产出：
1、项目计划（更新进度）

活动：
1、具体功效开发

产出：
1、功效单元代码
活动：

1、编写测试用例
和.自动化脚本
组织测试用例评审

产出：
1、测试用例
2、自动化脚本

单元测试阶段
活动：
1、监控项目进度
2、踪处理问题列表

产出：
1、项目计划（更新进度）
2、项目进度汇报

活动：
1、组织代码走查
2、单元测试

产出：
1、功效单元代码
2、单元测试汇报

7 项目测试
7.1 软件测试阶段
7.2 概述
软件错误是不可避免，所以必需经过严格测试。经过对本软件测试，尽可能发觉软件中错误，借以降低系统内部各模块逻辑，功效上缺点和错误，确保每个单元能正确地实现其预期功效。检测和排除子系统（或系统）结构或对应程序结构上错误，使全部系统单元配合适宜，整体性能和功效完整。而且使组装好软件功效和需求保持一致。
7.3 步骤

7.4 软件测试准备
测试组从软件需求分析阶段开始介入，对需求进行分析，风险分析，测试范围等等。即开始编制软件测试计划，在软件概要设计、具体设计和编程实现过程中逐步完善，最终形成《软件测试计划》，并组织测试计划评审。
软件测试计划完成后开始编写相关测试方案，编写测试用例，搭建测试环境。测试用例完成后进行评审，冒烟测试用例覆盖率必需达成100%，系统测试用例达成95%，
输出：
1)《软件测试计划》，格式参考 附录8《软件测试计划》；
2)《软件测试说明》（含测试用例和测试程序），格式参考 附录6《软件测试说明》；
3)《软件测试方案》，格式参考 附录9《软件测试方案》；
4)《测试用例文档》，格式参考 附录10《测试用例文档》；
7.5 软件测试实施
测试人员依据《测试用例》进行软件测试，对发觉错误进入缺点管理步骤，并进行回归测试以验证修更正确性。测试结束后，测试人员应编写《缺点汇报》，及《软件测试汇报》。
在测试阶段后期，组织《软件测试汇报》评审，关键对软件测试方法、测试过程和测试结果有效性和正确性进行审查和评价。项目组应保持评审结果及任何须需方法统计。
输出：
《缺点汇报》，格式参考 附录11《缺点汇报》；
《软件测试汇报》，格式参考 附录12《软件测试汇报》。

8 内部验收
项目完成集成测试和系统测试后进行项目内部验收，关键有三个步骤：
8.1 文档准备
项目经理提交内部验收计划、项目开发总结汇报、产品公布清单；财务主管提交项目财务预算汇报。
8.2 内部验收测试
内部验收测试测试内容和方法即使和系统测试基础相同，但应站在用户验收角度进行，因为它是试运行基础，经过这一步，为用户验收作充足准备。
8.3 内部评审
对提交全部文档及测试结果进行内部评审，完成项目开发总结汇报。
9 项目试运行和验收
试运行和用户验收阶段关键任务是，使全部工作产品得到用户确实定。关键工作有：
9.1 验收前准备
项目经理负责检验产品完整性，包含文档、介质和中间产品等，以确保现场实施成功；负责应用软件现场安装调试，完成安装调试总结汇报；负责制订用户验收计划，并得到用户确实定。
9.2 用户测试 
用户进行验收测试和系统试运行，进行文档和系统移交。
9.3 用户确定
项目经理负责和用户协调，帮助用户进行项目验收，形成用户验收汇报。
10 项目维护
10.1 错性维护
因为前期测试不可能暴露软件系统中全部潜在和隐含错误，诊疗和更正这些错误过程。
10.2 完善性维护
在软件正常使用过程中，用户还会不停地提出新需求，为了满足用户新需求而增加软件功效活动称为完善性维护。假如需求变更很大，那完善性维护将转变为软件新版本开发。系统维护宗旨就是提升用户对软件产品满意度。确保系统正常运行是系统维护根本目标。
11 需求变更步骤
11.1 目标
指导项目部、软件部、质量部、测试部对产品软件变更需求（简称CR）进行控制和管理，规范对应作业步骤, 具体地定义了各步骤步骤中状态、角色和动作。 
明确步骤中各角色职责
规范软件缺点变更过程
11.2 适用范围
全部项目标软件变更需求控制管理。
11.3 作业步骤

11.4 步骤描述
1．项目需求确定，项目计划确定后。在项目标任何阶段，如有任何需求变动提议。 
2．判定是否有必需做需求变更？ 
3．如确定需要需求变更，评定是否对项目现有设计或实现有影响？ 
4．假如有影响：暂停设计或实现，考虑新需求，重新需求分析，设计，实现，修改项目计划。
5．假如没有影响：评定新需求是否紧急？需要加入目前项目，或在下一项目实现？
6．假如加入目前项目：增加新需求工作量，更新项目计划。
7．假如在下一项目实现：在下一项目开始前，搜集全部可加入下一项目标需求变更。在下一项目范围内考虑。 

11.4.1 内部项目
用户提出需求-》项目组对问题进行分析（不明确问题要进行确定，区分问题优先级和处理方案）-》提交变更申请表（包含估量和计划）-》高层领导决议-》审批经过-》依据项目计划实施 。
内部项目通常需求控制权在高层领导中，有时候不一定关注成本，偏重于系统产生价值，对用户而且关键关注实用和易用性上。项目经理或团体关键侧重分析用户需求合理性。
11.4.2 外部项目
用户提出需求-》项目组对问题进行分析（过滤需求是否合理、是否在本版原来做、能否放到二期、需求必需性等）-》和用户讨价还价（把不合理需求、无须要在本期实现功效推掉）-》必需要实现需求-》提交需求变更申请（初步计划和处理方案）-》高层领导决议-》具体分析需求和处理方案-》评定工作量-》设定计划-》用户签字确定-》依据项目计划实施。
外部项目首先应该考虑是企业投入成本和获取收益，比如变更会给企业增加协议额或后期市场拓展机会和对产皮提炼（有项目是项目型产品）。假如上述条件不满足，则首要考虑是怎样推掉需求。
11.5 提交需求变更
编写要尽可能具体，并经过用户、高层经理和项目组内部人员认可。比如测试人员对测试工作量要参与评定，开发人员对开发工作量要进行评定。数据起源基于基层，确保数据正确性。同时补充一点变更带来质控工作量也应该纳入到变更需求表中，比如可能设计项目总结和数据统计工作量。 
  用户提交问题要做好具体统计，确保有据可查，对问题要进行面对面确实定，避免含糊其词用户需求。对确定结果进行统计。
输出：
《需求变更申请表》，格式参考 附录13《需求变更申请表》》；
11.6 审核评审
11.6.1 工作内容
评审组织者组织相关评审者对需求表进行评审。评审者提出评审意见，组织者汇总全部评审意见，并经过开会讨论方法决定对需求表最终评审意见。
11.6.2 相关角色
提议者：需求表提议者。
评审组织者：企业领导、部门领导，尤其是策划部领导。
评审者：企业领导、部门领导、提议者等其它人员。
11.7 反馈
产品经理按评审结论修改对应需求条目，并公布需求版本。
12 附录
12.1 附录1《软件需求说明书》
12.2 附录2《概要设计说明书》
12.3 附录3《数据库设计说明书》
12.4 附录4《具体设计说明书》
12.5 附录5《用户使用手册》
12.6 附录6《软件测试说明》
12.7 附录7《项目开发计划》
12.8 附录8《软件测试计划》
12.9 附录9《软件测试方案》
12.10 附录10《测试用例文档》
12.11 附录11《缺点汇报》
12.12 附录12《软件测试汇报》
12.13 附录13《需求变更申请表》