产品研发流程程序文件

3目的及适用范围

3.1为规范产品研发过程，提高产品研发的效率、质量，降低研发成本，特制定本程序；

3.2本程序文件适用于侏罗纪公司产品研发；

3.3本程序文件由侏罗纪公司制定，其解释权及修改权属于；

3.4本程序文件从2003年月日起执行；

4职责

4.1产品部负责产品研发；

4.2质量控制部负责对产品开发过程中的里程碑产生的相关成果和文档进行质量控制，并将符合规

范的成果放入资源中心存档；

4.3技术支持部和市场部负责宣传材料和用户手册的制作，以及和产品销售流程的衔接环节和动

作；

5产品研发流程

5.1技术副总从公司战略规划决案中形成产品规划，下发给技术研发部；

5.2技术研发部经理进行产品研发立项；

5.3公司组织人员对产品立项进行评审，若评审未通过，相关文档放入行政综合部备案；

5.4若立项评审通过，质量保证部对立项进行质量检验，若质检未通过，修改立项报告；

5.5若质检通过，开始制订项目计划，同时质量保证部将立项相关文档放入行政综合部归档；

5.6技术部经理将项目计划提交给技术副总评审，若未通过，技术部经理修改项目计划；

5.7若评审通过，质量控制部对项目计划进行评审，若质检评审未通过，产品经理修改项目计划，

若质检评审通过，产品总监安排研发项目资源；

5.8产品经理获得研发项目资源后，进行需求分析，并将相关成果交技术委员会进行内容评审；

5.9若内容评审未通过，产品经理修改需求分析；若内容评审通过，质量控制部对《需求分析说明》

进行质量检验；

5.10若质检未通过，产品经理修改《需求分析说明》，若质检通过，相关成果和文档放入资源

管理部归档，同时产品经理带领研发相关人员进行总体设计；

5.11产品经理和研发人员完成总体设计后将相关成果交技术委员会进行内容评审；

5.12若内容评审未通过，产品经理修改《总体设计说明》；若内容评审通过，质量控制部对《总体设计说明》进行质量检验；

5.13若质检未通过，产品经理修改《总体设计说明》，若质检通过，相关成果和文档放入资源管理部归档，同时产品经理和研发人员进行程序设计/测试；

5.14完成程序设计/测试后，产品经理将相关成果交质量控制部进行功能测试，若测试未通过，产品经理修改相关成果，若测试通过，质量控制部对相关成果和文档进行质量检验；

5.15若质检未通过，产品经理修改相关成果和文档；若质检通过，质量控制部将相关成果和文档放入资源管理部门归档；

5.16同时产品研发组制作软件，技术支持部和市场部制作宣传材料，之后，技术支持部对销售人员进行内部培训，市场部申请并取得著作权；

5.17市场部在取得著作权后制作用户/技术手册；

5.18产品研发组完成软件制作后，质量控制部对制作的软件进行质量检验，若未通过质检，产品研发组重新制作软件；若通过质检，相关成果和文档放入资源管理部归档，同时产品经理进行产品研发总结；

5.19质量控制部将产品研发总结等相关成果和文档放入资源管理部，同时市场部进行软件产品包装，销售部进行产品销售；

6相关文件

6.1《产品规划说明书》

6.2《立项报告》

6.3《综合评审记录》

6.4《质量控制立项报告和可行性分析报告说明书》

6.5《项目计划书》

6.6《质量控制项目计划评审记录》

6.7《资源调度单》

6.8《需求分析说明书》

6.9《质量控制需求分析说明书评审报告》

6.10《资源中心验收单》

6.11《评审规程》

6.12《总体设计说明书》

6.13《概要设计说明书》

6.14《详细设计说明书》

6.15《质量控制系统设计报告评审记录》6.16著作权相关文档（略）

6.17《软件质量保证单》

6.18《软件缺陷报告》

6.19《项目总结》

产品规划说明书

时间合评审记录（公司）

时间

立项报告评审记录

记录编号：- 时间：年月日

1．本页不足记述评审意见时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。

第页/共页

HS-20-QA-0001-00

风险评估与控制（立项建议报告评审附页）

