项目管理中，我们所需要的文档这里包括15类项目文档：
1 软件开发计划
2 需求规格说明书
3 软件概要设计说明
4 数据库设计说明
5 软件详细设计说明
6 可执行程序生成说明
7 软件测试计划
8 软件测试说明
9 软件测试报告
10 安装部署手册
11 源代码交付说明
12 上线部署方案
13 上线部署实施报告
14 软件终验测试方案
15 软件终验测试报告
在本篇文章中就将对这15类项目文档做一个完整的内容介绍要求。完全可以复用到其他项目中去使用。这里着眼于内容要求，对于具体的项目而言，文档名称可能存在不同的称谓，也允许文档的分拆和合并，但文章中所述内容要求应得到体现。
格式要求
所有文档应包括封面、文档变更记录、目录和正文四个部分。封面应包括文档提供方的名称、项目名称、项目阶段、文件名称、文件版本和总页数。应有文档维护记录。发生重大版本变更时，应保存不同版本的技术文档，同时应保存必要的变更说明和变更审核记录。
1 软件开发计划
(一) 文档内容要求
1 引言
1.1标识
本条应包含本文档的完整标识，以及本文档适用的系统和软件的完整标识，包括标识号、标题、缩略词语、版本号和发行号。
1.2系统概述
本条应简述本文档适用的系统和软件的用途，应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的业主方、用户、承建方、监理方等；标识当前和计划的运行现场等。
1.3文档概述
概述本文档的用途和内容，并描述与其使用有关的保密性和私密性的要求。
1.4与其他计划之间的关系
描述本计划和其他项目管理计划的关系。
1.5输入基线
给出编写本项目开发计划的输入基线，如业务需求说明书等。
2 引用文件
应列出本文档引用的所有文档的编号、标题、修订版本、日期和来源。
- 项目范围及约束条件
3.1 交付产品
列出本项目的交付产品成果，包括软件程序、交付文档等，以及各交付成果的交付期限。
3.2 业务需求和约束条件
分条阐述项目的业务需求和约束条件；
3.3 其它方面的需求和约束条件
分条阐述其它方面的约束，如项目进度要求、保密性等。
3.4 项目目标
综述项目进度目标、成本目标、质量目标。
4 项目总体计划
4.1软件开发过程和里程碑
描述要采用的软件开发过程。计划应覆盖论及它的所有合同条款，确定已计划的开发阶段(适用)、目标和各阶段要执行的软件开发活动。
里程碑设置分条阐述里程碑/阶段名称、期限、里程碑标志说明（进入条件和输出）、评审方式等。
提供一张工作产品矩阵表，描述各工作产品的编号、名称、产生阶段、评审方式等。工作产品包括各阶段产生的过程文档和技术文档等，是工作任务分解和配置管理计划制定的重要依据。
4.2软件开发方法
描述或引用要使用的软件开发方法，包括为支持这些方法所使用的手工、自动工具和过程的描述。
4.3软件产品标准
描述或引用在表达需求、设计、编码、测试用例、测试过程和测试结果方面要遵循的标准和要求。对要使用的各种编程语言应提供编码标准。
4.4 评审途径
阐述软件内部评审的方式，以及需方或授权代表（总集、监理）实施软件产品和活动评审的途径和方式。
4.5软件配置管理
描述针对本项目所采用和遵循的软件配置管理方法.包括配置项的标识、控制、状态统计、审核、交付等。 具体的配置项识别和管理可在配置管理计划中另文给出。
4.6软件质量保证
描述针对在本项目所采用和遵循的软件质量保证方法。包括软件质量保证评估、软件质量保证记录和处理、第三方独立性保证等。质量保证计划也可另文给出。承建方应在计划中落实下述内部审核和检查工作：
软件计划审核：在软件计划编制阶段结束后必须进行软件计划审核，以确保在软件开发计划、软件配置管理计划、软件质量保证计划中所规定的计划的合适性。
软件需求审核：在软件需求分析阶段结束后必须进行软件需求审核，以确保在软件需求规格说明中所规定的各项需求的合适性。
软件概要设计审核：在软件设计结束后必须进行软件设计的审核，以评价软件概要设计说明、数据结构设计说明中所描述的软件设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性；以及在数据结构、功能、算法和过程描述等方面的合适性。
软件详细设计、编码阶段的审核：在软件详细设计和编码实现完成之后要对软件详细设计说明、软件测试计划、软件测试说明（含软件测试用例）、目标程序生成说明进行审核，以确认业主方的业务需求是否得到满足，验证软件需求规格说明中的需求是否已由软件设计说明描述的设计实现，软件设计说明表达的设计是否已由编码实现。
出厂测试审核：在完成出厂测试之后要对源代码交付验证说明、软件测试报告（含源代码交付验证报告）以及按照合同要求应提交给业主方的所有文档（如：软件用户手册等）进行审核，以评价待交付的程序及文档的质量是否满足出厂交付要求、覆盖了业主方的业务需求、做好了交付准备。
部署审核：在配合监理方和业主方完成测试工作后承建方进入系统部署阶段，在完成软件部署并配合完成系统联调联试后，要对部署实施报告进行审核，以验证部署实施的真实性以及外部接口的正确性。
4.7问题跟踪和处理(更正活动)
描述软件更正活动中要遵循的方法，包括不同阶段的问题发现、纪录、报告、处理、审核和更正流程，问题/bug跟踪系统的选用等。须论及出厂测试、需方验证测试、试运行三个阶段。
4.8 档案收集
阐述作为承建方在项目进行过程中进行自身档案收集管理的方法，包括纸质档案。
5 项目估算及进度计划
5.1 工作任务分解
分解项目工作任务，得出工作任务分解结构（WBS）。
5.2 规模估算
估算项目规模，如需新编的代码行数、文档页数等。
5.3 工作量估算
根据规模估算及项目经验，估算项目工作量。
5.4 进度计划
在工作任务分解结构（WBS）、工作量估算的基础上，进行活动排序、资源分配，进而编制进度计划甘特图,标识各活动的依赖关系、资源分配情况、起止时间等。
5.5风险估计及应对方法
逐条给出识别的风险及其风险估计量化指标（可能性、严重性等级）、相应的对策和缓解方案。建议以列表的方式给出。
6 项目跟踪与变更管理
6.1 项目日常跟踪
阐述项目日常跟踪方法，包括由业主方和授权代表(监理方)参与的项目跟踪。
6.2 里程碑评审
阐述或引用项目各里程碑评审的方法。
6.3 变更管理
包括计划变更、需求变更等的处理流程、机制和方法。
7 项目组织和资源
7.1项目组织
本条应描述本项目要采用的组织结构，包括涉及的组织机构、机构之间的关系、执行所需活动的每个机构的权限和职责。
7.2项目资源
本条应描述适用于本项目的资源。 主要包括：
a.人力资源，分条说明投入此项目的人员、职责、投入阶段、地理位置和涉密程度等；
b. 开发人员要使用的设施，包括执行工作的地理位置、要使用的设施、保密区域和运用合同项目的设施的其他特性；
c.为满足合同需要，需方应提供的设备、软件、服务、文档、资料及设施及需要提供的时间。
8 内部培训
根据项目的技术要求和项目成员的情况，确定是否需要进行项目培训，并制订培训计划。如不需要培训，应说明理由。
9 注解
本章应包含有助于理解本文档的一般信息(例如原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。
附录
附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A, B等)编排。
(二)内容审核要点：
1．项目范围阐述与合同及其附件要求等是否一致；
2．工作任务分解与项目范围/需求是否一致；
3．工作任务分解、工作量估计和活动进度安排是否合理；
4．计划内容是否包括软件项目管理的各个必要的方面；
5．工作产品定义是否包含需方所要求的各相关必要文档；
6．组织机构和人力资源安排和分配是否合理并符合合同相关要求；
7．项目日常跟踪管理是否具有可操作性；
8．项目开发过程中的问题/bug处理机制是否具有可操作性；
9．档案收集管理是否具有可操作性。
10．是否制定了合适的配置管理策略和质量保证策略。
2 软件需求规格说明书
（一）文档内容要求
1 引言
1.1 编写目的
说明编写这份用户需求说明书的目的，指出预期的读者范围。
1.2 范围
说明系统的业务范围以及功能界限的划分。
1.3 术语和缩略语
提供此文档中用到的专门术语的定义和缩写词的原词组。
1.4 参考资料
列出此文档所参考的文档。这些文档可以是合同、标准、指南、和其他的用户需求说明书。
2 需求概述
2.1 项目背景
提供对项目的整体描述。如果此文档定义的项目是一个更大的项目的一个构件，应提供同更大项目或系统的关系和这个项目会提供的功能。并且提供和明确两者之间的关系。
2.2 操作环境
描述使软件运行的运行环境。给出了软件运行所需的硬件平台、操作系统和软件平台等细节。
如果功能/子模块/子项目涉及仅仅是整体的产品/项目、硬件/软件环境的子集，也在这里指出。
2.3 设计和实现限制
包括客户在所采用的技术和运行环境等方面的特定要求，以及其它影响开发人员自由选择的问题，必要时说明原因。
2.4 假设、依赖和外部风险
明确在准备此文档时所做的假设和外部依赖条件，这些假设会影响需求的状态。
对外部项目或软件的接口服务的依赖条件也可在这里说明。
明确客户应该会关心的外部风险，如：第三方供应的软件和硬件应该准时送到、所依赖软件是否按时提供等等。
对需求优先等级的定义也需要给出。
3 功能需求
以下详细描述系统功能需求。如果需要，用例图及其描述可以作为附录。功能点、子功能或功能可以指定缺省优先级。
3.1 <功能名称1>
所有的功能名、子功能名、功能点都需要以某种全文档唯一的方式进行编号，以备审核、设计、实现、测试时引用。功能、子功能都要规定优先等级。
3.1.1 功能概述
对本功能进行概要描述。如有需要，可用结构图来描述本功能中各模块的结构关系。
3.1.2 相关业务流程
根据需要，提供相应的业务流程图。
3.1.3 <子功能名称1>
3.1.3.1 子功能描述
对子功能作文字描述。如果需要，对子功能流程进行流程描述，并提供子功能业务流程图。
3.1.3.2 <功能点1>
对于每一功能点，需要具体描述其各种需求，由下列部分组成，可以以表格的形式给出：
a.功能点编号
b.功能点描述
具体描述该功能点所提供的功能。
c.操作
这里说明用户要求的常规的和特殊的操作。
d.输入
描述该功能的所有输入数据，如输入源、数量、度量单位、时间设定和有效输入范围等。
e.输出
详细描述该功能的所有输出数据，如输出目的地、数量、度量单位、时间关系、有效输出范围、非法值的处理、出错信息等。
f.业务表单
如果需要，描述该模块所涉及的业务表单。
g. 处理或算法
定义获得预期输出结果的全部操作，包括输入数据的有效性检查、操作的顺序、异常情况的响应、把输入转换成相应输出的方法、输出数据的有效性检查等。
f. 数据库要求
如果需要，指出对于数据库表设计方面的要求
3.1.3.3 <功能点2>功能需求
……
3.1.4 <子功能名称1>功能需求
……
3.2 <功能名称2>功能需求
……
4 外部接口需求
所有接口都必须提供唯一标识。
4.1 用户接口
提供用户使用软件产品时的接口需求。例如，如果系统的用户通过显示终端进行操作，就必须指定如下要求：
a． 对屏幕格式的要求；
b． 报表或菜单的页面格式和内容；
c． 程序功能键的可用性。
屏幕接口要求细节很多，建议提供界面demo。
4.2 硬件接口
要指出软件产品和系统硬部件之间每一个接口。包括支撑什么样的设备，如何支撑这些设备，有何约定。
4.3 软件接口
需要说明3方面的软件接口内容：
1．说明需使用的其他软件产品（例如，数据管理系统、工作流软件、中间件产品等）；
2．说明需要使用到的其它应用软件系统所提供的接口功能；
3．说明需要提供出来供其它应用软件系统调用的公用接口功能服务。对这些接口要尽量做形式化描述。
5.成品软件定制需求：
如果本项目是在成熟的成品软件基础上进行进一步的定制开发，需要在此说明本项目所依据的成品软件版本。并根据成品软件的功能，对照本项目需求，以列表的方式明确说明哪些功能点需要进行进一步的定制开发。
- 性能需求
以下详细说明软件各项性能需求，(如适用)包括以下方面。
6.1 数据容量
根据实际情况，确定数据容量。
6.2 时间特性
说明系统在响应时间、更新处理时间、数据转换与传输时间、运行时间等方面所需达到的时间特性。
6.3 吞吐量
系统需要支持并发的处理能力。
6.4 安全性
系统安全方面的需求描述。
6.5 其它质量属性
指明软件产品在可靠性、可移植性、实用性、可维护性等方面的目标和需求。应尽量以明确的、量化的、可检验的方式来描述。 - 其他需求
7.1 可测试性需求
指出可测试性方面的需求。如对于只能在生产环境才能满足的测试条件，如何在出厂测试时用变通的方式解决。
7.2 安装和操作
定义软件安装和操作方面的需求，例如安装的环境要求，以及安装的方式等。
7.3 安全保密
定义有关产品安全保密方面的要求和说明。如果没有这方面的要求， 注明无安全保密性要求。
7.6 维护服务
对软件的升级、维护以及服务方面的需求说明，包含维护方式和提供服务的方式，以及服务的质量要求，时间要求等。
8 辅助部分
8.1 未确定的问题
说明目前尚未确定的问题，以及对这些问题的处理的计划。
8.2 风险分析
说明本项目面临的主要风险，例如需求可实现性、需求变动、时间压力、技术复杂度、人力资源不足等，并提出规避或预防措施。
8.3 编程工具
说明对开发的工具要求，包含编程语言，使用的开发环境，以及其中涉及到的其它工具的要求，例如建模工具，分析工具，配置管理工具等。
8.4 其它支撑软件
软件运行说必需的环境的说明，包含软件使用到地第三方的组件以及应用程序的说明。
9 项目的交付
9.1 交付形式
项目的交付方式的说明，包含交付的产品、文档，以及交付的方式等。
9.2 测试要求
说明需要对目标系统进行哪些方面的测试，如功能测试、集成测试、压力测试等，以及各种测试的功能覆盖面要求。
（二）内容审核要点：
1．功能描述是否完备，是否通盘考虑了业务需求说明书所述内容；
2．文档内容是否充分反应了与用户的沟通成果；
3．功能描述是否明确，是否有二义性、含糊的或相互矛盾的需求内容；
4．功能点是否细化到合理程度；
5．对外接口服务的描述是否全面并细化到合理程度；
6．对于外部依赖条件的描述是否准确全面；
7．是否提供了用户所需的人机界面的必要描述（如以demo方式）；
9．对性能指标是否进行了必要的说明；
10．是否给出了必要的数据库设计方面的要求；
3 软件概要设计说明
（一）文档内容要求
1 引言
1.1 编写目的
说明编写这份概要设计说明书的目的，指出预期的读者。（对于由多个子系统构成的系统，可以根据需要针对子系统编写单独的软件概要设计说明）
1.2背景
说明：
a． 待开发软件系统的名称；
b． 列出此项目的任务提出者、开发者、用户以及将运行该软件的位置；
1.3术语和缩略语
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有关的参考文件，如：
a． 本项目的经核准的计划任务书或合同，上级机关的批文；
b． 属于本项目的其他已编制文件；
c． 本文件中各处引用的文件、资料，包括所要用到的软件开发标准、专业技术标准。列出这些文件的标题、文件编号、发表日期、出版单位和来源。
2总体设计
2.1需求规定
说明对本系统的主要的输入输出项目、处理的功能性能要求。可以引用软件规格说明文档以避免重复。
2.2运行环境
简要地说明对本系统的运行环境（包括硬件环境和支持环境）的规定。
2.3设计思想
2.1.1 系统构思
说明本系统设计的系统构思。
2.1.2 关键技术与算法
说明本系统设计采用的关键技术和主要算法。
2.1.3关键数据结构
简要说明本系统实现中的最主要的数据结构。
2.2系统总体结构
以图表的形式说明本系统的系统元素（各层模块、子模块、公用模块等）的划分，扼要说明各系统元素的标识和功能，分层次说明各系统元素之间的关系。
2.3基本处理流程
2.3.1系统流程图
用流程图的方式说明本系统的主要控制流程和处理流程。
2.3.2 数据流程图
根据需要，用数据流程图说明本系统的主要数据及其流转过程，并说明流转过程中的处理动作。
2.4功能需求与模块的关系
说明各项功能需求的实现同各模块的分配关系。要与软件规格说明中的功能编号相一致。
2.6尚未解决的问题
说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。
3接口设计
3.1外部接口
说明本系统同外界的所有接口设计。包括本系统与硬件之间的接口设计、本系统与各支持软件之间的接口设计、对外提供的接口服务的设计。
3.2内部接口
说明本系统之内的各个系统元素之间的接口的安排。
4性能设计及质量属性考虑
通过设计落实在软件规格说明中的各种性能及质量属性规定。
5数据库设计
说明本系统内所使用的数据结构设计要点及与程序模块间的关系。对数据库表的设计一般以另文方式（数据库设计说明）给出。
（二）内容审核要点：
1．是否全面考虑了软件需求规格说明文档的功能需求；
2．所述功能名称及编号与软件需求规格说明文档是否一致；
3．总体结构是否清晰合理；
4．是否包括对外提供的接口服务的形式化表述和设计内容；
5．数据结构设计内容的全面性及合理性；
4 数据库设计说明
(一) 文档内容要求
1 概述
1.1 编写目的
描述该文档的编写目的。
1.2 参考资料
列出此文档所参考的文档，如软件需求规格说明、软件设计说明等。
1.3 分类
（若有）对存储数据分类进行简要说明（数据可以按照子系统进行划分）。
· 第全局类数据及其说明
· 第二类数据及其说明
· 第三类数据及其说明
…
1.4 使用它的程序
描述对应不同分类的数据，所使用它的外部程序或者业务系统。
1.5 约定
描述数据库设计方面的标识约定、设计约定、特殊约定等。
2 数据定义
2.1 全局数据
主要应用范围：
作用：
数据库定义文件：
ER图文件：
2.1.1 表结构设计
2.1.1.1 表一与触发器
表一结构说明，包括：表名、表说明（内容、作用）、索引、各列属性。
各列属性，包括：列英文名、列中文名、 数据类型、长度、 列取值含义等。
触发器列表，包括：名称、说明、定义等。
2.1.1.2 表二与触发器
……
2.1.2 视图设计
2.1.2.1 视图一
定义：
用途：
2.1.2.1 视图二
……
2.1.3 存储过程设计
2.1.3.1 过程一
定义：
用途：
输入：
输出：
2.1.3.2 过程二
……
2.2 第二类数据
主要应用范围：
作用：
数据库定义文件：
ER图文件：
2.2.1 表结构设计
……
2.2.2 视图设计
……
2.1.3 存储过程设计
……
3 数据库角色定义
3.1 第一类角色
角色职能：
角色权限：
3.2 第二类角色
……
4 数据库安全设计
针对数据库安全方面的要求进行的设计，包括保密性、安全性等方面。
5 数据库备份设计
针对数据的备份要求，描述数据库的备份策略、备份和恢复的手段、备份计划、操作步骤等方面的内容。
(二) 内容审核要点：
1．本文档内容与软件设计文档、软件需求文档是否一致性；
2．所述内容是否完备；
3．本文档内容本身是否前后一致；
4．表结构描述是否清楚明确；
5．（若有）触发器描述是否清楚明确；
6．（若有）视图描述是否清楚明确；
7．（若有）存储过程描述是否清楚明确；
8．数据库角色设置是否清楚合理。
9．是否满足了安全、备份的要求。
5 软件详细设计说明
（一）文档内容要求
1 引言
1.1 编写目的
说明编写这份详细设计说明书的目的，指出预期的读者范围。
1.2 背景
说明：
a． 待开发的软件系统的名称；
b． 列出本项目的任务提出者、开发者、用户以及将运行该项软件的单位。
1.3 术语和缩略语
列出本文件中用到的专门术语的定义和缩写词的原词组。
1.4 参考资料
列出要用到的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件，包括软件需求说明书、软件概要设计说明等；
c． 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2 系统结构
以表格方式列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间的层次结构关系。并用文字说明每个程序完成的功能，以及互相之间的调用关系。
3 程序1（标识符）设计说明
从本章开始，逐个地给出各个层次中的每个程序的详细设计。以下给出的提纲是针对一般情况的。对于一个具体的模块，可能根据需要在其说明条目上有适当增减。
3.1 程序描述
给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且说明本程序的特点。
3.2 功能
说明该程序应具有的功能，可采用IPO图（即输入－处理－输出图）的形式。
3.3 性能
说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。
3.4 输入项
给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式、数量和频度、输入媒体、输入数据的来源和安全保密条件等等。
3.5 输出项
给出对每一个输出项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输出的形式、数量和频度、输出媒体、对输出图形及符号的说明、安全保密条件等等。
3.6 算法
详细说明本程序所选用的算法，具体的计算公式和计算步骤。
3.7 流程逻辑
用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程。
3.8 接口
用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式，说明与本程序相直接关联的数据结构。
3.11 限制条件
说明本程序运行中所受到的限制条件。
3.12 单元测试
说明对本程序进行单元测试的计划和方式，包括单元测试用例的设计等。
3.13 尚未解决的问题
说明在本程序的设计中尚未解决而设计者认为在软件完成之前应解决的问题。
4 程序2（标识符）设计说明
．．．．．．
（二）内容审核要点：
1．本文档内容与概要设计说明、软件需求规格说明等文档中的内容是否一致性；
2．所述内容是否完备；
3．各子程序模块描述是否清楚；
4．是否有必要的单元测试用例编制方面的考虑；
5．程序模块间关系是否清楚准确。
6 可执行程序生成说明
（一）文档内容要求
1 概述
1.1 编写目的
说明编写目的。本文档主要供开发方项目组内部使用，其目的包括：
a．便于项目组测试人员通过版本控制机制，每次生成新的目标程序在干净的环境下进行自测（包括出厂测试）；
b．便于今后源代码的交付。
1.2背景
说明软件系统的名称和作用，以及本可执行程序属于软件系统的哪一部分。
1.3 参考资料
列出所参考的文档，如需求规格说明、设计说明等。
2 工具和支撑软件要求
指出目标程序生成的工具要求，如对于使用ant 脚本生成目标程序的方式，需要ant工具的支持。
指出目标程序执行的支撑软件要求，如虚拟机、应用服务器或其它底层软件支持。
注：建议尽量提供生成脚本而不依赖于可视化开发工具来生成目标代码，以便于测试方能根据版本控制库中的源码迅速生成目标程序进行测试和回归测试。
3 源代码获取
指出从何处及如何获取源代码，包括脚本程序代码。一般情况下，在开发团队内部，源代码的获取方法和步骤与项目源代码配置管理方式相关。
4 目标程序生成步骤
详细说明目标程序生成步骤，步骤的多少与项目复杂度、所编制脚本功能强弱等因素相关。
注：不管步骤多少，整个步骤应是明确和完备的，并提供方便的清除所生成目标程序的方法。
5 目标程序的执行
说明如何运行生成的目标程序，一般包括以下内容：
。从何处获取生成的目标程序；
。执行前的准备工作，如配置文件的修改、数据库表定义/删除的脚本的执行、数据库表的初始化数据生成/清除脚本的执行等；
。软硬件运行环境的建立；
。程序的部署和执行。
（二）内容审核要点：
1．所述各目标程序生成说明文档是否涵盖项目整个软件系统；
2．所述步骤是否明确和详细；
3．是否内部有版本控制机制。
7．软件测试计划
（一）文档内容要求
1 范围
1.1 标识
本条应包含本文档及本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。
1.2 系统概述
本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的开发方、业主方、总集方、监理方等；标识当前和计划的运行现场等。
1.3 文档概述
本条应概述本文档的用途和内容，并描述与其使用有关的保密性和私密性的要求。
2 引用文档
应列出本文档引用的所有文档的编号、标题、修订版本、日期和来源。
3 术语和定义
提供此文档中用到的专门术语的定义和缩写词的原词组。
4 测试目标和测试内容
4.4 测试目标
描述本测试计划的测试目标。如完成软件的出厂测试，达到可交付验证测试的目的。
4.1 测试的功能和特性
概要说明本次需要测试的功能和特性
4.2 不测的功能和特性
说明本次不测的功能、特性及原因
4.4 测试质量目标
简要说明测试的质量目标,如：
(1)测试计划中所有测试方法和模块已经执行通过
(2)所有的测试案例已经执行过
(3)所有的重要等级Bug已经解决并由测试验证
-
应交付的测试成果文档
说明最终需要交付的测试成果文档，包括软件测试计划、软件测试说明(含测试用例)、软件测试报告、测试问题报告等。文档名和数量因具体项目而异，应确定文档责任人。
6.测试策略
6.1整体测试策略
说明基本的测试过程和策略。如测试人员在需求和设计阶段参与需求评审和设计评审、在开发完成前实施测试案例设计和测试开发，在系统开发完成之后正式执行测试等。
6.2问题等级划分
划分软件缺陷的等级分类代码。推荐的等级划分如下：
6.3 开始/中断/完成标准
6.3.1 测试启动条件
说明启动测试的条件。如对于出厂测试，已经过评审、测试人力资源已经具备、软件需求规格说明/详细设计文档/测试说明文档已经过确认、内部模块测试和组装测试已经完成等。
其中业主方、总集方、监理方交付验证测试的准入条件：
a) 软件源代码正确通过编译且为最终版本；
b) 软硬件测试平台已搭建并已配置完成；
c) 业主方具有测试所需的各种文档（纸质、电子版）；
d) 业主方获得的各种文档均与最终版本的软件相对应，且全部通过审核；
e) 承建方、监理方已完成测试并提交测试报告。
6.3.2 测试中断条件
说明测试中断的条件。例如：
１．在测试中发现A类bug，并导致后续的测试无法继续时；
２．已执行完所有的测试用例，并已报告给承建方，等待承建方在限期内改正时。
6.3.３ 测试终止条件
说明在什么条件下终止本计划所述产品交付验收证测试。如：
1. 正常终止条件：
a) 按照测试计划完成所有定义的测试用例；
b) 客观、详细地记录了软件测试过程和软件测试中发现的问题；
c) 有效完成了定位缺陷的回归测试循环；
d) 测试中未发现A、B缺陷，以及少于n个C类缺陷；
e) 提交测试报告。
- 异常终止条件
太多的A或B类缺陷以致测试无法进行或测试周期已结束。
或者针对软件规模，规定C类bug不超过n个
6.4 测试工具选择
说明需要用到的测试工具软件，应包括软件版本号。
6.5 测试流程
阐述或引用测试流程，应包括问题报告、审核、分配、跟踪、回归等各方面。测试流程与承建方内部质量管理制度和业主方的要求相关。
6.6 测试技术和方法
确定测试需要的技术或方法，如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术等；明确测试用例的设计和选择方法，针对不同类型的测试(功能测试、性能测试、容量测试、用户界面测试), 根据需要，应给出针对性的测试用例设计要求。
6.7 评价准则和方法
6.7.1 测试通过准则
定义系统测试通过准则，以下是一个测试通过准则的示例：
1． 可执行软件与需求规格说明书、设计说明书是一致的；
2． 测试覆盖率应达到100%
3． 测试用例通过率要达到95%；
4． 软件缺陷终结率达到100%
5． 系统页面风格符合规范化要求，程序代码编写以及各种命名符合规范化要求。
6． 各模块正确衔接。
7． 对异常数据应有相应的提示信息，并能安全终止异常操作。
6.7.2 对测试结果处理方法
测试结果分为通过和未通过。测试达到通过准则的要求称为“通过”，测试结果没有达到测试通过准则的称为“未通过”。说明对不同测试结果的处理方法。 - 测试项目组织与资源
7.1 参与部门和组织
说明参与测试的组织/部门
7.2 角色和职责
说明参与测试的组织/部门中各角色划分及职责。
7.3 人员和培训要求
说明参与测试的组织/部门的员及角色对应关系。以及是否需要预先进行相关培训。
7.4 关键资源
说明需要用到的关键资源 -
测试活动和进度计划
应根据测试资源和测试项目内容，分解测试活动，分配测试资源，编制测试进度计划。以下是一个进度计划的示例：
?
?
8 风险分析及应对措施
风险分析是评测项目管理的重要内容。常见的风险包括供测试的软件版本混乱、软件缺陷修改时间过长、回归不足引发新的问题、测试方和开发方对缺陷的认识存在差异等。建议以列表的方式给出识别的风险并提供针对性的缓解措施。
（二）内容审核要点：
1．测试内容是否完整，是否涵盖了测试目的、内容、方法策略、资源、进度安排等各方面；
2．测试进度安排是否合理；
3．测试资源要求是否充分；
4．测试技术和方法的选择是否可行；
5．是否包含了对测试结果评价分析标准；
6．是否包含了对测试过程的跟踪和控制规程。
8 软件测试说明
（一）文档内容要求
1 范围
1.1标识
本条应包含本文档及本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。
1.2系统概述
本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的开发方、业主方、总集方、监理方等；标识当前和计划的运行现场等。
1.3文档概述
本条应概述本文档的用途和内容，并描述与其使用有关的保密性和私密性的要求。
2 引用文件
应列出本文档引用的所有文档的编号、标题、修订版本、日期和来源。
3 术语和缩略语
提供此文档中用到的专门术语的定义和缩写词的原词组。
4 测试准备
以下按照软件测试类型（如：功能测试、性能测试、可靠性测试等）分章节编写。
每一项测试类型均应有唯一的标识号，应描述如何准备并获取测试资源，如测试环境所必须的软件、硬件、数据资源等；必要时，应描述如何准备测试程序，如开发测试接口所需的数据仿真、业务仿真程序以及测试支持软件等。
4.X （测试名称、唯一标识号）
4.X.1 设施环境要求
描述对测试场所、设施和环境的要求。（若有）分析上述差异对测试可能造成的影响。
4.X.2 硬件准备
描述对测试硬件的要求。分析硬件差异对测试可能造成的影响。
4.X.3 软件准备
描述对测试软件的要求。分析软件差异对测试可能造成的影响。
4.X.4 数据准备
描述对测试数据的要求。分析数据差异对测试可能造成的影响。
4.X.5 其它测试准备
描述对测试程序等分面的其他测试准备工作。
5 测试项分解
将需测试的内容进行层次化的分解形成测试项，并进行标识命名。对最终分解后的每个测试项，说明测试用例设计方法的具体应用、测试数据的选择依据等。测试项与具体的功能和性能要求对应，测试项还应包含对用户文档(用户手册、安装部署手册)的测试。
6 测试说明
逐层对测试项和测试用例进行标识和说明。其中，测试用例至少应包含：所属测试项、用例名称标识、用例说明、对应需求、前提和约束、执行步骤、预期结果等。
注：测试用例可采用表格方式，可作为本文档的附件另行成文，以下是对测试用例相关项的解释。
对应需求：说明测试所依据的内容来源，如软件需求规格说明书中的需求功能编号或具体条款
测试说明：简要描述测试的对象、目的和所采用的测试方法。
前提和约束：说明实施该测试用例的前提条件和约束条件，如环境条件、准备工作等。
执行步骤：编写按照执行顺序排列的一系列相对独立的步骤，每一个执行步骤应包括测试操作动作、测试程序输入或设备操作、期望的测试结果。
预期结果：期望测试结果应有具体内容(如确定的元数值、业务流程状态等)，不应是不确切的概念或笼统的描述。
7 测试用例执行顺序
应确定软件测试用例的执行顺序，从而合理安排测试执行过程，避免重复执行测试用例，提高测试工作效率。同时，通过合理的测试用例执行顺序实现对完整的业务流程的确认和验证。
（二）内容审核要点：
1．测试说明的范围与合同及其附件要求等是否一致；是否覆盖了全部软件需求；是否覆盖了全部测试需求；
2．软件测试准备是否充分；
3．软件测试分解是否合理；测试设计思路是否清晰；测试技术实现方法是否科学；
4．对接口的分析和说明是否完整、准确；对接口测试的正常和容错说明是否全面；
5．测试用例是否充分；除正常操作、正常流程、正常数据外，是否覆盖了可测试的异常情况；
6．测试用例的执行顺序是否合理；是否可覆盖必要的业务流程。
9 软件测试报告
（一）文档内容要求
1引言
1.1标识
本条应包含本文档及其所适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。
1.2系统概述
本条简述本文档适用的系统和软件的用途。应描述系统与软件的一般性质；描述系统基本功能；概述本系统或软件的开发、测试、试运行和维护的历史；标识项目的承建方、业主方、总集方、监理方等；标识系统当前和计划的运行现场；
1.3文档概述
本条应概括本文档的用途与内容，并描述与其使用有关的保密性方面的要求。
1.5引用文件
本条应列出本文档引用的所有文档的编号、标题、修订版本、日期和来源。
1.6 术语与缩略语
提供此文档中用到的专门术语的定义和缩写词的原词组。
2测试概述
2.1测试目的
描述本次测试的目的。
2.2测试内容
描述本次测试的主要内容，包括需要进行测试的功能和特性。可以引用测试计划和测试说明文档中的内容。对于出厂测试，要将用户文档的正确性测试作为测试的内容之一。
2.3测试的质量目标
描述本次测试所要达到的质量目标，如A、B类bug低于多少个，系统响应时间、系统表现达到什么目标等等。
2.4测试依据
描述本次测试的所依据的方案、文档和标准。
2.5测试环境描述
描述本次测试的软硬件环境，包括使用的服务器的软硬件环境和配置，网络和客户端环境，部署情况说明等。与生产系统环境的差异。
2.6测试时间
说明本次测试的执行时间。
2.7测试人员及工作量
说明本次测试投入的人员、工作量，以及具体每个功能子模块的人员、计划工作量、实际工作量的分配。
3测试问题记录
通过列表的方式列出测试发现的主要问题记录，包括问题编号、问题说明、对应测试用例、解决情况等。
4测试结果分析及软件评价
4.1对被测试软件的总体评价
.根据本报告中所展示的测试结果，提供对该软件的总体评价，包括遗留bug的统计与分析、软件存在的主要问题、是否达到本次测试的质量目标等。
4.2测试技术分析
分析测试技术对测试结果的影响。
4.3 测试环境的影响
对测试环境与操作环境的差异进行评估，并分析这种差异对测试结果的影响。
4.4 改进建议
针对对被测试软件还存在的问题，提出改进建议。
附录
附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。
文档中，如果定义了缺陷等级分类代码，需要在附录中给出其定义。
（二）内容审核要点：
1．是否全面、真实地反映了测试执行过程；测试记录是否完整、有效；
2．是否全面总结了测试执行过程中发现的软件问题和缺陷；
- 对问题及缺陷的判断和定位是否准确；
4． 所测试内容与测试计划是否一致。
10 软件安装部署手册
（一）文档内容要求
1 概述
1.1 编写目的
说明编写目的，指出本文档的预期读者。
1.2 背景
说明系统的项目背景，使用本系统所包含的用户。
1.2 范围
说明本文档的适用范围。
1.3 参考资料
列出所参考的文档，如其它的用户文档。
1.3 软件清单
列出所提交的软件产品的程序及其它必要的附件文件，包括可能的支持软件、第三方包、脚本文件、说明文档等，对清单中的名项给出必要的说明。
2 运行环境要求
说明系统进行安装部署时，对运行环境的要求，分为硬件环境和软件环境，包括服务器、客户端。
服务器端的运行环境，硬件方面需要指出最低参数要求，软件方面需要指出如操作系统、数据库软件、web应用服务器的名称、版本信息等。
客户端的运行环境，硬件方面需要指出最低参数要求，软件方面需要列出操作系统版本、运行依赖的浏览器版本、需要安装的驱动程序等。
3 支撑软件的安装、部署和配置
给出所有支撑软件的安装、部署和配置步聚，可以引用第三方文档。
3.x <支撑软件X>的安装、部署和配置
支撑软件X安装、部署和配置步聚。
4 应用程序的安装、部署和配置
4.x<应用程序x>的安装、部署和配置
4.x.1 安装、部署前的准备工作
说明系统进行安装部署前，需要进行的前期准备工作。如对操作系统、数据库、web应用服务器进行相应的参数设置，数据库的初始化等等。
4.x.2 部署环境概要说明
可以对部署的服务器环境，如文件目录结构，进行概要说明。
4.x.3 依赖
系统在进行安装、部署时，如果需要对外部系统运行或接口有依赖关系，在此列出。
4.x.4 安装、部署和配置步聚
列出详细的安装、部署和配置过程，包括对相关配置文件内容的修改。
5 程序的启动和停止
给出软件的启动和停止说明
（二）内容审核要点：
1．所述运行环境和支撑软件是否详细完备；
2．部署前的准备工作是否详细完备；
3．安装过程是否详细易懂。
11源代码交付说明
（一）文档内容要求
1 概述
1.1 背景
说明系统的项目背景，本系统的使用和运维单位等。
1.2 范围
说明本文档的适用范围。
2 源代码交付清单
以表格的形式，列出所提交的源代码光盘中所有的文件目录结构，对各目录和子目录加以说明。对主要源代码程序加以说明。对其它必要的附件（包括第三方包、类库、配置文件、程序的帮助说明文档等）也要加以说明。
3 编译和打包的说明
3.1编译环境和工具要求
如果需要，对编译环境和所需要工具进行简要说明。
3.2 编译和打包步聚
说明对源代码进行编译和打包的详细步聚，要能根据这些步骤生成可用的目标程序。尽量使用脚本方式生成目标程序。
3.3 生成物说明
对编译生成的执行程序进行简要说明。
（二）内容审核要点：
1．交付清单是否详细完备；
2．说明文字是否明确易懂；
3．交付物版本是否和实际系统的程序版本一致（能根据本文档生成与实际生产系统一致的程序）；
12 系统上线部署方案
（一）文档内容要求
1 概述
1.1 编写目的
说明编写目的，指出预期的读者范围。
1.2背景
简要描述此次上线部署的背景。
1.3 参考资料
列出所参考的文档，如安装部署手册等。
2 工作内容
说明本次上线部署的工作内容。即要做哪几件事。
3 部署环境
3.1部署结构
以部署结构图的形式描述本软件系统各部件的上线部署结构。对部署部件、服务器、网络等情况加以必要的说明。
3.2软件环境描述
明确描述本次部署的软件环境。包括操作系统、数据库、JDK、中间件等系统软件及版本信息。对于尚未明确需要协调的部分要加以说明。
3.3硬件环境描述
明确描述本次部署的硬件支撑环境。对于尚未明确需要协调的部分要加以说明。
4 详细步骤
详细说明本次部署要做的各项工作的执行步骤（需要时可以引用安装部署手册中的内容）。本章是该文档的重点，各步骤必须具体明确，具有可操作性。
5 人员和进度安排
列出本次的人员组织以及详细的进度安排。
6 部署测试
说明系统上线部署时需要进行的必要的测试验证工作内容。
7 部署不成功的处理
说明部署不成功的处理措施。如果是在生产系统上替代已有系统，则必须提供完善的应对措施。
（二）内容审核要点：
1．部署目标和工作内容是否明确；
2．部署环境描述是否清楚；
3．任务是否适当分解，人员是否落实，进度是否明确。
4．所述步骤是否具体并具有可操作性；
4．部署测试内容是否能对本次部署是否成功能起到验证作用。
13 系统上线部署实施报告
（一）文档内容要求
1 概述
1.1 编写目的
说明编写目的，指出预期的读者范围。
1.2背景
简要描述此次上线部署的背景。
1.3 参考资料
列出所参考的文档，如安装部署手册等。
2 工作内容
说明本次上线部署的工作内容。即要做哪几件事。
3 实际完成情况
对照工作内容，详细说明本次实际部署过程和工作任务完成情况。
4 部署测试情况
详细说明本次部署测试情况，测试内容是否都获通过。
5遗留工作和待解决问题
如果有遗留工作或问题，需要在此部分列出。
6 签字栏
本报告作为验收的依据，需要相关方的签字。应留有签字栏。
（二）内容审核要点：
1．任务描述是否明确；
2．部署实际完成情况是否描述清楚；
3．部署测试情况是否描述清楚；
2．部署部署过程是否与实际情况一致。
14 软件终验测试方案
(一) 文档内容要求
１．测试目的
终验测试是项目终验的组成部分，用于各方现场验证系统各功能可用，试运行中发现的问题是否已经解决。
２．测试对象
描述所测试的软件系统名、版本等信息
３．测试方式
由业主方、承建方、监理方、总集方代表在用户现场，依据本方案进行测试，并记录测试结果，时间以半天到一天为宜。测试结束后，现场编制终验测试报告并由各方签字确认。
４．测试通过准则
本测试方案中所列所有测试项均已通过，则终验测试通过，否则为不通过。
5．功能测试
４.1 功能名1
以表格方式列出子功能、测试方法、是否通过、备注
4.2 功能名2
。。。
6．试运行期间问题解决情况测试
以表格方式列出问题、问题描述、测试方法、是否通过、备注
(二)内容审核要点：
略
15 软件终验测试报告
(一) 文档内容要求
１．测试目的
终验测试是项目终验的组成部分，用于各方现场验证系统各功能可用，试运行中发现的问题是否已经解决。
２．测试对象
描述所测试的软件系统名、版本等信息
３．测试方式
由业主方、承建方、监理方、总集方代表在用户现场，依据本方案进行测试，并记录测试结果，时间以半天到一天为宜。测试结束后，现场编制终验测试报告并由各方签字确认。
４．测试通过准则
终验测试方案中所列所有测试项均已通过，则终验测试通过，否则为不通过。
５．测试时间
说明实施测试的时间
６．测试地点
说明实施测试的地点
７．测试参与人员
说明参与终验测试的各方人员，要说明所属单位
８．功能测试结果记录
根据终验测试方案，以表格的方式列出各项所测功能是否通过
９．问题解决情况记录
根据终验测试方案，以表格的方式列出各项所测问题是否全部解决
10．测试结论
给出终验测试是否通过的结论。
(二)内容审核要点：
略
附：关于接口描述的文档内容要求
1、概述
1.1、接口的概念
在应用软件系统中，接口是程序和系统与外界交互的窗口。本文中所阐述的接口，包括：
- 应用软件系统提供软件功能供外部软件程序调用；
- 应用软件系统调用外部系统提供的软件功能；
- 应用软件系统依据应用级别的交互协议与外系统进行功能和数据的交换；
- 应用软件系统通过公用文件目录或数据库与外部系统交换信息。
此处中所阐述的接口不包括：
- 应用软件系统内部功能模块之间的接口调用；
- 应用软件系统提供的人机交互界面。
1.2、接口处理策略
xxxxxxxxxxx是一个庞大的由众多应用子系统构成的复杂分布式系统。各应用子系统之间存在众多的软件接口关系。
在xxxxxxxxxxx中，我们采用SOA的体系架构来解决各应用子系统之间、应用子系统与外部系统之间的接口问题。通过基于ESB服务总线技术的应用支撑平台来发布和管理应用软件系统对外提供公用服务。在这里，服务系指精确定义、封装完善、独立于其他服务所处环境和状态的软件功能。接口服务系指以服务的方式提供的接口实现。
通过支撑平台，各业务子系统接口之间的点对点关系，变成了各业务子系统接口与支撑平台的关系，从而简化了系统间的逻辑关系，应用支撑平台是各业务子系统相互连接的中介和纽带。各业务子系统之间在进行服务请求和服务调用时所需的一些附加工作，如通信协议的转换、路由、消息格式转换、安全性保证等，也可以由应用支撑平台来提供支持。此外，应用支撑平台提供适配器方式以支持文件同步、数据库同步、JMS、FTP等,应用支持平台还提供定制适配器功能接入特殊的外部系统。
通过应用支持平台发布公用服务，将有利于接口服务的复用，以及接口服务的维护和管理。
1.3、接口文档规范的必要性
xxxxxxxxxxx建设过程中，各应用软件系统的接口定义、实现、发布和管理是处理好接口问题的四个关键环节，他们贯穿在软件生命周期的全过程。为了保证在这些环节对应用软件系统之间的接口问题进行有效的处理，保证接口的良好定义、合理实现、受控发布和方便管理，有必要对相关技术文档提出规范化要求。
涉及接口定义的技术文档主要有业务需求说明书、软件需求规格说明书；涉及接口实现的技术文档主要有软件概要设计说明书、软件详细设计说明书、用户手册；涉及接口服务发布和管理的技术文档包括接口服务发布和管理规范等。
2、接口定义的文档规范要求
2.1、业务需求说明书中的接口描述
在xxxxxxxxxxx中，业务需求说明书由业主方任命的子项目组负责编制。业务需求说明书中有关接口描述的要求：
1． 宜有专门章节阐述子项目拟分包系统与其它子项目系统及外部系统之间的接口关系；
2． 在描述本系统与外部某系统接口关系时，宜：
- 具体阐明本系统的哪项或哪些业务功能与所述外部系统存在接口关系；
- 阐明接口的类型，如向外系统提供数据、从外系统获取数据、对外系统提供功能服务、向外系统请求某项功能服务；
- 对所述接口作必要的文字解释。
2.2、软件需求规格说明书中的接口描述
软件需求规格说明书系由承建方在业务需求说明书的基础上，在系统功能、性能、外部限制条件等方面的进一步明确和细化，作为系统设计、实现、测试的依据。是涉及接口定义的重要文档。
软件需求规格说明书中有关接口定义和描述的要求如下：
1． 软件需求规格说明书中有关与外部系统接口定义的范围应涵盖业务需求说明书中有关接口的描述，并补充业务需求书中遗漏的接口内容；
2． 本系统作为接口对外提供的软件功能，应在软件需求规格说明书中明确阐明该功能。包括接口功能编号、名称、性质（功能服务、数据交换、文件交换等）、接口功能的各输入参数及数据类型，返回的结果数据类型等；
3． 如果接口是作为某种信息交互协议（如Z39.50）的服务端提供的功能，要求阐明支持的协议版本以及是否完全支持该协议，如果不完全支持，要明确列举支持或不支持的功能；
4． 如果接口是某种信息交互协议（如Z39.50）的客户端，且外部系统提供的相应协议服务端功能是本系统相关功能实现的必要条件，须将对外部系统的相关接口实现要求列入软件需求规格说明书中的限制条件部分；
5． 如果系统功能涉及到要使用或访问外部系统提供的功能，须将其列入需求规格说明书中限制条件部分。
2．3 接口定义的变更
如果在软件需求评审通过后的实施过程中，原定义或描述的接口发生了变化，须通过变更流程修改软件需求规格说明书；或编制需求文档的补充材料，与原需求规格说明书一起，作为测试和验收的依据。
3、接口实现的文档规范要求
3.1、软件设计说明书中的接口服务实现描述
在软件概要设计说明书中，有关接口实现的要求如下：
1． 须覆盖软件需求说明书中所述对外提供接口功能；
2． 确定接口的实现策略。如采用Web Service、EJB、通过网络端口连接对外提供服务、文件目录或数据库同步等。
3． 对外提供的接口功能，需要进行形式化描述，如果不能确定在软件概要设计说明书完全进行接口功能的形式化表述，应在该说明书中明示并在详细设计说明书中给出以供编码实现之用。
3．2 用户文档中的接口使用描述
在设计说明书中描述的所有对外提供的接口功能，最终都要落实在用户文档中。具体的用户文档名称，取决于项目合同和软件开发计划中对最终交付文件的规定。如用户使用手册、用户参考手册、用户技术手册等。
各应用软件系统通过该系统的用户文档对外正式公布本系统对外的接口服务的功能和调用方式。
?