需求工程规范.docx
- 文档编号:6192038
- 上传时间:2023-01-04
- 格式:DOCX
- 页数:10
- 大小:79.19KB
需求工程规范.docx
《需求工程规范.docx》由会员分享,可在线阅读,更多相关《需求工程规范.docx(10页珍藏版)》请在冰豆网上搜索。
需求工程规范
需求工程规范
[0.1版]
目录
1.概要1
1.1.目的1
1.2.范围1
1.3.术语与缩略语1
1.4.角色与职责1
2.过程描述2
2.1.过程介绍2
2.2.立项2
2.2.1.准入条件2
2.2.2.输入2
2.2.3.具体步骤3
2.2.4.输出4
2.2.5.准出条件4
2.2.6.裁剪4
2.3.需求分析4
2.3.1.准入条件4
2.3.2.输入4
2.3.3.具体步骤5
2.3.4.输出6
2.3.5.准出条件6
2.3.6.裁剪6
2.4.需求跟踪与管理6
2.4.1.准入条件6
2.4.2.输入6
2.4.3.具体步骤6
2.4.4.输出7
2.4.5.准出条件7
2.4.6.裁剪7
3.实施建议7
4.其它7
4.1.需求调研的六边形法则7
1.概要
1.1.目的
本文档用以规范本公司的需求工程活动。
1.2.范围
本文档适用本公司的所有项目的需求活动。
1.3.术语与缩略语
术语/缩略语
解释
客户需求
客户按照自己的理解提出的需求。
产品需求
根据客户需求进行分析得到的需求,面向技术人员使用。
质量属性
满足质量要求的一系列要求。
1.4.角色与职责
角色
职责
2.过程描述
2.1.过程介绍
2.2.立项
2.2.1.准入条件
无。
2.2.2.输入
客户初始意向。
2.2.3.具体步骤
2.2.3.1.获取客户需求
根据客户初始意向需求,按照以下流程处理:
需求详尽的标准:
可以使用目前的需求进行估算。
研发部经理确定PM人选,由PM负责需求调研工作,PM成立需求调研小组,确定组长和组员。
(一)需求详尽
1)预习—提问
由于客户提供的需求比较详尽,PM组织研发部内的技术骨干等相关人员预习需求,并对不理解的需求点提出疑问。
2)交流
对于不理解的需求点,PM通过业务部与客户方接口人直接交流,解决疑问。
3)达成一致
最终双方对于需求的理解达成一致,并进行书面确认。
(二)需求不详尽
1)计划:
PM编制调研计划,准备需求调研报告模板、调查表,计划、模板、调查表需要经过研发部、业务部和测试部评审。
2)调研
PM安排需求调研小组与客户方接口人建立联系,使用访谈、参观、调查表等不同方式综合运用对客户进行调研。
需求调研小组获取相关的资料和数据后,组长按照模板编制《需求调研报告》。
3)内部评审
PM组织评审会议评审《需求调研报告》,参加人员:
需求调研小组、研发部经理、业务部经理、测试人员、QA。
4)达成一致
PM将评审通过后的《需求调研报告》发给客户,并与客户书面上达成一致。
2.2.3.2.估算
参考《项目估算指南》。
本活动工作产品为《估算表》。
2.2.3.3.可行性分析报告
研发部根据估算表进行可行性分析,出具一份《可行性分析报告》提交给业务部。
2.2.3.4.项目建立
业务部参考《可行性分析报告》安排后续商务活动,并通知研发部是否立项。
2.2.3.5.项目组成立
业务部确定要立项,需要通知研发部。
业务部在与客户签订合同前要将影响项目的相关事项告知研发部。
研发部经理安排PM成立项目组。
PM配置项目所需资源,编写《项目计划日程表》。
2.2.4.输出
《客户需求调研报告》
《需求调查表》
《估算表》
《可行性分析报告》
《项目计划日程表》
2.2.5.准出条件
业务部与客户签订商务合同。
2.2.6.裁剪
编号
活动标题
裁剪结果
裁剪条件
备注
2.3.需求分析
2.3.1.准入条件
项目已经立项。
2.3.2.输入
客户需求调研报告
客户提供资料
客户提供数据
《决策分析指南》
2.3.3.具体步骤
2.3.3.1.计划
PM开始编写《项目计划书》,分析各阶段详细日程及资源安排,初期完成(3天内)。
同时PM确定各个角色人员(如CM),分配人员任务安排。
如果原先的需求调研小组没有人员变动,则转变为需求分析小组;如有人员变动,PM需要重新确定组长和组员。
2.3.3.2.整理现有业务流程
需求分析小组首先整理客户现有的业务流程,必要时使用活动图进行描述。
2.3.3.3.设计新系统
需求分析小组根据需求调研结果设计新系统功能定义与业务流程,使用用例图描述。
需求分析小组组长负责编制《需求规格书》初稿,主要内容为现有业务流程和新系统业务流程。
2.3.3.4.评审
PM组织评审会议评审《需求规格书》初稿,参加人员:
需求分析小组、开发人员、测试人员、客户、研发部经理、QA。
2.3.3.5.设计整体架构
评审通过后,PM组织几个技术专家负责设计整体架构,每个技术专家独立设计一套方案。
主要包括系统部署、子系统划分、基础平台、关键技术、开发语言、DB选型等内容。
多个方案完成后,PM组织决策会议,研发部经理、测试部经理、业务部经理及技术骨干等参加决策会议,评价多个方案,最终确定一个方案为采纳方案,同时保留一个方案为备用方案。
设计采纳方案的技术专家由研发部任命为该项目技术经理,负责后续技术架构、设计等工作。
PM负责编写《决策分析计划、报告》,使用《决策评价表》对待决策事项进行评价,具体流程参加《决策分析指南》。
2.3.3.6.设计性能
需求分析小组和技术经理考虑系统的质量属性,设计系统的性能。
2.3.3.7.设计接口
需求分析小组和技术经理设计接口。
2.3.3.8.考虑约束
需求分析小组和技术经理在设计时需要考虑约束。
2.3.3.9.开发界面原型
美工协助需求分析小组设计开发界面原型,并与客户确认。
2.3.3.10.确定复用/采购组件
PM和技术经理确定是否复用代码、采购组件或使用开源软件,在必要时举行决策会议决策采购组件或使用开源组件。
如需决策会议,PM负责编写《决策分析计划、报告》,使用《决策评价表》对待决策事项进行评价,具体流程参加《决策分析指南》。
2.3.3.11.编制规格书
技术经理根据模板编制《需求规格书》,必要时增加《活动图》附件。
2.3.3.12.评审
PM组织评审会议评审《需求规格书》,参加人员:
需求分析小组、技术经理、研发部经理、业务部经理、测试部经理、技术骨干、QA(、总经理)。
2.3.3.13.客户书面确认
PM将评审后的《需求规格书》发送给业务部经理,业务部经理根据商务合同安排,将《需求规格书》发送给客户,并书面上达成一致。
2.3.3.14.二次估算
参考《项目估算指南》。
本活动工作产品为《估算表》。
重新进行估算,以便于PM制定《项目计划书》。
2.3.3.15.项目计划编制
PM在《需求规格书》评审通过后要完成《项目计划书》。
PM组织里程碑会议,同时评审《项目计划书》,参加人员:
项目组全体、研发部经理、测试部经理、业务部经理、QA(、总经理)。
PM提交《里程碑报告》发送与会全体,抄送总经理。
2.3.3.16.形成需求基线
项目CM参考《配置管理规范》,建立需求基线。
2.3.4.输出
《需求规格书》
《估算表》
《项目计划书》
《活动图》
《里程碑报告》
《决策分析计划、报告》
《决策评价表》
2.3.5.准出条件
已经形成需求基线。
2.3.6.裁剪
编号
活动标题
裁剪结果
裁剪条件
备注
2.3.3.2
整理现有业务流程
不做
客户对自身现有业务流程不清晰,或无法获取现有业务流程。
2.3.3.10
确定复用/采购组件
不做
本次项目属于新业务领域拓展或对于新组件不熟悉。
2.4.需求跟踪与管理
2.4.1.准入条件
需求基线已经形成。
2.4.2.输入
需求基线文档。
2.4.3.具体步骤
2.4.3.1.建立需求跟踪矩阵
PM需要指定一人负责需求跟踪和管理(以下简称RTM人员)。
需求基线形成后,RTM人员开始建立《跟踪矩阵》之需求跟踪矩阵表。
整个生命周期中,建立跟踪矩阵的时机,产品需求依赖客户需求,系统测试用例依赖产品需求,概要设计依赖产品需求,详细设计依赖概要设计。
2.4.3.2.维护需求跟踪矩阵
当需求需要变更时,PM要先做变更影响分析,分析本次变更的影响范围。
然后使用决策方法决定是否进行变更。
如需决策会议,PM负责编写《决策分析计划、报告》,使用《决策评价表》对待决策事项进行评价,具体流程参加《决策分析指南》。
进行变更后,PM要安排人员对受到影响的文档进行修改,并经过评审后重新入基线。
RTM人员根据修改情况,修改《跟踪矩阵》之需求跟踪矩阵表。
2.4.4.输出
《跟踪矩阵》之需求跟踪矩阵表
《决策分析计划、报告》
《决策评价表》
2.4.5.准出条件
整个项目运行中持续跟踪。
2.4.6.裁剪
编号
活动标题
裁剪结果
裁剪条件
备注
3.实施建议
建议需求跟踪矩阵在形成需求基线后再进行制作,因为工作量较大,需求不稳定时调整较多。
4.其它
4.1.需求调研的六边形法则
组织结构:
企业为进行相应的业务流程所做的人员的组织安排。
业务流程:
企业开展业务所必须的各个环节及在每个环节中的具体做法。
业务数据:
企业内部经营信息的存储和流动形式。
业务地点分布:
反映企业在什么地方开展业务以及业务流程中的各个环节之间的地点关系。
业务应用:
企业以什么样的应用软件处理业务流程中的各个环节。
技术基础设施:
企业在信息技术基础设施上的状况。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 工程 规范