传统软件需求开发规程规范.docx
《传统软件需求开发规程规范.docx》由会员分享，可在线阅读，更多相关《传统软件需求开发规程规范.docx（13页珍藏版）》请在冰点文库上搜索。
传统软件需求开发规程规范
需求开发规程
文件状态：
[V]草稿
[]
[]
正式发布
正在修改
文件标识：
PNS-RD-PROC-01
当前版本：
1.0
作者：
完成日期：
普华讯光（北京）科技有限公司
版本历史
版本/状态
作者
参与者
完成日期
说明
审批人员
姓名
职务
时间
1
目的
2
范围
3
术语定义
4
职责
5
裁剪指南
6
过程
6.1
概要图
6.2
启动条件
6.3
输入
6.4
活动
6.4.1
需求调研
错误!
未定义书签。
6.4.2
分析需求
错误!
未定义书签。
6.4.3
需求确认
错误！
未定义书签。
6.4.4
细化需求
错误!
未定义书签。
6.4.5
需求确认
错误!
未定义书签。
6.5
输出
6.6
关闭标准
7
审核
8
度量
9
技能要求
10
参照文件
1
1
1
1
2
2
2
4
4
4
6
6
6
6
7
7
1目的
需求开发过程帮助项目组有序地分析和产生客户需求、产品及产品构件需求，并取得用户的最终确认。
2范围
适用于公司所有项目、产品或产品升级的需求获取。
3术语定义
评审小组：
一般由高级需求分析师、项目经理、系统架构师、部门经理、业务专家及公司高层组成。
4职责
角色
活动、
评审小组
项目经理
需求分析人员
项目组
客户销售代表
准备
参与需求开发及管理计划评审
执行需求开发及管理计划
参与需求开发计划评审
参与需要开发及管理计划评审
需求调研
执行需求调研
配合需求调研，提供原始需求
建立用户需求说明书
建立用户需求说明书
需求分析
执行需求分析
建立需求规格说明书
建立需求规格说明书
界面原型初步设计
界面原型初稿
需求评审
参加评审
组织评审
参加评审
参加评审
可能时，参加评审
需求确认
组织需求确认
组织需求确认
客户进行确认
E-R建模
建立概念模型
概念模型评审
参加评审
组织评审
参加评审
参加评审
可能时，参加评审
需求完善
根据评审意见完善需求规格说明收、界面原型、概念模型
5裁剪指南
实施类项目可裁剪需求开发过程。
可裁剪的活动有需求调研和产品需求开发。
对于需求明确不需要调研活动的项目可不作需求调研，对于在原有平台基础上配置复用的项目如原平台需求规格明确，可不作产需求开发。
对应以上活动的裁剪可裁减的输出包括：
《需求调研计划》、《需求调研记录》、《需求规格说明书》、《E-R模型》、《需求确认单》。
6过程
6.1概要图
需求开发工作流程
输入
管理规范、业
务流程、表单
等业务材料
用户需求说明
书
析
与研调求需户用
技术协议或售
前方案
用户
页目经理
需求分析师
评审组
用户需求说明
书
界面原型初设
稿
E-R模型
设初型原与析分格规求需件软
需求调研
「需求确认
用户确认:
P面原型初设稿
开始
质量控制组
输出
f计划
需求调研准备
需求调研记录
内部评审用户需求
功能细分
编写需求用例
I
定义操作流程
定义非功能性需求
界面原型初步设计
内部评审需求规格说明书和界面原型初
用户确认单
业务数据分析
E-R建模
E-R模型
内咅
评审E-R摸型
分析调研获取的用户需求
编制用户需求说明书
E-R模型评审记录
界面原型初设
稿
■需求规格说明书和原型初设
稿评审记录
用户需求确认
单
用户需求评审
记录
需求规格说明
书
用尸需求说明
1
细化完善界面原型
（面向开发人员）
用颜色区分哪些是内部输出，哪些是部门承接L
哪些是质量管控
重点
界面原型交付
开发稿
6.2
启动条件
需求分析员已经确定（由需求设计中心和项目组共同组成）。
项目合同中的技术协议、客户提供的原始需求资料、项目计划。
6.4.1需求开发准备
项目经理根据项目合同中的技术协议或客户提供的原始需求资料确定需求开发范围和确定需求小组成员，制订需求开发的详细计划。
需求分析师根据客户提供的原始需求资料制定《需求调研计划》，对需求调研过程中要调研的问题形成《需求调研大纲》。
需求调研的对象可能会是：
客户、售前人员、售后服务人员、产品实施人员、竞争对手产品等。
项目经理对调研计划进行内部审核。
6.4.2用户需求开发
项目经理与用户管理层确定客户方需求提供人（高层领导、管理干部或具体用户），并协调客户方需求提供人开展工作。
需求小组根据需求调研计划以及需求调研大纲，在《需求调研记录》中填写调查的信息。
需求小组根据《需求调研记录》编写《用户需求说明书》。
注意事项：
需求分析师可以总结公司以前相同类型的软件，根据以前的经验补充完善需求说明书，经过项目组讨论后，再请客户提出意见和看法，以制定出合理完善的需求说明书;
6.4.3用户需求确认
项目经理组织组内审核。
组内审核通过后由质量人员组织进行评审。
评审通过后，由客户进行确认，确认一般采用会议阅读或发送需求说明书给客户的方式进行，客户确认通过，需要填写《需求确认单》。
644产品需求开发
在开发产品需求时，应注意前期需求的分析。
界定功能需求和非功能需求,
需求小组根据《用户需求说明书》为客户需求建立产品构件。
并规格化描述非功能需求、模块化描述功能需求。
需求小组对通过技术转化的需求建立相应的需求与产品构件的对应关系表，比如要实现客户要求的“100万条记录/秒”的查询速度，那么就需要前台查询模块和后台处理程序各承担一定的处理能力。
需求小组对接口需求进行分析，分别确定产品内部的产品构件之间、产品与外部产品之间的接口需求。
需求小组编写《产品需求规格说明书》。
注意事项：
把客户需求理解为产品需求时应剖析客户需求本质；抽取共性需求，根据客户业务需求,区分主次，归纳，分析，总结并提炼。
主要通过以下两个步骤进行需求分析:
1.进行业务建模，从静态和动态两个角度对目标客户群体的业务特征进行描述并抽取其中
的共性和变量、内涵和外延。
静态特征包括：
业务目标、业务组织结构、业务角色、业务成果等。
动态特征主要指：
业务流程。
进行业务组件抽取，根据业务模型从业务实现的角度对产品模块进行分层次抽取和划分。
2.功能规划，根据之前任务中得到的业务需求信息对产品的功能及性能进行规划，划分出
每次迭代版本将要实现的功能及功能优先级，以及对产品性能的要求。
当前迭代的功能点必须是明确的，相对而言，后续迭代的功能可以不那么明确，在每次迭代开始前进行重新整理和明确。
功能组件抽取，从业务无关的功能角度对产品功能进行分层次抽取和划分，提取可复用的功能组件。
需求规格说明书是软件设计的依据，是工程的起点，应是用户需求的真实反应。
编写需求
规格说明书应遵循以下规则:
标准。
实现的优先权。
5.可证实性。
是否能通过测试或者其它验证方式来决定产品中的每个需求都能正确的实现。
6.4.5需求分析及评审
需求小组分析用户需求说明书，获得需求的优先级，以及需求模块之间的关系，以及所开发软件产品在客户方预期运行的环境等场景。
需求小组按模块编写需求功能，包含需求编号、优先级、处理功能、接口等。
需求小组分析需求的可执行度、项目经理分析实现需求的成本、进度、风险，最后由需求小组编写《需求可行性分析》，对于暂缓实施的功能或不实施的功能，需要与客户或用户进行协商，形成会议纪要。
项目经理组织相关人员（客户等）对《需求规格说明书》进行评审确认。
《需求调研计划.doc》（包含《需求调研大纲》）《需求调研记录.doc》《用户需求说明书.doc》《产品需求规格说明书.doc》《需求可行性分析.xIs》《需求确认单.doc》
《需求评审报告》
已经对产品需求进行了评审，并且获得了开发方和客户方对需求的承诺。
审核
评审小组需对输出进行审核。
度量
项目经理统计工作量和上述文档的规模。
9技能要求
项目经理有项目管理技能、组织协调能力。
需求分析师有需求分析能力。
10参照文件
无。
升级会员 