需求管理过程.docx
《需求管理过程.docx》由会员分享，可在线阅读，更多相关《需求管理过程.docx（17页珍藏版）》请在冰豆网上搜索。
需求管理过程
软件过程标准
需求管理过程
V1.0
修订记录
版本号
日期
作者
授权人
授权日期
描述
0.9
2002/07/19
万志鹏
苏光
2002/07/18
第一次编制,苏光指导
0.99
2002/07/29
万志鹏
苏光
2002/08/01
根据评审意见修改过程，并转换为公司文档格式。
1.0
2002/08/12
万志鹏
彭柏林
2002/08/12
通过批准
1目的和范围
2
本过程的目的在于为公司实施与需求相关的方针提供指南。
该过程对所有公司负责需求采集的项目适用，也适用于那些客户在自行采集需求时需要帮助的项目。
术语简称与解释
3
总经理：
简称GM，指公司总经理，具备法人代表资格。
副总：
简称VGM，公司的一种职务，指公司副总。
项目经理：
简称PM，公司的一种职务，一般由具备项目管理经验和行业经验人员承担，负责项目的管理活动。
项目负责人：
简称PL，项目组组长，临时性职务，负责项目的开发活动，如无变更，
生存周期与项目生存周期相同。
需求分析人员：
简称RA，通常由项目组中成员承担此角色，可以是项目负责人也可以项目组中其他人员。
软件设计人员：
简称SD。
在公司一般指系统分析员和程序员（包括高级程序员）；在项目中指项目组中的设计人员。
软件质量保证：
SQA，一种软件质量保证活动，在公司通常也用SQA代表质量保证活动者，目前由公司品管部执行此活动。
配置管理员：
简称CC，在公司中负责所有项目的配置管理活动。
进入准则
4
进入准则如下：
Ø来自客户的关于需求的文档经过公司审批；
Ø
Ø来自客户的标识有意进行某个项目的信函，并且经过公司审批；
Ø
Ø总经理对内部项目的授权，有相关文件（文档）表明是经过审批的；
Ø
Ø公司与客户签订的合同。
Ø
附注：
满足其中任何一种条件均可。
退出准则
5
退出准则如下：
ØSRS的文档已准备好，经过评审和批准。
Ø
阶段交付产品
6
本阶段交付有：
Ø经过评审并得到批准的SRS文档；
Ø
ØSRS评审报告；
Ø
Ø变更请求；
Ø
Ø变更请求单日志；
Ø
Ø影响分析报告。
Ø
使用者
7
本文件的使用者如下：
VGM、RA、SD、PM、PL、QA。
过程流图
8
过程
8.1
需求收集与获取
8.1.1
8.1.2
8.1.3
需求评审
8.1.4
8.1.5
8.1.6
需求变更管理过程
8.1.7
8.1.8
8.1.9
过程描述
8.2
需求管理过程被分为3部分，包括：
需求获取和采集过程、需求评审过程、需求变更管理过程。
需求收集与获取规程
8.2.1
Ø需求可能来自以下任何一种渠道
Ø
⏹客户的需求文档
⏹
⏹工作范围描述文档
⏹
⏹电子邮件
⏹
⏹合同
⏹
Ø随后，进行需求文档格式的评审：
Ø
⏹当需求不是以公司格式提交时，项目经理/项目负责人可选择如下处理办法：
⏹
将需求转换成金恒宇公司的格式，或采用用户的需求文档格式。
⏹当客户特别要求用他们自己的格式时，应满足他们的要求。
⏹
Ø就以下方面对评审需求
Ø
⏹正确性。
正确性取决于技术人员
⏹
⏹完整性。
完整性取决于技术人员以及SQA人员
⏹
⏹可行性。
可行性研究由PM/PL在评审时进行，在进行估计时进一步完善对可行性的研究
⏹
⏹一旦在需求文件中发现缺陷/问题，将编制评审报告，并从客户那里征求进一步的阐述或建议或更多输入
⏹
⏹如果评审报告表明需求清晰、完整而且正确无误，需求文档得到基线化；
⏹
⏹需求文档命名应遵守命名规则，并检入配置管理（CM）工具/库；
⏹
⏹SRS的评审报告也要置于配置管理之下
⏹
需求评审规程
8.2.2
Ø在SRS被用于开展进一步的策划和开发活动之前，SRS必须经过评审
Ø
Ø制定评审计划，选定SRS评审人员，主要有：
VGM、PM、PL、RA、SD、关键技术人员。
Ø
Ø评审进度安排要通知给评审小组成员，交流的方式可以是E-MAIL亦可是书面通知
Ø
Ø分发SRS文档以及其他客户提供的资料和参考资料，评审小组成员就SRS进行个人评审，如果发现任何缺陷，将他们列入个人的缺陷清单
Ø
Ø评审者参加评审会议，分配评审组角色
Ø
Ø读者朗读SRS文档
Ø
Ø当任何评审组员发现潜在的缺陷时，读者停止朗读，小组讨论它是否是SRS的一个缺陷，若确实存在缺陷，由记录员负责记录下来
Ø
Ø以上过程反复进行直到所有的缺陷均被讨论并达成一致意见
Ø
Ø记录员做出最终缺陷列表，评审小组负责人将其通知客户
Ø
Ø需求分析人员就评审中发现的缺陷征求客户的意见
Ø
Ø评审小组就缺陷严重程度决定是否进行再评审
Ø
Ø一旦再评审是必须的，评审报告应反映这个情况并采用本规程安排及执行再评审
Ø
Ø如果在SRS文件中找不到重要缺陷，亦认为再评审无必要，则可批准该SRS文档，并基线化
Ø
Ø基线化的SRS版本应检入配置管理（CM）工具/库
Ø
需求变更管理规程
8.2.3
Ø当需求发生变更，公司要提出变更请求、这个工作可以由公司或客户来做
Ø
Ø变更请求必须有一个唯一的编号
Ø
Ø对变更进行影响分析，以评估变更的规模。
一旦发现变更影响巨大，以至波及到项目工作量、进度，成本，变更将转送到公司高层经理和市场/财务部门决策是否变更合同
Ø
Ø当变更被认可（小变更由公司控制，大变更要经过客户许可）变更申请转变成变更令，并付诸实施
Ø
Ø更新SRS文件。
如果有要求，更新其他文件
Ø
Ø为这些变更的进行提供资源（人，软件、硬件），如有必要时。
Ø
Ø将更新过的文档置于CM的管理之下（CM工具/库）
Ø
Ø将SRS及其他文件的变更通知所有相关人员
Ø
Ø按照项目跟踪过程与活动，对变更的执行进行跟踪
Ø
Ø一旦变更实施，且实施通过验收，变更请求单上将标注为闭合
Ø
Ø为便于在以后参阅，关于该变更的所有信息将保存在过程数据库中
Ø
验证机制
8.3
验证机制如下：
Ø配置审计
Ø
⏹对执行期超过六个月的项目应当在每个月、每个版本发布前、任何外部审计前进行。
⏹
⏹对执行期少于六个月的项目应当在每15天、每个版本发布前、任何外部审计前进行。
⏹
Ø由SQA/独立小组进行的内部审计
Ø
⏹对执行周期超过六个月的项目每个月组织内部审计。
⏹
⏹对执行周期少于六个月的项目每15天组织内部审计。
⏹
Ø外部审计
Ø
⏹ISO监督审计—由外审人员安排日程。
⏹
⏹CMM相关评估——由评估人员安排日程。
⏹
Ø给管理高层的关于需求管理相关活动的定期报告
Ø
⏹对执行期少于六个月的项目应当每周进行报告
⏹
⏹对执行期超过六个月的项目应当每15天进行报告
⏹
度量
8.4
对需求相关活动的评估指标如下：
编号
评估指标
频率
责任
来源
1
需求数量
每15天
PM/PL
SRS
2
需求变更数量
每周
PM/PL
变更日志
3
已认可的变更数量
每周
PM/PL
变更申请日志
4
正在执行的变更数量
每周
PM/PL
项目状态报告
5
需求相关活动中耗费的工作量
每周
所有参与需求相关活动人员
时间表
6
预期在需求管理中耗费的工作量
每周
PM/PL
项目计划
7
实际在需求管理中耗费的工作量
每周
所有参与需求活动人员
项目状态报告
9活动职责矩阵
编号.
活动
VGM
PM
PL
RA
SQA/SEPG
1
获得需求
-
S
S
P
-
2
评审需求
S
P
P
P
S
3
准备SRS
-
S
P
P
-
4
评审SRS
S
P
P
P
S
5
认可SRS
S
P
S
S
S
6
认可变化
S
P
S
P
S
7
影响分析
S
P
P
P
S
8
管理SRS
S
S
P
S
S
9
升级PDB
-
-
-
-
P
附注：
P:
主要职责
S:
次要职责
参考资料
10
SEI-CMMversion1.1
附件
11
TM_SDLC_SRSSRS模板
FM_SDLC_REVW缺陷评审/测试表
CL_SDLC_REQE需求获取检查单
CL_SDLC_RQRWSRS评审检查单
SRS评审报告
变更请求表
变更请求记录表
影响分析表
升级会员 