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