文档介绍：计算机软件文档编制规范
ＧＢ／Ｔ８５６７新老版本的主要差异
５）软件移交计划
　６）运行概念说明
　７）系统／子系统需求规格说明
　８）接口需求规格说明
　９）系统／子系统设计（结构设计）说明
１０）接口设计说明
１１）软件需求新的审核过程。
文档开发
按文档计划规定进行文档开发。通常，在进行文档开发前，要规定文档的格式（风格）。在软件的开发和管理过程中需要那些文档，每种文档的规范在下面说明。
评审
概述
本节规定文档评审的要求和相关活动。本节主要以用户文档的评审为例说明。对于开发文档的评审，由供方组织和实施。而批准由开发组织的上级技术机构实施。更要着重经常性的、非正式的注重实效的评审。不是要追求形式。
用户文档的评审应由需方实现，包括当需要时与文档管理者讨论。
l  评审的目的是保证提交的材料是完整的和正确的并满足了在合同和文档计划中定义的需方的需要。
评审宜由合适的有资格的人员执行，这些人员被授权请求变更和批准文档的内容。
l  需方宜限止评审人员数为评审功能所必需的那些。
需方在批准每个用户文档草案之前，应保证文档的安全和合法。
为评审交付的文档应包括从文档管理者来的说明书，说明评审的目的和评审员的职责。
l  注1：在需方和文档管理者之间在整个开发过程期间维持良好的通信会提高文档的质量并利于评审成功。这宜包括非正式的讨论和尽早地提供样板或初始材料给需方。
l  注2：在要求的变更超出了合同和文档计划的范围时，需要变更合同。
l  注3：评审过程不免除文档管理者，他们的责任是试图尽可能保证文档的精确和完整。
l  注4：从评审的结果而来的需方的评论结果宜用或是加上标记的草案或用有适当的参考的方式写评论。需方宜保持变更的副本为了与下一草案相比较。评论应使文档开发人员能实现所要求的变更而不需要评审人员的进一步解释。
l  注5：对于大的、复杂的系统或正在写文档时系统仍在开发，可能需要多于两次草案和一次校样。在这样情况下，最多的草案数宜在需方和文档管理者之间同意并在文档计划中规定。
文档计划评审
此评审的目的应保证文档计划定义的文档，当完成时，既满足开发过程的需要也满足需方在合同中规定的的文档目标。需方同意文档计划，是同意在计划中定义的用户文档的所有可交付的特征。
l  注：需方宜放注意至在内容的草案表中展示的文档的结构、完整性和可用性。只要适当，文档计划宜在第一个草案开始工作之前评审和批准。
第一个草案评审
第一个草案应包含如在文档计划中描述的文档主体，加上内容表，附录和词汇。在使用自动索引工具处，生成的索引包含位置参照。标点符号、风格和版面应如在文档计划中描述的。
文档的第一个草案的评审目的是核查文档的技术正确性和完整性，以保证草案满足文档计划的目标。标点符号、风格和版面应如在文档计划中定义的。
在批准第一个草案中，除了要求的变更外，评审批准技术正确性、结构清楚性和文档的完整性。
l 注1：第一个草案宜在交付前编辑。这有两个理由：
a）这保证评审者不分心于改正印刷的和版面的错误；
b）保证由编辑过程引起的任何技术错误被评审者捕获。
l 注2：草案应针对在文档计划中批准的目标、读者定义、内容表和其他特征进行评审。在带有评论的第一个草案返回前，宜确认，若草案完全改正了，将满足文档计划的要求。
第二个草案评审
第二个草案应包在第一个草案评审中同意的所有变更且应以尽可能接近最后的形式包括在文档计划中定义的可交付的内容。
此评审的目的是核查在第一个草案中的内容已经正确实现。
在第二个草案的批准中，除了草案的物理形式外，批准文档的所有方面。草案的物理形式可能与可交付的不精确相同。
l 注：在批准第二个草案前，宜确认草案（包含评审对草案的评论）已经准备好批准。
六、文档编制要求
软件生存周期与各种文档的编制
在计算机软件的生存周期中，一般地说，应该产生以下一些基本文档。
可行性分析（研究）报告；
软件（或项目）开发计划；
软件需求规格说明；
接口需求规格说明；
系统／子系统设计（结构设计）说明；
软件（结构）设计说明；
接口设计说明；
数据库（顶层）设计说明；
（软件）用户手册；
操作手册；
测试计划；
测试报告；
软件配置管理计划；
软件质量保证计划；
开发进度月报；
项目开发总结报告；
软件产品规格说明；
软件版本说明等。
本标准将给出这些文