1目的及适用范围1.1为规范产品研发过程，提高产品研发的效率、质量，降低研发成本，特制定本程序；1.2本程序文件适用于侏罗纪公司产品研发；1.3本程序文件由侏罗纪公司制定，其解释权及修改权属于；1.4本程序文件从2003年月日起执行；2职责2.1产品部负责产品研发；2.2质量控制部负责对产品开发过程中的里程碑产生的相关成果和文档进行质量控制，并将符合规范的成果放入资源中心存档；2.3技术支持部和市场部负责宣传材料和用户手册的制作，以及和产品销售流程的衔接环节和动作；3产品研发流程3.1技术副总从公司战略规划决案中形成产品规划，下发给技术研发部；3.2技术研发部经理进行产品研发立项；3.3公司组织人员对产品立项进行评审，若评审未通过，相关文档放入行政综合部备案；3.4若立项评审通过，质量保证部对立项进行质量检验，若质检未通过，修改立项报告；3.5若质检通过，开始制订项目计划，同时质量保证部将立项相关文档放入行政综合部归档；3.6技术部经理将项目计划提交给技术副总评审，若未通过，技术部经理修改项目计划；3.7若评审通过，质量控制部对项目计划进行评审，若质检评审未通过，产品经理修改项目计划，若质检评审通过，产品总监安排研发项目资源；3.8产品经理获得研发项目资源后，进行需求分析，并将相关成果交技术委员会进行内容评审；3.9若内容评审未通过，产品经理修改需求分析；若内容评审通过，质量控制部对《需求分析说明》进行质量检验；3.10若质检未通过，产品经理修改《需求分析说明》，若质检通过，相关成果和文档放入资源管理部归档，同时产品经理带领研发相关人员进行总体设计；3.11产品经理和研发人员完成总体设计后将相关成果交技术委员会进行内容评审；3.12若内容评审未通过，产品经理修改《总体设计说明》；若内容评审通过，质量控制部对《总体设计说明》进行质量检验；3.13若质检未通过，产品经理修改《总体设计说明》，若质检通过，相关成果和文档放入资源管理部归档，同时产品经理和研发人员进行程序设计/测试；3.14完成程序设计/测试后，产品经理将相关成果交质量控制部进行功能测试，若测试未通过，产品经理修改相关成果，若测试通过，质量控制部对相关成果和文档进行质量检验；3.15若质检未通过，产品经理修改相关成果和文档；若质检通过，质量控制部将相关成果和文档放入资源管理部门归档；3.16同时产品研发组制作软件，技术支持部和市场部制作宣传材料，之后，技术支持部对销售人员进行内部培训，市场部申请并取得着作权；3.17市场部在取得着作权后制作用户/技术手册；3.18产品研发组完成软件制作后，质量控制部对制作的软件进行质量检验，若未通过质检，产品研发组重新制作软件；若通过质检，相关成果和文档放入资源管理部归档，同时产品经理进行产品研发总结；3.19质量控制部将产品研发总结等相关成果和文档放入资源管理部，同时市场部进行软件产品包装，销售部进行产品销售；4相关文件4.1《产品规划说明书》4.2《立项报告》4.3《综合评审记录》4.4《质量控制立项报告和可行性分析报告说明书》4.5《项目计划书》4.6《质量控制项目计划评审记录》4.7《资源调度单》4.8《需求分析说明书》4.9《质量控制需求分析说明书评审报告》4.10《资源中心验收单》4.11《评审规程》4.12《总体设计说明书》4.13《概要设计说明书》4.14《详细设计说明书》4.15《质量控制系统设计报告评审记录》4.16着作权相关文档（略）4.17《软件质量保证单》4.18《软件缺陷报告》4.19《项目总结》产品规划说明书时间合评审记录（公司）时间立项报告评审记录记录编号： - 时间：年月日1．本页不足记述评审意见时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页风险评估与控制（立项建议报告评审附页）1.评估中风险不限于表中已列出的，应依据评审的具体情况增加风险项。
并将各项填写完整。
2.风险描述：描述当前过程中可能发生的风险。
风险发生可能性：风险发生的概率，以百分数表示，为0到1，增量为0.05。
风险级别：风险发生造成损失的严重程度，以0~10级表示，其中10级 为最高级。
风险现值：风险发生可能性与风险级别的乘积。
风险控制措施：预防风险发生的措施。
第 页/共 页可行性分析报告评审记录记录编号： - 时间：年月日1．本页不足记述评审意见时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页风险评估与控制（可行性分析报告评审附页）1.评估中风险不限于表中已列出的，应依据评审的具体情况增加风险项。
并将各项填写完整。
2.风险描述：描述当前过程中可能发生的风险。
风险发生可能性：风险发生的概率，以百分数表示，为0到1，增量为0.05。
风险级别：风险发生造成损失的严重程度，以0~10级表示，其中10级 为最高级。
风险现值：风险发生可能性与风险级别的乘积。
风险控制措施：预防风险发生的措施。
第 页/共 页项目计划书备注：抄送财务部、人力资源部时间项目启动计划评审记录记录编号：时间：年月日1.项目启动计划评审由项目管理部门组织评审。
2.评审完成后由开发体系决策层SMG批准。
3.本页不足记述结果时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页开发计划评审记录记录编号：时间：年月日2.评审完成后由开发体系决策层SMG批准。
3.本页不足记述结果时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页开发计划检查表（开发计划评审附页）项目名称：项目编号：检查人/日期：批准人/日期：风险评估与控制（开发计划评审附页）1.评估中风险不限于表中已列出的，应依据评审的具体情况增加风险项。
并将各项填写完整。
2.风险描述：描述当前过程中可能发生的风险。
风险发生可能性：风险发生的概率，以百分数表示，为0到1，增量为0.05。
风险级别：风险发生造成损失的严重程度，以0~10级表示，其中10级 为最高级。
风险现值：风险发生可能性与风险级别的乘积。
风险控制措施：预防风险发生的措施。
第 页/共 页软件问题报告记录编号： - 时间：年月日1. 问题描述栏中可以填写问题现象及其产生原因，如果有用户的书面说明，则可以直接引用。
2. 修改描述一栏描述问题的确切原因、修改办法以及修改后的效果。
3. 本页不足记述时，可以有附页，格式自定。
总页数包括本页与所有附页。
项目资源调度单（借鉴产品中心任务书）备注：抄送财务、人力资源部时间软件需求分析说明书1.引言1.1目的说明编写软件需求说明书的目的，指出预期的读者。
1.2背景（1）待开发的软件系统的名称；（2）本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；（3）该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3参考资料列出所用的参考资料，如：（1）本项目的经核准的计划任务书或合同、上级机关的批文；（2）属于本项目的其他已发表的文件；（3）本文件中各处引用的文件、资料，包括所需用到的软件开发标准。
（4）列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
1.4术语列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
2.项目概述本部分描述影响产品和其需求的一般因素。
此处并不说明具体的需求，其描述的内容仅仅是为了更容易理解、深化需求规格，其用意是为从多方面、多角度考虑需求以提供思维参考点。
2.1一般描述本节描述软件开发项目的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料，解释待开发产品和其相关的其他产品或项目的关系。
如果本产品是独立的，而且自含全部内容，应在此说明。
如果所定义的产品是一个较大系统或项目中的一个组成部分，那么在此需要描述如下内容：要概述这个较大的系统或项目的每一个组成部分的功能，并说明其接口；指出本产品主要的外部接口（不需要详细描述，详细描述放在其他章节中）；描述所使用的计算机硬件、外围设备。
这里仅仅是一个综述性描述。
【技巧】在本节的描述中，用一个方框图来表达一个较大的系统或项目的主要组成部分、相互联系和外部接口是非常有帮助的。
【提醒注意】本节所描述的既不是设计方案，也不是在方案设计时的约束条件，它仅仅为方案设计时的约束条件提供了一个可以解释的理由。
2.2功能简述对待的软件产品功能提供一个摘要。
【技巧】编制功能的一种方法是制作功能表，以便客户或第一次读这个文件的人很容易理解；用方框图来表达不同的功能和它们的关系有益于理解。
【提醒注意】方框图不是产品的设计，而只是一种有效的解释方式。
本节不是具体需求的陈述，只是对具体需求部分中为什么要对一些需求做出描述的铺垫。
2.3用户特点本节描述产品最终用户（包括操作员、维护员和系统工作人员等）具有的受教育水平、工作经验及技术专长等一般特点。
如果系统的大多数用户是一些临时的用户，那么就要求系统包含如何完成基本功能的提示，而不是假设用户已经从过去的会议或从阅读用户指南中了解到这些细节。
2.4假定和约束给出影响软件需求说明书中陈述的需求的每一个因素。
这些因素不是软件的设计约束，但是它们的改变可能影响到需求说明书中的需求。
这些假定和约束条件可能包括：管理方针；运行环境，包括硬件设备和支持软件的限制；与其他应用间的接口；并行操作；实时功能；审查功能；控制功能；所需的高级语言；通信协议；应用的临界点；安全保密方面的考虑等。
【提醒注意】本节中描述的因素是软件需求所依据的基石，当这些基石发生不可抗拒或控制的改变时对产品需求将造成影响。
本节的内容不能用来陈述具体需求或强加若干特殊的设计约束，而应对具体需求部分中的某些具体需求或设计约束的描述提供理由。
3.具体需求本章应包括软件开发者在建立设计时需要的全部细节。
本章的编写应该遵循如下基本原则：遵循可验证性、无歧义性等的准则，对每一个需求细节作具体描述；在软件需求说明书前言、项目概述、附录部分的有关讨论中，要提供对任何一个具体需求交叉引用的背景；按符合逻辑的和可读的方式组织；详细描述每一个需求，使得该需求应达到的目标能够用指定的方法进行客观的验证。
【提醒注意】每一项需求的描述都应包括至少5个方面的内容：功能需求；性能需求；属性需求；外部接口需求；设计约束。
3.1功能需求用文字、图表或数学公式详细描述被开发软件的输入、处理、输出以及在上述过程中发生的基本操作。
对于每一类功能或者有时对于每一个功能，这部分通常由引言、输入、处理、输出四个部分组成：3.1.1引言（1）描述该功能要达到的目标、所采用的方法和技术；（2）清楚说明功能意图的由来和背景。
3.1.2输入（1）详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、有效输入范围（包括精度和公差）。