GB/T8567-2006 本标准将给出这些文档的编制规范，同时，本标准也是这些文档的编写质量的检验准则。一般地 说，一个软件总是一个计算机系统（包括硬件、固件和软件）的组成部分。鉴于计算机系统的多样性，本 标准一般不涉及整个系统开发中的文档编制问题，本标推仅仅是软件开发过程中的文档编制指南。 对于面向对象的软件开发，其文档编制要求，参见附录A。 对于使用文档的人员而言，他们所关心的文件的种类随他们所承担的工作而异。 管理人员：可行性分析（研究）报告， 项目开发计划， 软件配置管理计划， 软件质量保证计划， 开发进度月报， 项目开发总结报告； 开发人员：可行性分析（研究）报告， 项目开发计划， 软件需求规格说明， 接口需求规格说明， 软件（结构）设计说明， 接口设计说明书， 数据库（顶层）设计说明， 测试计划， 测试报告： 维护人员：软件需求规格说明， 接口需求规格说明， 软件（结构）设计说明， 测试报告， 用 户：软件产品规格说明， 软件版本说明， 用户手册， 操作手册。 本标推规定了在软件开发过程中文档编制的要求，这些文档从使用的角度可分为用户文档和开发 文档两大类。其中，用户文档必须交给用户。用户应该得到的文档的种类和规模由供应者与用户之间 签订的合同规定。 如前所述，软件，从出现一个构思之日起，经过软件开发成功投入使用，直到最后决定停止使用并被 另一项软件代替之时止，被认为是该软件的一个生存周期，一般地说这个软件生存周期可以分成以下6 个阶段： a)可行性与计划研究阶段： b)需求分析阶段； c)设计阶段； d) 实现阶段： e)测试阶段； )运行与维护阶段。 在可行性分析（研究）与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投 资一收益分析、制订开发计划，并完成可行性分析报告、开发计划等文档。 在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性 11
GB/T8567一2006 能需求和设计约束，确定对文档编制的要求，作为本阶段工作的结果，一般地说软件需求规格说明（也称 为：软件需求说明、软件规格说明)、数据要求说明和初步的用户手册应该编写出来。 在设计阶段内，系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计， 分析每个设计能履行的功能并进行相互比较，最后确定一个设计，包括该软件的结构、模块（或CSCI)的 划分、功能的分配，以及处理流程。在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段 和详细设计阶段两个步骤。在一般情况下，应完成的文档包括：结构设计说明、详细设计说明和测试计 划初稿。 在实现阶段内，要完成源程序的编码、编译（或汇编）和排错调试得到无语法错的程序清单，要开始 编写进度日报、周报和月报（是否要有日报或周报，取决于项目的重要性和规模），并且要完成用户手册、 操作手册等面向用户的文档的编写工作，还要完成测试计划的编制。 在测试阶段：该程序将被全面地测试，已编制的文档将被检查审阅。一般要完成测试分析报告。作 为开发工作的结束，所生产的程序、文档以及开发工作本身将逐项被评价，最后写出项目开发总结报告。 在整个开发过程中（即前五个阶段中），开发集体要按月编写开发进度月报。 在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能的扩 充和删改、更新和升级。 6.2文档编制中的考虑因素 文档编制是开发过程的有机组成部分，也是一个不断努力的工作过程。是一个从形成最初轮廓、经 反复检查和修改，直至程序和文档正式交付使用的完整过程。其中每一步都要求工作人员做出很大努 力。要保证文档编制的质量，要体现每个开发项目的特点，也要注意不要花太多的人力。为此编制中要 考虑如下各项因素。 6.2.1文档的读者 每一种文档都具有特定的读者。这些读者包括个人或小组、软件开发单位的成员或社会上的公众、 从事软件工作的技术人员、管理人员或领导干部。他们期待着使用这些文档的内容来进行工作，例如设 计，编写程序、测试、使用、维护或进行计划管理。因此这些文档的作者必须了解自己的读者。这些文档 的编写必须注意适应自己的特定读者的水平、特点和要求。 6.2.2重复性 本标准中列出的文档编制规范的内容要求中，显然存在某些重复。较明显的重复有两类。引言是 每一种文档都要包含的内容，以向读者提供总的梗概。第二类明显的重复是各种文档中的说明部分，如 对功能性能的说明；对输入、输出的描述：系统中包含的设备等。这是为了方便每种文档各自的读者，每 种文档应该自成体系，尽量避免读一种文档时又不得不去参考另一种文档。当然，在每一种文档里，有 关引言、说明等同其他文档相重复的部分，在行文上、在所用的术语上、在详细的程度上，还是应该有一 些差别以适应各种文档的不同读者的需要。 6.2.3,灵活性 鉴于软件开发是具有创造性的脑力劳动，也鉴于不同软件在规模上和复杂程度上差别极大，在文档 编制工作中允许一定的灵活性。这种灵活性如下所述。 a)应编制的文档种类 尽管本标准认为在一般情况下，一项软件的开发过程中，应产生如上所述的各种文档，然而针对一 项具体的软件开发项目，有时不必编制这么多的文档，可以把几种文档合并成一种。一般地说，当项目 的规模、复杂性和失敗风险增大时，文档编制的范围，管理手续和详细程度将随之增加，反之，则可适当 减少。为了恰当地掌握这种灵活性，本标准要求贯彻分工负责的原则，这意味着： 1)一个软件开发单位的领导机构应该根据本单位经营承包的应用软件的专业领域和本单位的管 理能力，制定一个对文档编制要求的实施规定，主要是：在不同的条件下，应该形成哪些文档？ 这些文档的详细程度？该开发单位的每一个项目负责人，必须认真执行这个实施规定。 12
GB/T8567-2006 2)对于一个具体的应用软件项目，项目负贵人应根据上述实施规定，确定一个文档编制计划（可 以包含在软件开发计划中)，其中包括： (1)应该编制哪几种文档，详细程度如何？ (2)各个文档的编制负责人和进度要求； (3)审查、批准的负责人和时间进度安排： (4)在开发时间内，各文档的维护、修改和管理的负责人，以及批准手续。 每项工作必须落实到人。这个文件编制计划是整个开发计划的重要组成部分。 3)有关的设计人员则必须严格执行这个文档编制计划。 b)文档的详细程度 从同一份提纲起草的文件的篇幅大小往往不同，可以少到几页，也可以长达几百页。对于这种差 别，本标准是允许的。此详细程度取决于任务的规模、复杂性和项目负责人对该软件的开发过程及运行 环境所需要的详细程度的判断。 c)文档的扩展 当被开发系统的规模非常大〈例如源码超过一百万行〉时，一种文档可以分成几卷编写，可以按其中 每一个系统分别编制；也可以按内容划分成多卷，例如： 项目开发计划可能包括：质量保证计划， 配置管理计划， 用户培训计划， 安装实施计划： 系统设计说明可分写成：系统设计说明， 子系统设计说明； 程序设计说明可分写成：程序设计说明， 接口设计说明， 版本说明； 操作手册可分写成：操作手册， 安装实施过程； 测试计划可分写成：测试计划， 测试设计说明， 测试规程， 测试用例； 测试分析报告可分写成：综合测试报告， 验收测试报告； 项目开发总结报告亦可分写成项目开发总结报告和资源环境统计。 d)章、条的扩张与缩并 在软件文档中，一般宜使用本标准提供的章、条标题。但所有的条都可以扩展，可以进一步细分，以 适应实际需要。反之如果章条中的有些细节并非必需，也可以根据实际情况缩并。此时章条的编号应 相应地变更。 e)程序设计的表现形式 本标准对于程序的设计表现形式并未作出规定或限制，可以使用流程图的形式，判定表的形式，也 可以使用其他表现形式，如程序设计语言(PDL)、问题分析图(PALb)等。 )文档的表现形式 本标准对于文档的表现形式亦未作出规定或限制。可以使用自然语言，也可以使用形式化语言。 也可以使用各种图、表。 13
GB/T8567-2006 g)文档的其他种类 当本标准中规定的文档种类尚不能满足某些应用部门的特殊需要时，他们可以建立一些特殊的文 档种类要求，例如软件质量保证计划、软件配置管理计划等，这些要求可以包含在本单位的文件编制实 施规定中。 7文档编制格式 7.1可行性分析（研究）报告(FAR) 说明： 1.《可行性分析（研究）报告》(FAR)是项目初期策划的结果，它分析了项目的要求、目标和环 境；提出了几种可供选择的方案；并从技术、经济和法律各方面进行了可行性分析。可作为 项目决策的依据。 2.FAR也可以作为项目建议书、投标书等文件的基础。 可行性分析报告的正文格式如下： 引言 本章分为以下几条。 1.1标识 本条应包含本文档适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本 号和发行号。 1.2背最 说明项目在什么条件下提出，提出者的要求、目标、实现环境和限制条件。 1.3项目概述 本条应简述本文档适用的项目和软件的用途，它应描述项目和软件的一般特性；概述项目开发、 运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现 场；列出其他有关的文档。 1.4文档概述 本条应概述本文档的用途和内容，并描述与其使用有关的保密性和私密性的要求。 2引用文件 本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常 的供货渠道获得的所有文档的来源。 3可行性分析的前提 3.1项目的要求 3.2项目的目标 3.3项目的环境、条件、假定和限制 3.4进行可行性分析的方法 4可选的方案 4.1原有方案的优缺点、局限性及存在的问题 4.2可重用的系统，与要求之间的差距 14
GB/T8567-2006 4.3可选择的系统方案1 4.4可选择的系统方案2 .000 4.5选择最终方案的准则 5所建议的系统 5.1对所建议的系统的说明 5.2数据流程和处理流程 5.3与原系统的比较（若有原系统） 5.4影响（或要求） 5.4.1设备 5.4.2软件 5.4.3运行 5.4.4开发 5.4.5环境 5.4.6经费 5.5局限性 6经济可行性（成本一效益分析） 6.1投资 包括基本建设投资（如开发环境、设备、软件和资料等），其他一次性和非一次性投资（如技术管 理费、培训费、管理费、人员工资、奖金和差旅费等)。 6.2预期的经济效益 6.2.1一次性收益 6.2.2非一次性收益 6.2.3不可定量的收益 6.2.4收益/投资比 6.2.5投资回收周期 6.3市场预测 7技术可行性（技术风险评价） 本公司现有资源（如人员、环境、设备和技术条件等）能否满足此工程和项目实施要求，若不满 足，应考虑补救措施（如需要分承包方参与、增加人员、投资和设备等），涉及经济问题应进行投资、成 本和效益可行性分析，最后确定此工程和项目是否具备技术可行性。 8法律可行性 系统开发可能导致的侵权、违法和责任。 9用户使用可行性 用户单位的行政管理和工作制度；使用人员的素质和培训要求。 10其他与项目有关的问题 未来可能的变化