传统软件需求开发规程规范_第1页
传统软件需求开发规程规范_第2页
传统软件需求开发规程规范_第3页
传统软件需求开发规程规范_第4页
传统软件需求开发规程规范_第5页
已阅读5页,还剩5页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

PNS-RD-PROC-01需求开发规程文件状态:[√]草稿[]正式发布[]正在修改文件标识:PNS-RD-PROC-01当前版本:1.0作者:完成日期:普华讯光(北京)科技有限公司

版本历史版本/状态作者参与者完成日期说明审批人员姓名职务时间目的需求开发过程帮助项目组有序地分析和产生客户需求、产品及产品构件需求,并取得用户的最终确认。范围适用于公司所有项目、产品或产品升级的需求获取。术语定义评审小组:一般由高级需求分析师、项目经理、系统架构师、部门经理、业务专家及公司高层组成。职责角色活动评审小组项目经理需求分析人员项目组客户销售代表准备参与需求开发及管理计划评审执行需求开发及管理计划参与需求开发计划评审参与需要开发及管理计划评审需求调研执行需求调研配合需求调研,提供原始需求建立用户需求说明书建立用户需求说明书需求分析执行需求分析建立需求规格说明书建立需求规格说明书界面原型初步设计界面原型初稿需求评审参加评审组织评审参加评审参加评审可能时,参加评审需求确认组织需求确认组织需求确认客户进行确认E-R建模建立概念模型概念模型评审参加评审组织评审参加评审参加评审可能时,参加评审需求完善根据评审意见完善需求规格说明收、界面原型、概念模型裁剪指南实施类项目可裁剪需求开发过程。可裁剪的活动有需求调研和产品需求开发。对于需求明确不需要调研活动的项目可不作需求调研,对于在原有平台基础上配置复用的项目如原平台需求规格明确,可不作产需求开发。对应以上活动的裁剪可裁减的输出包括:《需求调研计划》、《需求调研记录》、《需求规格说明书》、《E-R模型》、《需求确认单》。过程概要图启动条件需求分析员已经确定(由需求设计中心和项目组共同组成)。输入项目合同中的技术协议、客户提供的原始需求资料、项目计划。活动需求开发准备项目经理根据项目合同中的技术协议或客户提供的原始需求资料确定需求开发范围和确定需求小组成员,制订需求开发的详细计划。需求分析师根据客户提供的原始需求资料制定《需求调研计划》,对需求调研过程中要调研的问题形成《需求调研大纲》。需求调研的对象可能会是:客户、售前人员、售后服务人员、产品实施人员、竞争对手产品等。项目经理对调研计划进行内部审核。用户需求开发项目经理与用户管理层确定客户方需求提供人(高层领导、管理干部或具体用户),并协调客户方需求提供人开展工作。需求小组根据需求调研计划以及需求调研大纲,在《需求调研记录》中填写调查的信息。需求小组根据《需求调研记录》编写《用户需求说明书》。注意事项:需求分析师可以总结公司以前相同类型的软件,根据以前的经验补充完善需求说明书,经过项目组讨论后,再请客户提出意见和看法,以制定出合理完善的需求说明书;用户需求确认项目经理组织组内审核。组内审核通过后由质量人员组织进行评审。评审通过后,由客户进行确认,确认一般采用会议阅读或发送需求说明书给客户的方式进行,客户确认通过,需要填写《需求确认单》。产品需求开发在开发产品需求时,应注意前期需求的分析。需求小组根据《用户需求说明书》为客户需求建立产品构件。界定功能需求和非功能需求,并规格化描述非功能需求、模块化描述功能需求。需求小组对通过技术转化的需求建立相应的需求与产品构件的对应关系表,比如要实现客户要求的“100万条记录/秒”的查询速度,那么就需要前台查询模块和后台处理程序各承担一定的处理能力。需求小组对接口需求进行分析,分别确定产品内部的产品构件之间、产品与外部产品之间的接口需求。需求小组编写《产品需求规格说明书》。注意事项:把客户需求理解为产品需求时应剖析客户需求本质;抽取共性需求,根据客户业务需求,区分主次,归纳,分析,总结并提炼。主要通过以下两个步骤进行需求分析:1.进行业务建模,从静态和动态两个角度对目标客户群体的业务特征进行描述并抽取其中的共性和变量、内涵和外延。静态特征包括:业务目标、业务组织结构、业务角色、业务成果等。动态特征主要指:业务流程。进行业务组件抽取,根据业务模型从业务实现的角度对产品模块进行分层次抽取和划分。2.功能规划,根据之前任务中得到的业务需求信息对产品的功能及性能进行规划,划分出每次迭代版本将要实现的功能及功能优先级,以及对产品性能的要求。当前迭代的功能点必须是明确的,相对而言,后续迭代的功能可以不那么明确,在每次迭代开始前进行重新整理和明确。功能组件抽取,从业务无关的功能角度对产品功能进行分层次抽取和划分,提取可复用的功能组件。需求规格说明书是软件设计的依据,是工程的起点,应是用户需求的真实反应。编写需求规格说明书应遵循以下规则:1.正确性。每个需求必须精确描述要交付的功能。2.可行性。在现有的软硬件环境中,每个需求必须是开发人员有能力实现的。3.必要性。每个需求应载明什么是客户确实需要的,什么应该顺应于外部的需求、接口或标准。4.优先权。为了表明一个详细的产品版本中应包含哪些要点,需要为每个需求、特征分配实现的优先权。5.可证实性。是否能通过测试或者其它验证方式来决定产品中的每个需求都能正确的实现。需求分析及评审需求小组分析用户需求说明书,获得需求的优先级,以及需求模块之间的关系,以及所开发软件产品在客户方预期运行的环境等场景。需求小组按模块编写需求功能,包含需求编号、优先级、处理功能、接口等。需求小组分析需求的可执行度、项目经理分析实现需求的成本、进度、风险,最后由需求小组编写《需求可行性分析》,对于暂缓实施的功能或不实施的功能,需要与客户或用户进行协商,形成会议纪要。项目经理组织相关人员(客户等)对《需求规格说明书》进行评审确认。输出《需求调研计划.doc》(包含《需求调研大纲》)《需求调研记录.doc》《用户需求说明书.doc》《产品需求规格说明书.doc》《需求可行性分析.xls》《需求

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论