软件开发过程之需求开发和管理过程Word格式.docx
- 文档编号:4703267
- 上传时间:2023-05-03
- 格式:DOCX
- 页数:16
- 大小:20.96KB
软件开发过程之需求开发和管理过程Word格式.docx
《软件开发过程之需求开发和管理过程Word格式.docx》由会员分享,可在线阅读,更多相关《软件开发过程之需求开发和管理过程Word格式.docx(16页珍藏版)》请在冰点文库上搜索。
1概述5
1.1编写目的5
1.2适用范围5
1.3术语和缩写5
1.4参考资料5
2输入5
3输出6
4角色和职责6
5过程定义6
5.1入口条件6
5.2出口条件6
5.3过程流程图7
5.4过程活动描述7
5.4.1调研准备7
5.4.2需求调研7
5.4.3撰写用户需求说明书8
5.4.4同行评审(用户需求说明书)9
5.4.5需求承诺9
5.4.6需求分析10
5.4.7同行评审(需求规格说明书)11
5.4.8需求确认11
5.4.9需求跟踪12
5.4.10需求变更管理13
6过程度量14
7裁剪准则15
1概述
1.1编写目的
定义和建立公司对项目需求开发和管理活动的规范和责任。
定义及规范软件开发工作中从需求阶段的需求收集,需求分析,需求文档化,到开发阶段的需求控制,需求跟踪,以及需求变更管理的工作过程。
通过该规范来提高公司的需求开发和管理能力。
1.2适用范围
本过程适用于公司内所有软件开发项目的需求开发和管理活动。
1.3术语和缩写
术语和缩写
解释
备注
RD
RequirementsDevelopment
需求开发
RM
RequirementsManagement
需求管理
SCCB
SoftwareChangeControlBoard
软件变更控制委员会
需求文档
在需求开发阶段产生的需求工作产品,包括:
《需求调研报告》、《需求说明书》、《需求规格说明书》等
1.4参考资料
参考文件
《CMMIV1.1》
2输入
输入制品
《工作说明书》
3输出
输出制品
《需求调研报告》
《用户需求说明书》
《需求规格说明书》
《需求管理矩阵》
4角色和职责
角色
职责
项目经理
●组织对需求开发活动
●保证项目中需求管理工作的实施
●评审《需求变更表》
●确认需求变更情况
需求分析师
●进行需求调研准备,开展调研,搜集需求资料,整理调研内容,形成《需求调研报告》
●进行需求分析,形成需求文档
●提请对需求文档进行同行评审
●创建《需求管理矩阵》
●维护《需求管理矩阵》
同行评审者
●参与需求文档的评审
●对需求变更申请进行评审
客户代表
●配合进行需求调研,提供调研相关资料
●对需求文档进行确认
●参与需求变更评审,并确认和签字认可。
5过程定义
5.1入口条件
项目立项,需求阶段开始。
5.2出口条件
需求文档经过评审和客户代表确认后可进入设计过程;
需求的变更和跟踪管理一直持续到项目结项。
5.3过程流程图
参见《需求开发和管理流程》
5.4过程活动描述
5.4.1调研准备
活动名称
调研准备
责任角色
项目小组
活动接口
进入条件
(或活动启动的事件)
1、项目或产品已经立项
2、有明确的工作任务书
活动的输入
《工作任务书》(SOW)
活动的输出
准备调研内容和问题的《需求调研报告》
系统原型(可选)
退出条件
(或触发其他活动的事件)
调研准备相关资料(比如行业资料,系统原型)已经准备完成
任务
1、搜集相关资料尽可能了解客户情况或客户所在行业的特点
2、准备要调研的内容和问题,填写《需求调研报告》
3、为帮助用户直观的理解,根据用户或需求分析师的意见项目组可考虑建立一个系统原型,或者简单一点,建立一个界面原型。
这个原型有助于在调研过程中更准确的捕获用户的需求。
使用工具
MicrosoftWord2000以上版本
相关过程
了解客户情况时可以参考项目的合同,与相关的销售人员、售前支持人员进行交流,以便对项目有一个基本轮廓的认识,并尽可能充分了解客户的情况
5.4.2需求调研
需求调研
需求分析师、客户代表
1、需求调研准备活动完成
准备好调研内容和问题的《需求调研报告》
系统原型
已完成和确认《需求调研报告》
搜集的各种样表、资料
需求调研活动完成
1、就《需求调研报告》上的调研内容和问题跟用户进行沟通,同时可能引申出其它相关内容,需求分析师要做好记录。
2、收集相关样表、资料。
3、在调研过程中要关注用户的真正目的是什么。
为了达到目的可以采用多种方法,有时用户仅仅知道其中一种方法,这时需求分析师不能简单的照单全收,要勇于提出新的建议。
有时用户甚至不知道方法,这时需求分析师要提出解决方案,去满足用户的真正目的。
4、需求分析师在调研过程中可以借助系统原型或界面原型和用户更直观的沟通,有利于捕获用户的真实想法。
5、需求分析师要对沟通过的内容进行整理,要注意区分哪些内容是需求,哪些内容是用户提出来的对需求的解决方案。
在解决方案中要区分哪些是用户强制性的,这些将是设计的约束;
哪些是用户建议性质的,这些将是设计的参考。
6、需求分析师将整理的内容生成《需求调研报告》并和调研对象负责人确认。
MicrosoftWord2000以上版本
需求调研可以采用各种各样的方式进行,目的是尽可能全面、深入了解客户的真正需求
5.4.3撰写用户需求说明书
撰写用户需求说明书
需求调研完成
调研搜集的各种样表、资料
《用户需求说明书》完成
1、对需求调研阶段的资料,进行必要的整理、分类。
这些分类包括业务流程和系统功能的分类;
系统功能性需求和非功能性需求的分类;
系统功能性需求中子系统(模块)的分类。
2、分析必须功能、可选功能、暂可不实现功能。
3、对用户需求进行编号。
4、根据整理、分析,形成《用户需求说明书》。
需求调研、同行评审(需求规格说明书)
《用户需求说明书》要求用户和需求分析人员都能看懂、看明白,要避免使用专业技术的描述,尽量试用易懂、准确的描述
《用户需求说明书》要避免以“如何实现”的方式表述,要转换为“实现什么”的方式,因为关注的目标是“做什么”,而不是“怎么做”
5.4.4同行评审(用户需求说明书)
同行评审(用户需求说明书)
需求分析师、同行评审者、客户代表
需求分析完成
《同行评审报告》
《用户需求说明书》评审通过
1、按同行评审过程对《用户需求说明书》进行评审。
2、需要强调的是测试负责人应该参加《用户需求说明书》的同行评审,它的作用在于验证用户需求是否是可测试的。
无
同行评审
5.4.5需求承诺
需求承诺
需求分析师、项目经理、客户代表
《用户需求说明书》用户确认并做出承诺
1、项目经理,需求分析师确保项目组核心成员(包括技术负责人,测试负责人)对《用户需求说明书》有一致的意见。
必要时要组织项目组内的评审会。
需要特别指出的是测试负责人必须对《用户需求说明书》做认真审查,以确保这是可测试的需求。
2、项目经理,需求分析师向客户讲解《用户需求说明书》,可以采用的形式包括非正式的会谈,正式会议,培训,演示原型等。
3、如用户对《用户需求说明书》还存在疑问或意见,项目经理和需求分析师要对《用户需求说明书》做出解释或修改,直到用户认可为止。
4、用户对《用户需求说明书》做出承诺,承诺的方式以签字确认为准。
5.4.6需求分析
需求分析
《用户需求说明书》制定完毕
《需求规格说明书》完成
1、以《用户需求说明书》的内容为依据进行需求分析。
在分析过程中,需求分析师由于对技术和领域更熟悉的原因,会衍生出更多的规格需求,但这些需求不应该与用户需求冲突,且应该有利于实现用户需求的目的。
2、需求分析采取自上而下逐步分解,先分析需求点之间关系,再细化内容的方式。
3、首先区分功能、非功能的需求。
4、对功能需求自上而下分解,系统分解到子系统,子系统分解到用例包,用例包分解到用例。
在分解的同时要描述子系统和子系统的接口关系,用例包和用例包的接口关系,用例和用例的接口关系。
5、用例的分析将从需求类别,复杂度,优先级,用例描述,主事件流,异常流,输入,输出,前置条件,后置条件,相关接口,业务规则多个方面进行描述。
6、用例的内容按照《需求规格说明书》提供的用例模板编写。
用例要进行编号以便引用。
RationalRose2002以上版本或MicrosoftWord2000以上版本
5.4.7同行评审(需求规格说明书)
同行评审(需求规格说明书)
《需求规格说明书》评审通过
1、按同行评审过程对《需求规格说明书》进行评审。
2、需要强调的是测试负责人应该参加《需求规格说明书》的同行评审,它的作用在于验证需求规格是否是可测试的。
5.4.8需求确认
需求确认
《需求规格说明书》用户确认通过
1、项目经理,需求分析师确保项目组核心成员(包括技术负责人,测试负责人)对《需求规格说明书》有一致的意见。
需要特别指出的是测试负责人必须对《需求规格说明书》做认真审查,以确保这是可测试的需求。
2、项目经理,需求分析师向客户讲解《需求规格说明书》,可以采用的形式包括非正式的会谈,正式会议,培训,演示原型等。
3、如用户对《需求规格说明书》还存在疑问或意见,项目经理和需求分析师要对《需求规格说明书》做出解释或修改,直到用户认可为止。
4、用户对《需求规格说明书》进行确认。
确认的形式可以以签字,会议纪要,或反馈表形式体现。
5.4.9需求跟踪
需求跟踪
需求分析师、项目经理
《用户需求说明书》客户签字确认
设计制品
代码制品
测试用例
项目结项
1、在项目的各个开发阶段中,使用《需求管理矩阵》对用户需求和项目过程中制品进行双向的跟踪管理,以确保用户需求在整个项目生命周期中的一致性和可追溯性。
2、项目经理或项目经理指派专人负责建立和更新《需求管理矩阵》,确保随项目的进展,项目过程中的工作制品能体现到《需求管理矩阵》。
3、《需求管理矩阵》作为配置单元纳入SCM控制,并需要及时的维护和管理,《需求管理矩阵》负责人定期填写有关跟踪数据,确保每项需求的落实实施。
4、在整个软件产品生命周期中,需求的状态可以划分为以下几类:
1.已定义-需求已经明确定义,并记入《需求规格说明书》;
2.已确认-已经由客户确认,并签字认可;
3.已提交-已经纳入软件开发计划;
4.已设计-已经完成对应的设计工作,得到设计文档;
5.已履行-已经完成对应的编程工作,得到源代码;
6.已完成-已经通过系统测试,等待交货。
配置管理
5.4.10需求变更管理
需求变更管理
《需求变更单》
需求变更经SCCB评审通过,并且评审结论得以实施并验证通过。
1.需求变更管理是在项目过程中,在需求基线建立后,当需求发生更改时,对需求变更进行控制和管理的过程。
评估过程应包括由需求变更而引起的对软件开发综合计划、软件工作产品和软件开发活动的影响,具体包括相关变更的识别、评估,以及对风险的分析、与受变更影响的组和个人进行沟通等,并对需求变更活动进行记录、跟踪至完成。
需求变更引起的对外部承诺的变更须通知高层经理和客户,内部的承诺变更须通知到相关组/个人。
详见《配置管理过程》中的配置变更管理。
2.主要操作:
●需求变更评审:
变更申请人填写《需求变更单》,项目组SCCB对需求变更进行评审。
●文档更新:
如果需求变更评审同意需求变更,需求分析师将变更的情况反映到新版的《用户需求说明书》和《需求规格说明书》中。
●提交配置管理:
参考《配置管理过程》的产品提交管理,并对相关配置项进行修改
●相关更改:
考虑需求变更对工作产品、活动、项目计划的影响,考虑内容如下
●依据《需求管理矩阵》分析对工作产品的影响,将变更的情况反映到《需求管理矩阵》
●依据《需求管理矩阵》对《体系结构设计说明书》、《数据库设计说明书》、《用户界面设计说明书》、《模块设计说明书》、代码和测试文档等进行相应修改,以反映需求变更。
●在合适时对《项目综合开发计划》进行修改以反映需求变更的影响。
●在合适时与受到影响的组重新协商双方的约定。
6过程度量
1.需求规模(FunctionPoint数)
2.需求开发的工作量(人天)
3.需求变更次数
4.需求管理的工作量(人天)
5.需求制品的缺陷数
7裁剪准则
参见《过程剪裁报告》剪裁指南。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 过程 需求 管理
![提示](https://static.bingdoc.com/images/bang_tan.gif)