需求管理过程文档格式.docx
- 文档编号:14986841
- 上传时间:2022-10-26
- 格式:DOCX
- 页数:14
- 大小:206.72KB
需求管理过程文档格式.docx
《需求管理过程文档格式.docx》由会员分享,可在线阅读,更多相关《需求管理过程文档格式.docx(14页珍藏版)》请在冰豆网上搜索。
彭柏林
通过批准
1目的和范围
2
本过程的目的在于为公司实施与需求相关的方针提供指南。
该过程对所有公司负责需求采集的项目适用,也适用于那些客户在自行采集需求时需要帮助的项目。
3术语简称与解释
4
总经理:
简称GM,指公司总经理,具备法人代表资格。
副总:
简称VGM,公司的一种职务,指公司副总。
项目经理:
简称PM,公司的一种职务,一般由具备项目管理经验和行业经验人员承担,负责项目的管理活动。
项目负责人:
简称PL,项目组组长,临时性职务,负责项目的开发活动,如无变更,
生存周期与项目生存周期相同。
需求分析人员:
简称RA,通常由项目组中成员承担此角色,可以是项目负责人也可以项目组中其他人员。
软件设计人员:
简称SD。
在公司一般指系统分析员和程序员(包括高级程序员);
在项目中指项目组中的设计人员。
软件质量保证:
SQA,一种软件质量保证活动,在公司通常也用SQA代表质量保证活动者,目前由公司品管部执行此活动。
配置管理员:
简称CC,在公司中负责所有项目的配置管理活动。
5进入准则
6
进入准则如下:
来自客户的关于需求的文档经过公司审批;
来自客户的标识有意进行某个项目的信函,并且经过公司审批;
总经理对内部项目的授权,有相关文件(文档)表明是经过审批的;
公司与客户签订的合同。
附注:
满足其中任何一种条件均可。
7退出准则
8
退出准则如下:
SRS的文档已准备好,经过评审和批准。
9阶段交付产品
10
本阶段交付有:
经过评审并得到批准的SRS文档;
SRS评审报告;
变更请求;
变更请求单日志;
影响分析报告。
11使用者
12
本文件的使用者如下:
VGM、RA、SD、PM、PL、QA。
13过程流图
14
14.1过程
14.2
14.2.1需求收集与获取
14.2.2
14.2.3
14.2.4
14.2.5需求评审
14.2.6
14.2.7
14.2.8
14.2.9需求变更管理过程
14.2.10
14.2.11
14.2.12
14.3过程描述
14.4
需求管理过程被分为3部分,包括:
需求获取和采集过程、需求评审过程、需求变更管理过程。
14.4.1需求收集与获取规程
14.4.2
需求可能来自以下任何一种渠道
客户的需求文档
工作范围描述文档
电子邮件
合同
随后,进行需求文档格式的评审:
当需求不是以公司格式提交时,项目经理/项目负责人可选择如下处理办法:
将需求转换成金恒宇公司的格式,或采用用户的需求文档格式。
当客户特别要求用他们自己的格式时,应满足他们的要求。
就以下方面对评审需求
正确性。
正确性取决于技术人员
完整性。
完整性取决于技术人员以及SQA人员
可行性。
可行性研究由PM/PL在评审时进行,在进行估计时进一步完善对可行性的研究
一旦在需求文件中发现缺陷/问题,将编制评审报告,并从客户那里征求进一步的阐述或建议或更多输入
如果评审报告表明需求清晰、完整而且正确无误,需求文档得到基线化;
需求文档命名应遵守命名规则,并检入配置管理(CM)工具/库;
SRS的评审报告也要置于配置管理之下
14.4.3需求评审规程
14.4.4
在SRS被用于开展进一步的策划和开发活动之前,SRS必须经过评审
制定评审计划,选定SRS评审人员,主要有:
VGM、PM、PL、RA、SD、关键技术人员。
评审进度安排要通知给评审小组成员,交流的方式可以是E-MAIL亦可是书面通知
分发SRS文档以及其他客户提供的资料和参考资料,评审小组成员就SRS进行个人评审,如果发现任何缺陷,将他们列入个人的缺陷清单
评审者参加评审会议,分配评审组角色
读者朗读SRS文档
当任何评审组员发现潜在的缺陷时,读者停止朗读,小组讨论它是否是SRS的一个缺陷,若确实存在缺陷,由记录员负责记录下来
以上过程反复进行直到所有的缺陷均被讨论并达成一致意见
记录员做出最终缺陷列表,评审小组负责人将其通知客户
需求分析人员就评审中发现的缺陷征求客户的意见
评审小组就缺陷严重程度决定是否进行再评审
一旦再评审是必须的,评审报告应反映这个情况并采用本规程安排及执行再评审
如果在SRS文件中找不到重要缺陷,亦认为再评审无必要,则可批准该SRS文档,并基线化
基线化的SRS版本应检入配置管理(CM)工具/库
14.4.5需求变更管理规程
14.4.6
当需求发生变更,公司要提出变更请求、这个工作可以由公司或客户来做
变更请求必须有一个唯一的编号
对变更进行影响分析,以评估变更的规模。
一旦发现变更影响巨大,以至波及到项目工作量、进度,成本,变更将转送到公司高层经理和市场/财务部门决策是否变更合同
当变更被认可(小变更由公司控制,大变更要经过客户许可)变更申请转变成变更令,并付诸实施
更新SRS文件。
如果有要求,更新其他文件
为这些变更的进行提供资源(人,软件、硬件),如有必要时。
将更新过的文档置于CM的管理之下(CM工具/库)
将SRS及其他文件的变更通知所有相关人员
按照项目跟踪过程与活动,对变更的执行进行跟踪
一旦变更实施,且实施通过验收,变更请求单上将标注为闭合
为便于在以后参阅,关于该变更的所有信息将保存在过程数据库中
14.5验证机制
14.6
验证机制如下:
配置审计
对执行期超过六个月的项目应当在每个月、每个版本发布前、任何外部审计前进行。
对执行期少于六个月的项目应当在每15天、每个版本发布前、任何外部审计前进行。
由SQA/独立小组进行的内部审计
对执行周期超过六个月的项目每个月组织内部审计。
对执行周期少于六个月的项目每15天组织内部审计。
外部审计
ISO监督审计—由外审人员安排日程。
CMM相关评估——由评估人员安排日程。
给管理高层的关于需求管理相关活动的定期报告
对执行期少于六个月的项目应当每周进行报告
对执行期超过六个月的项目应当每15天进行报告
14.7度量
14.8
对需求相关活动的评估指标如下:
编号
评估指标
频率
责任
来源
1
需求数量
每15天
PM/PL
SRS
2
需求变更数量
每周
变更日志
3
已认可的变更数量
变更申请日志
4
正在执行的变更数量
项目状态报告
5
需求相关活动中耗费的工作量
所有参与需求相关活动人员
时间表
6
预期在需求管理中耗费的工作量
项目计划
7
实际在需求管理中耗费的工作量
所有参与需求活动人员
15活动职责矩阵
编号.
活动
VGM
PM
PL
RA
SQA/SEPG
获得需求
-
S
P
评审需求
准备SRS
评审SRS
认可SRS
认可变化
影响分析
8
管理SRS
9
升级PDB
P:
主要职责
S:
次要职责
16参考资料
17
SEI-CMMversion1.1
18附件
19
TM_SDLC_SRSSRS模板
FM_SDLC_REVW缺陷评审/测试表
CL_SDLC_REQE需求获取检查单
CL_SDLC_RQRWSRS评审检查单
SRS评审报告
变更请求表
变更请求记录表
影响分析表
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 管理 过程
![提示](https://static.bdocx.com/images/bang_tan.gif)