1、1.1 需求规格说明书需求规格相当于软件开发的图纸，一般说，软件需求规格说明书的格式可以根据项目的具体情况采用不同的格式，没有统一的标准。下面是一个可以参照的软件需求规格说明书的模板。1 导言1.1 目的说明编写这份项目需求规格的目的，指出预期的读者1.2 背景说明：a） 待开发的产品名称；b） 本项目的任务提出者、开发者、用户及实现该产品的单位；c） 该系统同其他系统的相互来往关系。1.3 缩写说明缩写缩写说明列出本文件中用到的外文首字母组词的原词组。1.4 术语定义术语术语定义列出本文件中用到的专门术语的定义。1.5 参考资料编号参考资料 版本号列出相关的参考资料。1.6 版本更新信息具体
2、版本更新记录如表所列。表 版本更新记录修改编号 修改日期 修改后版本 修改位置 修改内容概述2 任务概述2.1 系统定义本节描述内容包括： 项目来源及背景； 项目要达到的目标，如市场目标、技术目标等； 系统整体结构，如系统框架、系统提供的主要功能，涉及的接口等； 各组成部分结构，如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。2.2 应用环境本节应根据用户的要求对系统的运行环境进行定义，描述内容包括： 设备环境； 系统运行硬件环境； 系统运行软件环境； 系统运行网络环境；
3、用户操作模式； 当前应用环境。2.3 假定和约束列出进行本产品开发工作的假定和约束，例如经费限制、开发期限等。列出本产品的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长以及本产品的预期使用频度等重要约束。3 需求规定1.1 对功能的规定本节依据合同中定义的系统组成部分分别描述其功能，描述应包括： 功能编号； 所属产品编号； 优先级； 功能定义； 功能描述。1.2 对性能的规定本节描述用户对系统的性能需求，可能的系统性能需求有： 系统响应时间需求； 系统开放性需求； 系统可靠性需求； 系统可移植性和可扩展性需求； 系统安全性需求； 现有资源利用性需求。1.2.1 精度说明对该产品
4、的输入、输出数据精度的要求，可能包括传输过程中的精度。1.2.2 时间特性要求说明对于该产品的时间特性要求，如对：a） 响应时间；b） 更新处理时间；c） 数据的转换和传送时间；d） 计算时间等的要求。1.2.3 灵活性说明对该产品的灵活性的要求，即当需求发生某些变化时，该产品对这些变化的适应能力，如：a） 操作方式上的变化；b） 运行环境的变化；c） 同其他系统的接口的变化；d） 精度和有效时限的变化；e） 计划的变化或改进。对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。1.3 输入输出的要求解释各输入输出的数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必
5、须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。1.4 数据管理能力要求说明需要管理的文卷和记录的个数、表和文的大小规模，要按可预见的增长对数据及分量的存储要求做出估算。1.5 故障处理要求列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。1.6 其他要求如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。4 运行环境规定4.1 设备列出该产品所需要的硬件环境。说明其中的新型设备及其专门功能，包括：a) 处理器型号及内存容量；b) 外存容量、联机
6、或脱机、媒体及其存储格式。设备的型号及数量；c) 输入及输出设备的型号和数量，联机或脱机；d) 数据通信设备的型号和数量；e) 功能键及其他专用硬件。4.2 支持软件列出支持软件。包括要用到的操作系统、编译程序、测试软件等。4.3 双方签字需求方 （需方）：开发方 （供方）：日期：1.2 概要设计说明书概要设计说明书格式规范是指在概要设计阶段，制定概要设计报告所依据的标准，若在承接产品时，用户提供了概要设计说明书，则按此标准检查概要设计报告是否在内容上满足要求，若未提供概要设计说明书则需按此标准建立概要设计说明书。这里提供一个标准以供参考。1 导言1.1 目的说明文档的目的。1.2 范围说明文
7、档覆盖的范围。1.3 缩写说明定义文档中所涉及的缩略语 （若无则填写无）1.4 术语定义定义文档内使用的特定术语 （若无则填写无）1.5 引用标准列出文档制定所依据、引用的标准 （若无则填写无）1.6 参考资料列出文档制定所参考的资料 （若无则填写无）1.7 版本更新信息记录文档版本修改的过程，具体版本更新记录如表 1 所列表 版本更新记录修改编号 修改日期 修改后版本 修改位置 修改内容概述2 概述对系统定义和规格进行分析，并以此确定： 设计采用的标准和方法； 系统结构的考虑； 错误处理机制的考虑。3 规格分析根据需求规格或产品规格对系统实现的功能进行分析归纳，以便进行概要设计。4 系统体系
8、结构根据已选用的软件、硬件以及网络环境构造系统的整体框架，划分系统模块，并对系统内各个模块之间的关系进行定义。确定已定义的对象及其组件在系统内如何传输、通信。如果本系统是用户最终投入使用系统的一个子集或是将要使用现有的一些其他相关系统，在此应对他们各自的功能和相互之间的关系给予具体的描述。可通过图形的方式表示系统体系结构5 界面设计定义设计用户的所有界面6 接口定义通常设计应考虑的接口包括：人机交互接口人机交互接口应确定用户采用何种方式同系统交互，如键盘录入、鼠标操作、文件输入等以及具体的数据格式，其中包括具体的用户界面的设计形式。尽早确定人机交互接口，有利于确定概要设计的其他方面。用户界面设
9、计原则： 命令排序：（1）最常用的放在前面； （2）按习惯工作步骤排序； 极小化：尽量少用键盘组合命令，减少用户击键次数； 广度和深度：由于人的记忆局限，层次不宜大于 3； 一致性：使用一致的术语、一致的步骤、一致的动作行为； 显示提示信息； 减少用户记忆内容； 存在删除操作时。应能恢复操作； 用户界面吸引人；网络接口若本系统跨异种网络运行则应确定网络接口或采用何种网络软件，以使系统各部分间能有效地联络、通信、交换信息等，从而使整个系统紧密有效的结合在一起。系统与外部接口系统经常会与外部进行数据交换，因此应确定数据交换的时机、方式（如是批处理方式还是实时处理） 、数据交换的格式（如是采用数据包
10、还是其他方式）等。系统内模块之间的接口系统内部各模块之间也会进行数据交换，因此应确定数据交换的时机、方式等。数据库接口系统内部的各种数据通常会以数据库的方式保存，因此在接口定义时应确定与数据库进行数据交换的数据格式、时机、方式等。7 模块设计根据项目的时机需求情况，可将系统划分成若干模块，分别描述各模块的功能。这样可将复杂的系统简化、细化，有利于今后的设计和实现。划分各模块时，应尽量使其具有封闭性和独立性，具有低耦合性，减少各模块之间的关联，使其便于实现、调试、安装和维护。7.1 模块功能描述该模块在整个系统中所处的位置和所起的作用以及和其他模块的相互关系，该模块要实现的功能，对外部输入数据外
11、部触发机制的具体要求和规定。如果采用 OO 技术，可结合 Use Case 技术进行描述。7.2 模块对象（组件）对模块涉及的输入/输出，用户界面、对象或组件，对象或组件的关系以及功能实现流程进行定义。如果采用 OO 技术，可使用顺序（ sequence）图描述功能实现流程。对象设计应包括：Class Name （类名） ；Describe （类描述） ；Hierarchy （继承关系） ；Public Attribute （公共属性）Public Operation （公共操作）Private Attribute （私有属性）Private Operation （私有操作）Protected
12、 Attribute （保护属性）Protected Operation （保护操作）组件设计应包括： 组件属性； 组件关联； 组件操作； 实现约束。7.3 对象（组件）的触发机制规定对象（组件）中各个操作在什么外部条件触发下被调用以及调用后的结果。7.4 对象（组件）的关键算法如果对象（组件）中涉及关键算法，如采用何种算法加密、何种算法搜索等，需在此规定并予以相应的说明。至于其他具体操作的算法可在系统构造中去设计实现。8 故障检测和处理机制8.1 故障检测和触发机制系统发生故障可以有多种检测机制，如自动向上层汇报、由上层定时检测、将故障写入错误文件等。在此应明确系统所采用的故障检测机制。8.
13、2 故障处理机制他描述故障发生后系统如何处理，如只发个消息显示出错信息、写入一个文件、或采取相应的措施，在这里应进行详尽的描述。9 数据库设计9.1 数据库管理系统选型明确指出选用的数据库管理系统类型、版本、服务器与数据库、客户机与数据库之间的接口。9.2 设计 E-R 图根据系统数据实体之间的关系实际数据库 E-R 图。9.3 数据库表设计基于 E-R 图设计数据库物理表。10系统开发平台根据概要设计的结果选择确定系统开发所需的平台，包括硬件平台、操作系统以及开发工具等。1.3 详细设计说明书1 导言1.1 目的说明文档的目的1.2 范围说明文档覆盖的范围1.3 缩写说明定义文档中所涉及的缩
14、略语（若无则填写无）1.4 术语定义定义文档内使用的特定术语（若无则填写无）1.5 引用标准列出文档制定所依据、引用的标准（若无则填写无）1.6 参考资料列出文档制定所参考的资料（若无则填写无）1.7 版本更新信息记录文档版本修改的过程，具体版本更新记录如表 1 所列表 版本更新记录修改编号 修改日期 修改后版本 修改位置 修改内容概述2 系统设计概述本小节描述的主要内容包括： 简要描述系统的整体结构（文字和框图相结合） 模块划分和分布（如果采用 OO 技术，则可以 Component 图和 Package图表示） 系统采用的技术和实现方法3 详细设计概述本小节以模块为单位简要描述： 模块用途
15、 模块功能 特别约定4 详细设计本小节以模块为单位详细描述： 模块的定义 模块的关联 输入/输出数据说明 变量描述：重要的变量及其用途 约束或限制条件 实现描述/算法说明 说明本模块的实现流程，包括条件分支和异常处理 模块的应用逻辑 模块的数据逻辑这部分可以通过流程图或者伪代码的方式实现。5 程序提交清单程序提交清单以模块为单位分别进行描述，格式如表 2 所示。表 程序提交清单格式模块 文件名 文件类别 用途1.4 编码规范*编码阶段的产品是按照代码标准和规范编写的源代码，可在必要地时候进行部署。所以提交的文档包括： 代码标准和规范 源代码1.5 测试文档1.5.1. 测试计划文档测试是比较复
16、杂和困难的过程，为了很好控制测试的复杂性和困难性，需要仔细编写完整的测试文档。这里我们提供一个可以作为参照的系统测试计划模板。1. 介绍1.1 目的说明文档的目的。1.2 范围说明文档覆盖的范围。1.3 编写说明定义文档中所涉及的缩略语 （若无则填写无）1.4 术语定义定义文档内使用的特定术语 （若无则填写无）1.5 引用标准列出文档制定所依据、引用的标准 （若无则填写无）1.6 参考资料列出文档制定所参考的资料 （若无则填写无）1.7 版本更新信息记录文档版本修改的过程，具体版本更新记录如表 1 所列表 1 版本更新记录修改编号 修改日期 修改后版本 修改位置 修改内容概述1 测试项目对被测
17、试项目进行描述。2 测试特性描述测试的特性和不被测特性。3 测试方法分析和描述本次测试采用的测试方法和技术。4 测试标准描述测试通过的标准以及测试审批的过程。测试挂起/恢复的条件。5 系统测试交付物测试完成后提交的所有产品。6 测试任务7 环境需求8.1 硬件需求8.2 软件需求8.3 测试工具8.4 其他8 角色和职责9 人员及培训10 系统测试进度1.5.2. 测试设计文档测试设计主要是根据相应的依据（需求、概要设计、详细设计等） 设计测试方案，测试的覆盖率以及设计测试用例等。表 6-13 的测试覆盖表和表 6-14 的测试用例表可以作为参照。表 6-13 测试用例覆盖矩阵序号 功能项 预
18、期结果 优先级 测试用例表 6-14 测试用例编码测试项目名称：测试项目标题：测试人员： 测试时间：测试内容：测试环境与系统配置：测试输入数据：测试次数：预期结果：测试过程：测试结果：测试结论：实现限制：备注：1.5.3. 测试跟踪文档可以采用工具跟踪测试的结果，如表 6-15 所列就是一个缺陷跟踪的表格。目前市场上存在很多缺陷跟踪的商用工具软件。表 6-15 测试跟踪记录表序 号 时 间 事件描述 错误类型 状 态 处理结果 测试人 开发人1231.5.4. 测试总结文档下面的测试总结报告模板（可裁剪） ，可以参照。1 介绍1.1 目的说明文档的目的。1.2 范围说明文档覆盖的范围。1.3
19、编写说明定义文档中所涉及的缩略语 （若无则填写无）1.4 术语定义定义文档内使用的特定术语 （若无则填写无）1.5 引用标准列出文档制定所依据、引用的标准 （若无则填写无）1.6 参考资料列出文档制定所参考的资料 （若无则填写无）1.7 版本更新信息记录文档版本修改的过程，具体版本更新记录如表 1 所列表 1 版本更新记录修改编号 修改日期 修改后版本 修改位置 修改内容概述2 测试时间、地点和人员3 测试环境描述4 测试数据度量4.1 测试用例执行度量4.2 测试进度和工作量度量4.3 缺陷数据度量4.4 综合数据分析计划进度偏差 = (实际进度 计划进度) / 计划进度 * 100%用例执行效率 = 执行用例总数 / 执行总时间 （小时）用例密度 = （用例总数 / 规模）* 100缺陷密度 = （缺陷总数 / 规模）* 100用例质量 = （缺陷总数 / 用例总数）* 100缺陷严重程度分布饼图：缺陷类型分布饼图：5 测试评估5.1 测试任务评估例如，评估结论：本次测试执行准备充足，完成了既定目标。5.2 测试对象评估例如，评估结论：测试对象符合系统测试阶段质量要求，可以进入到下一阶