1.评估中风险不限于表中已列出的，应依据评审的具体情况增加风险项。并将各项填写完整。

2.风险描述：描述当前过程中可能发生的风险。风险发生可能性：风险发生的概率，以百分数表示，为0到1，增量为0.05。风险级别：风险发生造成损失的严重程度，以0~10级表示，其中10级为最高级。风险现值：风险发生可能性与风险级别的乘积。风险控制措施：预防风险发生的措施。

第页/共页

HS-20-QA-0001-00

可行性分析报告评审记录

记录编号：- 时间：年月日

1．本页不足记述评审意见时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。

第页/共页

HS-20-QA-0001-00

风险评估与控制（可行性分析报告评审附页）

1.评估中风险不限于表中已列出的，应依据评审的具体情况增加风险项。并将各项填写完整。

第页/共页

项目计划书

备注：抄送财务部、人力资源部

时间

项目启动计划评审记录

记录编号：时间：年月日

2.评审完成后由开发体系决策层SMG批准。

3.本页不足记述结果时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。

第页/共页

开发计划评审记录

记录编号：时间：年月日

2.评审完成后由开发体系决策层SMG批准。

3.本页不足记述结果时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。

第页/共页

开发计划检查表（开发计划评审附页）项目名称：项目编号：

检查人/日期：批准人/日期：

HS-20-QA-0001-00

风险评估与控制（开发计划评审附页）

1.评估中风险不限于表中已列出的，应依据评审的具体情况增加风险项。并将各项填写完整。

第页/共页

.14

软件问题报告

记录编号：- 时间：年月日

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）详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、有效输入范围（包括精度和公差）。

（2）操作员具体的操作控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的位置。例如：当打印检查时，要求操作员进行格式调整。

（3）指明引用的输入接口资料。

3.1.3处理

描述为获得预期输出结果，对输入数据及中间参数进行的全部操作。它包括如下的说明：

（1）输入数据的有效性检查手段；

（2）操作的顺序和处理过程，包括事件的时间设定；

（3）异常情况的响应，例如：溢出、通信故障、错误处理等；

（4）受操作影响的参数；

（5）降级运行的要求；

（6）用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）。

（7）输出数据的有效性检查手段。

3.1.4输出

（1）详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息；

（2）指明引用的输出接口资料。

【技巧】可以用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求。

【提醒注意】对着重于输入输出行为的系统来说，需求说明书应指定所有有意义的输入、输出对及其序列。当一个系统

要求记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态做出响应。这种情况犹如有限状态机。

3.2性能需求

从整体来说，本节应具体说明软件、或人与软件交互的静态或动态数值需求。

静态数值需求可能包括：支持的终端数，支持并行操作的用户数，处理的文卷和记录数，

表和文卷的大小等。

动态数值需求可能包括：欲处理的事务和任务的数量，以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量等。

所有这些需求都必须用可以度量的术语来叙述。例如：95%的事务必须在小于1s时间内处理完，不然，操作员将不等待处理的完成。

精度

说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。

时间特性要求

说明对于该软件的时间特性要求，如对响应时间、更新处理时间、数据的转换和传送时间、解题时间等的要求。

灵活性

说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：操作方式上的变化、运行环境的变化、同其他软件的接口的变化、精度和有效时限的变化、计划的变化或改进等。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

3.3软件属性需求

在软件的需求之中有若干个属性，下面列举一部分。

【提醒注意】下列属性决不能理解为是一个标准的或完整的清单，而应根据项目实际情况予以列举。

3.3.1正确性

3.3.2健壮性

3.3.3安全保密性

这里指的是保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。这个领域的具体需求必须包括：利用可靠的密码技术，掌握特定的记录或历史数据集，给不同的模块分配不同的功能，限定一个程序中某些区域的通信，计算临界值的检查等。

3.3.4易使用性

3.3.5可理解性

3.3.6可维护性

这里规定若干需求以确保软件是可维护的。例如：软件模块所需要的特殊的耦合矩阵，为微型装置指定特殊的数据/程序分割要求等。

3.3.7可测试性

3.3.8可移植性

这里规定把软件从一种环境移植到另一种环境所要求的用户程序、用户接口兼容方面的约束等。

3.4外部接口需求