GBT8567-2006-计算机软件文档编制规范.pdf

'ICS35.080L77中华人民共和国国家标准GB/T8567-2006代替GB/T8567-1988计算机软件文档编制规范Specificationforcomputersoftwaredocumentation2006-03-14发布2006-07-01实施中华人民共和国国家质量监督检验检疫总局发布中国国家标准化管理委员会 目次前言7．12数据需求说明(DRD)1范围7．13软件(结构)设计说明(SDD)2规范性引用文件7．14数据库(顶层)设计说明(DBDD)3术语和定义7．15软件测试说明(STD)4缩略语7．16软件测试报告(STR)5文档过程7．17软件配置管理计划(SCMP)5．1概述7．18软件质量保证计划(SQAP)5．2源材料准备7．19开发进度月报(DPMR)5．3文档计划7．20项目开发总结报告(PDSR)5．4文档开发7．21软件产品规格说明(SPS)5．5评审7．22软件版本说明(SVD)5．6与其他公司的文档开发子合同7．23软件用户手册(SUM)6文档编制要求7．24计算机操作手册(COM)6．1软件生存周期与各种文档的编制7．25计算机编程手册(CPM)6．2文档编制中的考虑因素附录A(规范性附录)面向对象软件的文档编制7文档编制格式A．1综述7．1可行性分析(研究)报告(FAR)A．2总体说明文档7．2软件开发计划(SDP)A．3用况图文档7．3软件测试计划(STP)A．4类图文档7．4软件安装计划(SIP)A．5顺序图文档7．5软件移交计划(STrP)A．6协作图文档7．6运行概念说明(OCD)A．7状态图文档7．7系统/子系统需求规格说明(SSS)A．8活动图文档7．8接口需求规格说明(IRS)A．9构件图文档7．9系统/子系统设计(结构设计)说明(SSDD)A．10部署图文档7．10接口设计说明(IDD)A．11包图文档7．11软件需求规格说明(SRS)参考文献 GB/T8567-2006《计算机软件文档编制规范》前言本标准是GB/T8567—1988《计算机软件产品开发文件编制指南》的修订版，并改名为《计算机软件文档编制规范》。本标准从实施之日起代替GB/T8567—1988。本标准与GB/T8567—1988相比，主要变化如下：a)本标准增加了文档编写过程。其内容参考了ISO/IECJTCl/SC7N21061999/04/15《软件工程——用户文档过程》。b)本标准主要从软件开发与管理的角度，规定相应的文档及规范。其内容依据GB/T8566—2001《软件生存周期过程》。c)在编写本标准时，综合了在软件开发与管理中的经验及中软网络技术股份有限公司有关CMM中拟订的一些文档规范。d)本标准与SJ20778—2000《软件开发与文档编制》很好地链接。e)本标准在规定软件需求规格说明、软件测试文件、软件质量保证计划与软件配置管理计划等文档时，既依据相应的国标，又根据发展与实践经验作了相应的扩展。f)本标准把SJ/T11291—2003《面向对象的软件系统建模规范第3部分：文档编制》中的文档编制规范作为本标准的规范性附录。本标准的附录A是规范性附录。本标准由中华人民共和国信息产业部提出。本标准由信息产业部电子工业标准化研究所归口。本标准起草单位：中软网络技术股份有限公司、信息产业部电子工业标准化研究所、北京联想软件有限公司、用友软件股份有限公司。本标准主要起草人；周明德、冯惠、韩乃平、欧阳春生、殷树勋、黄万镒、强学锋、韩振江、邓适宜。 GB/T8567-2006《计算机软件文档编制规范》计算机软件文档编制规范1范围本标准根据GB/T8566—2001《信息技术软件生存周期过程》的规定，主要对软件的开发过程和管理过程应编制的主要文档及其编制的内容、格式规定了基本要求。本标准原则上适用于所有类型的软件产品的开发过程和管理过程。使用者可根据实际情况对本标准进行适当剪裁(可剪裁所需的文档类型，也可对规范的内容作适当裁剪)。软件文档从使用的角度大致可分为软件的用户需要的用户文档和开发方在开发过程中使用的内部文档(开发文档)两类。供方应提供的文档的类型和规模，由软件的需方和供方在合同中规定。2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB/T8566—2001信息技术软件生存周期过程(idtISO/IEC：12207：1995)GB/T11457—2006软件工程术语3术语和定义GB/T11457—2006确立的以及下列术语和定义适用于本标准。3.1验收acceptance需方授权代表的一项活动，通过该活动，需方接受履行合同的部分或全部的软件产品的所有权。3.2需方acquinr为自己或为另一个组织采购软件产品的组织。3.3批准approval需方的授权代表或开发方的上级组织对开发方的项目计划、设计或其他方面表示满意并可以作为下一阶段工作基础而签署的书面文件。3.4体系结构architecture一个系统或CSCI(ComputerSoftwareConfigurationItem-计算机软件配置项)的组织结构，标明它的组成，这些组成的接口和它们之间的操作概念。3.5相关开发方associatedeveloper一个既不是主承包方也不是开发方的分承包方的组织，但它在同一个或相关系统或项目中承担开发工作。3.6行为设计behavioraldesign从用户观点出发，对整个系统或CScI的行为进行的设计，它只考虑满足用户需求而不考虑系统或CSCI的内部实现。这种设计与体系结构设计不同，后者要标明系统或CSCI的内部部件，并有这些部件的详细设计。3.7构建版；开发阶段build(1)软件的一个版本，它满足完整的软件所要满足的全部需求的一个特定的子集。(2)开发满足特定需求子集的软件版本所经历的时间。注：术语一开发阶段”和一版本”之间的关系依赖于开发方：例如，可以通过几个版本来实现一个开发阶段，一个开发阶段也可以发行几个并行的版本(如发往不同的地点)，或者将它们用作为同义词。3.8计算机数据库computerdatabase见3.14数据库。3.9计算机硬件computerhardware能接收和存储计算机数据的，对计算机数据执行一系列系统性的操作的，或能产生控制输出的设备。这类设备能实现基本的解释、计算、通信、控制或其他逻辑功能。3.10计算机程序computerprogram能使计算机硬件实现计算或控制功能的计算机指令和数据定义的集合。3.11计算机软件computersoftware GB/T8567-2006《计算机软件文档编制规范》见3.32软件。3.12计算机软件配置项computersoftwareconfigurationitem(CSCI)满足最终使用功能的软件集合，而且它由需方指定进行单独的配置管理。CSCI应从下列诸因素中进行折衷选择：软件功能、规模、宿主机或目标计算机、开发方、支持概念、重用计划、关键性、接口考虑、是否需要单独编写文档和控制以及其他因素。3.13配置项configurationitem能满足最终使用功能的硬件集合、软件集合或者软、硬件两者的集合，且由需方指定进行单独的配置管理。3.14数据库database以一种能被用户或计算机程序通过一个数据库管理系统进行访问的方式，存储在一个或多个计算机文件中的相关数据的集合。3.15数据库管理系统databasemanagementsystem是一整套计算机程序，它提供为建立、修改、使用和完整性维护一个数据库所需的功能。3.16可交付的软件产品deliverablesoftwareproduct合同要求交付给需方或其他指定的接受方的软件产品。3.17设计design开发方为响应一定的需求而对一个系统或CSCI选取的一些性能/规格。这些特性中有些是与需GB/T8567-2006求相匹配的：有一些是需求的精细化，如为了响应显示错误信息这一需求而定义所有的错误信息；有一些则是与实现有关的，如为满足需求，决定选用哪些软件配置项和逻辑。3.18开发方developer开发软件产品的组织(“开发”包括新的软件开发、修改、重用、再工程、维护或产生软件产品的任何其他活动)。开发方可以是一个承制方或者政府机构。3.19文档/文档编制document/documentation能供人或机器阅读的，一般具有永久性的一套资料(不管它们记录在什么媒体上)。3.20评价evaluation确定一个项或一个活动是否满足指定准则的过程。3.21固件firmware硬件设备和以只读软件的形式驻留在硬件设备上的计算机指令和/或计算机数据的组合。3.22硬件配置项hardwareconfigurationitem(HWCI)满足最终使用功能并由需方指定进行单独配置管理的一套硬件。3.23独立验证与确认independentverificationandvalidation(IV＆V)由一个机构对软件产品和活动作系统的评估，这个机构不负责该产品的开发或被评估的活动。IV＆V不在本标准的范围内。3.24接口interface在软件开发中，两个或多个实体(如cscI—cscIcscI—HWC：ICSCI一用户，或软件配置项一软件配置项)之间的关系。这些实体依据这种关系共享、提供或交换数据。接口并不是CSCI、软件配置项或其他的系统部件；接口只是这些实体间的一种关系。3.25联合评审jointreview由需方和开发方双方代表参加的对项目状态、软件产品和/或项目中的问题进行检查和讨论的活动或会议。3.26非交付的软件产品Non-deliverablesoftwaerproduct不是合同中要求交付给需方或其他指定接受方的软件产品。3.27过程process为实现某个既定目的而进行的一组有组织的活动，例如，软件开发过程。3.28合格性测试qualificationtesting为了向需方表明一个CSCI或系统满足其指定的需求而进行的测试。3.29再工程reengineering为了以一种新的形式重组一个现有的系统而对其进行检查和改造的过程。再工程可包括逆向工程(分析一 GB/T8567-2006《计算机软件文档编制规范》个系统并产生更高一级的抽象来表示它，如从代码到设计)、重构(在同一个抽象级上把系统从一种表示形式转换到另一种表示形式)、重编文档(分析一个系统并产生用户文档式支持文档)、正向工程(从现有的系统的软件产品结合新的需求，产生新系统)、重定目标系统(对系统进行转换以便将其安装到不同的目标系统上)和翻译(将源码从一种语言转换到另一种语言或者从一种语言的某个版本转换成另一种版本)。3.30需求requirement(1)为了使需方能够接受一个系统或CSCI所必需具备的特性。(2)本标准或合同中规定的必须遵守的陈述。3.31可重用的软件产品reusablesoftwareproduct为一个用途开发但还具有别的用途的软件产品，或者专门为了用于多个项目而开发的软件产品，或者在一个项目中有多种作用的软件产品。例子包括(但不限于)上市的商用软件产品，需方已装备的软件产品，重用库中的软件产品和开发方现存的软件产品。每一次使用可以包括这些软件产品的全部或部分，也可以涉及对它的修改。这个术语可以应用于任何软件产品(例如需求，体系结构等)而不只限于软件本身。3.32软件software计算机程序和计算机数据库。注：虽然有些软件的定义中包括文档，本标准把这个定义只限于计算机程序和计算机数据库。3.33软件开发softwaredevelopment产生软件产品的一整套活动。软件开发可以包括新开发、修改、重用、再工程、维护或者任何会产生软件产品的其他活动。3.34软件开发文件softwaredevelopmentfile(SDF)与特定软件实体开发有关的资料库。其内容一般包括(直接的或引用的)有关需求分忻、设计和实现的考虑、原理和约束条件；开发方内部的测试资料；进度和状态资料。3.35软件开发库softwaredevelopmentlibrary(SDL)一组受控的软件、文档、其他中间的和最终的软件产品，以及相关的用以促进软件的有序开发和后续支持的工具和方法。3.36软件开发过程softwaredevelopmentprocess为了把用户的需求转换成软件产品而进行的一系列有组织的活动。3.37软件工程softwareengineering一般情况下，它是软件开发的同义词。在本标准中，软件工程是软件开发的一个子集，它包含除了合格性测试之外的全部活动。本标准之所以加以这种区分只是为了给软件工程和软件测试环境以不同的命名。3.38软件工程环境softwareengineeringenvironment实施软件工程所需要的设施、硬件、软件、固件、方法和文档。它可以包括(但不限于)计算机辅助软件工程(CASE)的工具、编译程序、汇编程序、连接程序、装载程序、操作系统、排错程序、仿真程序、模拟程序、文档工具和数据库管理系统。3.39软件产品softwareproduct为了满足一个合同而建立、修改或组台的软件及相关资料。例如包括计划、需求、设计、代码、数据库、测试资料和手册。3.40软件质量softwarequality软件满足所规定的需求的能力。3.41软件支持softwaresupport为保证软件安装后能继续按既定目标持续运行而且在系统的运行中能起到既定的作用而实施的一系列活动。软件支持包括软件维护、用户支持和有关的活动。3.42软件系统softwaresystem只由软件组成的系统，有时可能还包括该软件赖以运行的计算机设备。3.43软件测试环境softwaretestenvironment为完成软件合格性测试和可能的其他测试所需的设施、硬件、软件、固件、方法和文档。其要素可以包括(但不限于)仿真程序、代码分析程序、测试用例生成程序和路径分析程序，还可能包括在软件工程环境下用到 GB/T8567-2006《计算机软件文档编制规范》的要素。3.44软件移交softwaretransition使软件开发的责任从一个组织转交给另一个组织的一系列活动。一般说，前一个组织是实现初期软件开发，而后一个组织是进行软件支持。3.45软件单元softwareunitCSCI设计中的一个基本单位：例如，CSCI的一个主要分支，该分支的一个组成部分、一个类、对象、模块、函数、子程序或者数据库。软件配置项可以出现在层次结构的不同层上并可以由其他的软件配置项组成。设计中的软件配置项与实现它们的代码和数据实体(例程、过程、数据库、数据文件等)及或包含这些实体的计算机文件之间不一定有一一对应的关系。4缩略语CASE计算机辅助软件工程ComputerAssistantSoftwareEngineeringCOM计算机操作手册ComputerOperationManualCPM计算机编程手册ComputerProgrammingManualCSCI计算机软件配置项ComputerSoftwareConfigurationItemDBDD数据库(顶层)设计说明DatabaseDesignDescriptionDID资料条目说明DataItemDescriptionDPMR开发进度月报DevelopmentPlanMonthReportDRD数据需求说明DatarequirementDescriptionFAR可行性分析报告FeasibilityanalysisReportHWCI硬件配置项HardwareConfigurationItemIDD接口设计说明InterfaceDesignDescriptionIRS接口(软件)需求规格说明InterfaceRequirementSpecificationIV＆V独立验证和确认IndependentverificationandvalidationOCD运行概念说明OperationConceptionDescriptionPDSR项目开发总结报告ProjectDevelopmentsummaryReportSCCB软件配置控制委员会SoftwareConfigurationControlBoardSCM软件配置管理SoftwareConfigurationManagerSCMP软件配置管理计划SoftwareConfigurationManagerPlanSDD软件(结构)设计说明SoftwareDesignDescriptionSDF软件开发文件SoftwareDevelopmentFileSFDD软件开发文档SoftwareDevelopmentDocumentSDL软件开发库SoftwareDevelopmentLibrarySDP软件开发计划SoftwareDevelopmentPlanSIP软件安装计划SoftwareInstallationPlanSPS软件产品规格说明SoftwareProductSpecificationSQA软件质量保证SoftwareQualityAssureSQAP软件质量保证计划SoftwareQualityAssurePlanSRS软件需求规格说明SoftwareRequirementSpecificationSSDD系统/子系统设计(结构设计)说明SystemSubsystemDesignDescriptionSSS系统/子系统需求规格说明SystemSubsystemRequirementSpecificationSTD软件测试说明SoftwareTestingDescritionSTP软件测试计划SoftwareTestingPlanSTR软件测试报告SoftwareTestingReportSTrP软件移交计划SoftwareTransferPlanSUM软件用户手册SoftwareUserManual GB/T8567-2006《计算机软件文档编制规范》SVD软件版本说明SoftwareVersionDescriptionSW软件Software5文档过程5.1概述有两种主要类型的标准：a)产品标准，它规定产品的特征和功能需求；b)过程标准，它规定开发产品的过程。应用程序和计算机软件的复杂性日益增加，使得给使用计算机的用户提供完整的、正确的和易懂的文档的需要更加迫切。本标准通过规定影响软件文档的质量的活动(做什么和由谁做)，提供达到这些目的的工具。文档常常是关心在软件已经实现后做些什么。然而，为了质量，软件文档编制应作为整个软件生产过程的一部分。过程计划应把文档计划包括在内。本标准也给用户和客户提供工具以保证文档过程实施。本标准的主要活动是建立开发文档的广泛计划。这是必须的，因为有计划，文档编制的质量会更好，过程的效率会更高。计划必须包括风格规格说明。本标准不规定风格规格说明的内容(即不规定具体的布局和字体)，但它规定风格规格说明必须覆盖什么。本标准也规定何种信息对文档管理者是可用的、谁做评审和再生产文档。本标准遵循GB/T8566—2001《信息技术软件生存周期过程》。为其开发过程和管理过程中的主要文档规定了编制规范。本标准是按文档由专门的文档管理人员和文本编写人员的模式规定的。具体的项目可根据具体情况安排。文档过程的活动应按图1中的顺序执行。图1文档编制过程概要得到源材料（需方与文档管理者）开发文档计划评审文档计划开发文档----如文档计划中规定的评审文档可用性测试----如在文档计划中规定的那样重生产和发布----如在文档计划中规定的那样其中，有两个阴影框。在一个阴影框中的所有活动应在下一个阴影框中的活动开始之前完成。在阴影框中的活动可以并行执行。虚线指示可能的重复。在文档的最小内容已经由需方规定的情况下，这宜由文档管理者在文档计划开发期间纳入。5.2源材料准备需方应允许文档管理者访问以下内容：a)所有有关的规格说明、记录格式、屏幕和报告布局、cASE工具输出和文档的准备所需要的任何其他的 GB/T8567-2006《计算机软件文档编制规范》信息；b)若可用，软件的操作副本；c)软件的分析员和程序员，以及及时和确切地解答由文档开发人员提出的问题；d)若可能，访问典型的用户(为了做读者分析和可用性测试)。为了增加对产品和它的读者的了解，对软件开发人员的访问是必要的但使这样的访问保持到最小是文档管理者的责任。不管文档管理者是否是软件的开发者，需方应提供适用的标准、风格和格式指南和其他相关的材料。文档管理者应分发这些材料至需要它的文档开发人员。保证需方交付给文档管理者的所有材料，当交付时，是完整的和正确的且在交付后保持是最新的，这是需方的责任。需方保证，提供的材料没有一个违反任何其他部门的知识产权。文档管理者应采取所有有理由的步骤，以保证由需方提供的材料保持在很好的状态，应保证需方要求的信息安全并在文档项目完成后，所有材料返回给需方。注：在某些情况下，不是所有材料需要返回；这应在合同中定义。在某些情况下，由需方传送给文档管理者的材料要求保持机密和安全。合同宜规定对于传送给文档管理者的材料，需方要求文档管理者的机密和安全等级。5.3文档计划5.3.1概要文档管理者应准备一份文档计划，此计划规定在文档创建中要执行的工作。此文档计划应经需方正式同意，以预示它完全覆盖了需方的要求。注：文档计划通常将覆盖整个文档系列。文档计划应正式地描述计划的文档的范围和限制，以及重要的文档分析和设计决定。也应规定在文档开发期间实现的过程和控制。文档计划应包括(但不限于)以下内容：a)计划的文档的工作名称、目的、范围和限制；b)文档的预定的读者，和使用的目的；c)文档内容的草案表，带有估计的页数和其他媒体的等效细节；d)交付：打印副本数，是否提供电子副本，磁盘和文件格式(包括软件版本)和在何处交付；e)版权的拥有者和任何其他所有权；(注：这是复杂的问题，应在合同中规定。)f)适当处，包括每个文档的安全或机密级；g)管理文档开发过程的步骤和控制，包括存储、检索、后备、处理和质量保证(若要求)；h)所用的生产方法、工具和工具版本；i)文档开发人员所在的队伍的结构，可包括队伍选择计划；注：在文档编写和生产的不同阶段中的工作人员，需要不同的技巧。编写人员可能要求对正在编写的系统有好的知识加上编写文档的经验；编辑人员可能要求有编辑经验而对系统知识无要求；版面艺术家可能对所用的版面工具外，无任何知识要求。j)项目依赖；k)所要求的人时和成本；l)项目资源需求，包括需方提供的信息和其他资源；m)在软件开发期间，软件变更传送信息给文档管理者的方法；n)文档的变更控制和维护的计划(任选)；0)实现后评审的计划(任选)；p)显示适当的里程碑的时间表，包括：1)文档计划批准；2)每个草案的准备、评审和改正；3)可用性测试； GB/T8567-2006《计算机软件文档编制规范》4)打印、装订和发布。若适当，这些活动的每一个对于文档的每一项应重复。注：文档计划宜在文档的开发开始以前准备与批准，以保证所有部门同意目标和所用的方法。批准后，计划宜尽可能广泛地分发；分发宜包括所有文档开发人员和可能包括需方人员及子合同方。5.3.2文档计划控制在正式批准后，文档管理者应控制文档计划和它的发布。文档管理者应保持一份文档计划副本的分发的清单。若以后文档计划变更了(得到文档管理者和需方的同意)，文档管理者应保证所有获得文档计划副本的人员得到变更通知。注：因为，过时的计划副本可能引起问题。文档管理者宜杜绝计划副本的失控，并制订计划的所有副本已经更新的审核过程。5.4文档开发按文档计划规定进行文档开发。通常，在进行文档开发前，要规定文档的格式(风格)。在软件的开发和管理过程中需要那些文档，每种文档的规范在下面说明。5.5评审5.5.1概述本条规定文档评审的要求和相关活动。本条主要以用户文档的评审为例说明。对于开发文档的评审，由供方组织和实施。而批准由开发组织的上级技术机构实施。更要着重经常性的、非正式的注重实效的评审。用户文档的评审应由需方实现，包括当需要时与文档管理者讨论。注：评审的耳的是保证提交的材料是完整的和正确的并满足了在合同和文档计划中定义的需方的需要。评审宜由合适的有资格的人员执行，这些人员被授权请求变更和批准文档的内容。注：需方宜限制评审人员数，满足评审功能所必需的那些即可。需方在批准每个用户文档草案之前，应保证文档的安全和合法。为评审交付的文档应包括从文档管理者来的说明书，说明评审的目的和评审员的职责。注1：在需方和文档管理者之间在整个开发过程期间维持良好的沟通会提高文档的质量并利于评审成功。这宜包括非正式的讨论和尽早地提供样板或初始材料给需方。注2：在要求的变更超出了合同和文档计划的范围时，需要变更合同。注3：评审过程不排除文档管理者，他们的责任是试图尽可能保证文档的精确和完整。注4：宜采用作为评审结果的需方的评论，或在草案上加上标记，或写有适当的参考的评论。需方宜保持变更的副本为了与下一草案相比较。评论应使文档开发人员能实现所要求变更而不需要评审人员进一步解释。注5：对于大的、复杂的系统或正在写文档时系统仍在开发，可能需要多于两次草案和一次校样。在这样情况下，最多的草案数宜在需方和文档管理者之间同意并在文档计划中规定。5.5.2文档计划评审此评审的目的应保证文档计划定义的文档，当完成时，既满足开发过程的需要也满足需方在合同中规定的文档目标。需方同意文档计划，是同意在计划中定义的用户文档的所有可交付的特征。注：需方宜把注意放在内容的草案表中展示的文档的结构、完整性和可用性。只要适当，文档计划宜在第一个草案开始工作之前评审和批准。5.5.3第一个草案评审第一个草案应包含如在文档计划中描述的文档主体，加上内容表、附录和词汇。在使用自动索引工具处，生成的索引包含位置参照。标点符号、风格和版面应如在文档计划中描述的。文档的第一个草案的评审目的是核查文档的技术正确性和完整性，以保证草案满足文档计划的目标。标点符号、风格和版面应如在文档计划中定义的。在批准第一个草案中，除了要求的变更外，要评审批准技术的正确性、结构清楚性和文档的完整性。注1：第一个草案宜在交付前编辑。这有两个理由：a)这保证评审者不分心于改正印刷的和版面的错误；b)保证由编辑过程引起的任何技术错误被评审者捕获。注2：草案应针对在文档计划中批准的目标、读者定义、内容表和其他特征进行评审。在带有评论的第一 GB/T8567-2006《计算机软件文档编制规范》个草案返回前，宜确认，若草案完全改正了，将满足文档计划的要求。5.5.4第二个草案评审第二个草案应包括在第一个草案评审中同意的所有变更，且应以尽可能接近最后的形式，包括在文档计划中定义的可交付的内容。此评审的目的是核查在第一个草案中的内容已经正确实现。在第二个草案的批准中，除了草案的物理形式外，批准文档的所有方面。草案的物理形式可能与可交付的不精确相同。注：在批准第二个草案前，宜确认草案(包含评审对草案的评论)已经准备好待批准。5.5.5校样评审校样应包括在第二个草案评审中同意的所有变更。此评审的目的是核查对第二个草案的评论已正确实现。任何不正确实现的评论应迅速地通知文档管理者，他们应相应地修改文档并返回可替换部分的副本，用于进一步评审。由批准证明，被接受的文档已准备好生产。5.6与其他公司的文档开发子合同文档管理者应保证子合同的文档遵循本标准，遵循文档计划和合同。在子合同的文档中，文档管理者作为本标准的“需方”而子合同承担者作为“文档管理者”。注：文档管理者应与子合同承担者签定符合本标准的协议。6文档编制要求6.1软件生存周期与各种文档的编制在软件的生存周期中，一般地说，应该产生以下一些基本文档：a)可行性分析(研究)报告；j)操作手册；b)软件(或项目)开发计划；k)测试计划；c)软件需求规格说明；1)测试报告；d)接口需求规格说明；m)软件配置管理计划；e)系统/子系统设计(结构设计)说明；n)软件质量保证计划；f)软件(结构)设计说明；o)开发进度月报；g)接口设计说明；p)项目开发总结报告；h)数据库(顶层)设计说明；q)软件产品规格说明；i)(软件)用户手册；r)软件版本说明等。本标准将给出这些文档的编制规范，同时，本标准也是这些文档的编写质量的检验准则。一般地说，一个软件总是一个计算机系统(包括硬件、固件和软件)的组成部分。鉴于计算机系统的多样性，本标准一般不涉及整个系统开发中的文档编制问题，本标准仅仅是软件开发过程中的文档编制指南。对于面向对象的软件开发，其文档编制要求，参见附录A。对于使用文档的人员而言，他们所关心的文件的种类随他们所承担的工作而异。管理人员开发人员维护人员用户可行性分析(研究)报告可行性分析(研究)报告软件需求规格说明软件产品规格说明项目开发计划项目开发计划接口需求规格说明软件版本说明软件配置管理计划软件需求规格说明软件(结构)设计说明用户手册软件质量保证计划接口需求规格说明测试报告操作手册开发进度月报软件(结构)设计说明项目开发总结报告接口设计说明书数据库(顶层)设计说明测试计划测试报告 GB/T8567-2006《计算机软件文档编制规范》本标准规定了在软件开发过程中文档编制的要求，这些文档从使用的角度可分为用户文档和开发文档两大类。其中，用户文档必须交给用户。用户应该得到的文档的种类和规模由供应者与用户之间签订的合同规定。如前所述，软件，从出现一个构思之日起，经过软件开发成功投入使用，直到最后决定停止使用并被另一项软件代替之时止，被认为是该软件的一个生存周期，一般地说这个软件生存周期可以分成以下6个阶段：a)可行性与计划研究阶段；b)需求分析阶段；c)设计阶段；d)实现阶段；e)测试阶段；f)运行与维护阶段。在可行性分析(研究)与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资——收益分析、制订开发计划，并完成可行性分析报告、开发计划等文档。在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性能需求和设计约束，确定对文档编制的要求，作为本阶段工作的结果，一般地说软件需求规格说明(也称为：软件需求说明、软件规格说明)、数据要求说明和初步的用户手册应该编写出来。在设计阶段内，系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一个设计，包括该软件的结构、模块(或CSCI)的划分、功能的分配，以及处理流程。在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。在一般情况下，应完成的文档包括：结构设计说明、详细设计说明和测试计划初稿。在实现阶段内，要完成源程序的编码、编译(或汇编)和排错调试得到无语法错的程序清单，要开始编写进度日报、周报和月报(是否要有日报或周报，取决于项目的重要性和规模)，并且要完成用户手册、操作手册等面向用户的文档的编写工作，还要完成测试计划的编制。在测试阶段：该程序将被全面地测试，已编制的文档将被检查审阅。一般要完成测试分析报告。作为开发工作的结束，所生产的程序、文档以及开发工作本身将逐项被评价，最后写出项目开发总结报告。在整个开发过程中(即前五个阶段中)，开发集体要按月编写开发进度月报。在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能的扩充和删改、更新和升级。6.2文档编制中的考虑因素文档编制是开发过程的有机组成部分，也是一个不断努力的工作过程。是一个从形成最初轮廓、经反复检查和修改，直至程序和文档正式交付使用的完整过程。其中每一步都要求工作人员做出很大努力。要保证文档编制的质量，要体现每个开发项目的特点，也要注意不要花太多的人力。为此编制中要考虑如下各项因素。6.2.1文档的读者每一种文档都具有特定的读者。这些读者包括个人或小组、软件开发单位的成员或社会上的公众、从事软件工作的技术人员、管理人员或领导干部。他们期待着使用这些文档的内容来进行工作，例如设计、编写程序、测试、使用、维护或进行计划管理。因此这些文档的作者必须了解自己的读者。这些文档的编写必须注意适应自己的特定读者的水平、特点和要求。6.2.2重复性本标准中列出的文档编制规范的内容要求中，显然存在某些重复。较明显的重复有两类。引言是每一种文档都要包含的内容，以向读者提供总的梗概。第二类明显的重复是各种文档中的说明部分，如对功能性能的说明；对输入、输出的描述；系统中包含的设备等。这是为了方便每种文档各自的读者，每种文档应该自成体系，尽量避免读一种文档时又不得不去参考另一种文档。当然，在每一种文档里，有关引言、说明等同其他文档相重复的部分，在行文上、在所用的术语上、在详细的程度上，还是应该有一些差别以适应各种文档的不同读者的需要。6.2.3灵活性鉴于软件开发是具有创造性的脑力劳动，也鉴于不同软件在规模上和复杂程度上差别极大，在文档编制工作中允许一定的灵活性。这种灵活性如下所述。 GB/T8567-2006《计算机软件文档编制规范》a)应编制的文档种类尽管本标准认为在一般情况下，一项软件的开发过程中，应产生如上所述的各种文档，然而针对一项具体的软件开发项目，有时不必编制这么多的文档，可以把几种文档合并成一种。一般地说，当项目的规模、复杂性和失败风险增大时，文档编制的范围，管理手续和详细程度将随之增加，反之，则可适当减少。为了恰当地掌握这种灵活性，本标准要求贯彻分工负责的原则，这意味着：1)一个软件开发单位的领导机构应该根据本单位经营承包的应用软件的专业领域和本单位的管理能力，制定一个对文档编制要求的实施规定，主要是：在不同的条件下，应该形成哪些文档?这些文档的详细程度?该开发单位的每一个项目负责人，必须认真执行这个实施规定。2)对于一个具体的应用软件项目，项目负责人应根据上述实施规定，确定一个文档编制计划(可以包含在软件开发计划中)，其中包括：(1)应该编制哪几种文档，详细程度如何?(2)各个文档的编制负责人和进度要求；(3)审查、批准的负责人和时间进度安排；(4)在开发时间内，各文档的维护、修改和管理的负责人，以及批准手续。每项工作必须落实到人。这个文件编制计划是整个开发计划的重要组成部分。3)有关的设计人员则必须严格执行这个文档编制计划。b)文档的详细程度从同一份提纲起草的文件的篇幅大小往往不同，可以少到几页，也可以长达几百页。对于这种差别，本标准是允许的。此详细程度取决于任务的规模、复杂性和项目负责人对该软件的开发过程及运行环境所需要的详细程度的判断。c)文档的扩展当被开发系统的规模非常大(例如源码超过一百万行)时，一种文档可以分成几卷编写，可以按其中每一个系统分别编制；也可以按内容划分成多卷，例如：项目开发计划可能包括：质量保证计划，配置管理计划，用户培训计划，安装实施计划；系统设计说明可分写成：系统设计说明，子系统设计说明；程序设计说明可分写成：程序设计说明，接口设计说明，版本说明；操作手册可分写成：操作手册，安装实施过程；测试计划可分写成：测试计划，测试设计说明，测试规程，测试用例；测试分析报告可分写成：综合测试报告，验收测试报告；项目开发总结报告亦可分写成项目开发总结报告和资源环境统计。d)章、条的扩张与缩并在软件文档中，一般宜使用本标准提供的章、条标题。但所有的条都可以扩展，可以进一步细分，以适应实际需要。反之如果章条中的有些细节并非必需，也可以根据实际情况缩并。此时章条的编号应相应地变更。e)程序设计的表现形式本标准对于程序的设计表现形式并未作出规定或限制，可以使用流程图的形式，判定表的形式，也可以使用其他表现形式，如程序设计语言(PDL)、问题分析图(PALb)等。f)文档的表现形式本标准对于文档的表现形式亦未作出规定或限制。可以使用自然语言，也可以使用形式化语言。也可以使用各种图、表。g)文档的其他种类当本标准中规定的文档种类尚不能满足某些应用部门的特殊需要时，他们可以建立一些特殊的文档种类要求，例如软件质量保证计划、软件配置管理计划等，这些要求可以包含在本单位的文件编制实施规定中。7文档编制格式7.1可行性分析(研究)报告(FAR)说明：l.《可行性分析(研究)报告》(FAR)是项目初期策划的结果，它分析了项目的要求、目标和环境；提出了 GB/T8567-2006《计算机软件文档编制规范》几种可供选择的方案；并从技术、经济和法律各方面进行了可行性分析。可作为项目决策的依据。2.FAR也可以作为项目建议书、投标书等文件的基础。可行性分析报告的正文格式如下：1引言本章分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。1.2背景说明项目在什么条件下提出，提出者的要求、目标、实现环境和限制条件。1.3项目概述本条应简述本文档适用的项目和软件的用途，它应描述项目和软件的一般特性；概述项目开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。1.4文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性和私密性的要求。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。3可行性分析的前提3.1项目的要求3.2项目的目标3.3项目的环境、条件、假定和限制3.4进行可行性分析的方法4可选的方案4.1原有方案的优缺点、局限性及存在的问题4.2可重用的系统，与要求之间的差距4.3可选择的系统方案14.4可选择的系统方案24.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投资包括基本建设投资(如开发环境、设备、软件和资料等)，其他一次性和非一次性投资(如技术管理费、培训费、管理费、人员工资、奖金和差旅费等)。 GB/T8567-2006《计算机软件文档编制规范》6.2预期的经济效益6.2.1一次性收益6.2.2非一次性收益6.2.3不可定量的收益6.2.4收益/投资比6.2.5投资回收周期6.3市场预测7技术可行性(技术风险评价)本公司现有资源(如人员、环境、设备和技术条件等)能否满足此工程和项目实施要求，若不满足，应考虑补救措施(如需要分承包方参与、增加人员、投资和设备等)，涉及经济问题应进行投资、成本和效益可行性分析，最后确定此工程和项目是否具备技术可行性。8法律可行性系统开发可能导致的侵权、违法和责任。9用户使用可行性用户单位的行政管理和工作制度；使用人员的素质和培训要求。10其他与项目有关的问题未来可能的变化。11注解本章应包含有助于理解本文档的一般信息(例如原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理附录可单独装订成册。附录应按字母顺序(A，B等)编排。7.2软件开发计划(SDP)说明：1.《软件开发计划》(SDP)描述开发者实施软件开发工作的计划，本文档中“软件开发”一词涵盖了新开发、修改、重用、再工程、维护和由软件产品引起的其他所有的活动。2.SDP是向需求方提供了解和监督软件开发过程、所使用的方法、每项活动的途径、项目的安排、组织及资源的一种手段。3.本计划的某些部分可视实际需要单独编制成册，例如，软件配置管理计划、软件质量保证计划和文档编制计划等。软件开发计划的正文的格式如下1引言本章分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。1.3文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性和私密性的要求。1.4与其他计划之间的关系(若有)本条描述本计划和其他项目管理计划的关系。 GB/T8567-2006《计算机软件文档编制规范》1.5基线给出编写本项目开发计划的输入基线，如软件需求规格说明。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。3交付产品3.1程序3.2文档3.3服务3.4非移交产品3.5验收标准3.6最后交付期限列出本项目应交付的产品，包括软件产品和文档。其中，软件产品应指明哪些是要开发的，哪些是属于维护性质的；文档是指随软件产品交付给用户的技术文档，例如用户手册、安装手册等。4所需工作概述本章根据需要分条对后续章描述的计划作出说明，(若适用)包括以下概述：a.对所要开发系统、软件的需求和约束；b.对项目文档编制的需求和约束；c.该项目在系统生命周期中所处的地位；d.所选用的计划/采购策略或对它们的需求和约束；e.项目进度安排及资源的需求和约柬；f.其他的需求和约束，如：项目的安全性、保密性、私密性、方法、标准、硬件开发和软件开发的相互依赖关系等。5实施整个软件开发活动的计划本章分以下几条。不需要的活动的条款用“不适用”注明，如果对项目中不同的开发阶段或不同的软件需要不同的计划，这些不同之处应在此条加以注解。除以下规定的内容外，每条中还应标识可适用的风险和不确定因素，及处理它们的计划。5.1软件开发过程本条应描述要采用的软件开发过程。计划应覆盖论及它的所有合同条款，确定已计划的开发阶段(适用的话)、目标和各阶段要执行的软件开发活动。5.2软件开发总体计划本条应分以下若干条进行描述。5.2.1软件开发方法本条应描述或引用要使用的软件开发方法，包括为支持这些方法所使用的手工、自动工具和过程的描述。该方法应覆盖论及它的所有合同条款。如果这些方法在它们所适用的活动范围有更好的描述，可引用本计划的其他条。5.2.2软件产品标准本条应描述或引用在表达需求、设计、编码、测试用例、测试过程和测试结果方面要遵循的标准。标准应覆盖合同中论及它的所有条款。如果这些标准在标准所适用的活动范围有更好的描述，可引用本计划中的其他条。对要使用的各种编程语言都应提供编码标准，至少应包括：a.格式标准(如：缩进、空格、大小写和信息的排序)；b.首部注释标准，例如(要求：代码的名称/标识符，版本标识，修改历史，用途)需求和实现的设计决策，处理的注记(例如：使用的算法、假设、约束、限制和副作用)，数据注记(输入、输出、变量和数据结构等)；c.其他注释标准(例如要求的数量和预期的内容)；d.变量、参数、程序包、过程和文档等的命名约定；e.(若有)编程语言构造或功能的使用限制； GB/T8567-2006《计算机软件文档编制规范》f.代码聚合复杂性的制约。5.2.3可重用的软件产品本条应分以下若干条。5.2.3.1吸纳可重用的软件产品本条应描述标识、评估和吸纳可重用软件产品要遵循的方法，包括搜寻这些产品的范围和进行评估的准则。描述应覆盖合同中论及它的所有条款。在制定或更新计划时对已选定的或候选的可重用的软件产品应加以标识和说明，(若适用)同时应给出与使用有关的优点、缺陷和限制。5.2.3.2开发可重用的软件产品本条应描述如何标识、评估和报告开发可重用软件产品的机会。描述应覆盖合同中论及它的所有条款。5.2.4处理关键性需求本条应分以下若干条描述为处理指定关键性需求应遵循的方法。描述应覆盖合同中论及它的所有条款。5.2.4.1安全性保证5.2.4.2保密性保证5.2.4.3私密性保证5.2.4.4其他关键性需求保证5.2.5计算机硬件资源利用本条应描述分配计算机硬件资源和监控其使用情况要遵循的方法。描述应覆盖合同中论及它的所有条款。5.2.6记录原理本条应描述记录原理所遵循的方法，该原理在支持机构对项目作出关键决策时是有用的。应对项目的“关键决策”一词作出解释，并陈述原理记录在什么地方。描述应覆盖合同中论及它的所有条款。5.2.7需方评审途径本条应描述为评审软件产品和活动，让需方或授权代表访问开发方和分承包方的一些设施要遵循的方法。描述应遵循合同中论及它的所有条款。6实施详细软件开发活动的计划本章分条进行描述。不需要的活动用“不适用”注明，如果项目的不同的开发阶段或不同的软件需要不同的计划，则在本条应指出这些差异。每项活动的论述应包括应用于以下方面的途径(方法/过程/工具)：a.所涉及的分析性任务或其他技术性任务；b.结果的记录；c.与交付有关的准备(如果有的话)。论述还应标识存在的风险和不确定因素，及处理它们的计划。如果适用的方法在5.2.1处描述了的话，可引用它。6.1项目计划和监督本条分成若干分条描述项目计划和监督中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.1.1软件开发计划(包括对该计划的更新)6.1.2CSCI测试计划6.1.3系统测试计划6.1.4软件安装计划6.1.5软件移交计划6.1.6跟踪和更新计划，包括评审管理的时间间隔6.2建立软件开发环境本条分成以下若干分条描述建立、控制、维护软件开发环境所遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.2.1软件工程环境6.2.2软件测试环境6.2.3软件开发库6.2.4软件开发文档 GB/T8567-2006《计算机软件文档编制规范》6.2.5非交付软件6.3系统需求分析6.3.1用户输入分析6.3.2运行概念6.3.3系统需求6.4系统设计6.4.1系统级设计决策6.4.2系统体系结构设计6.5软件需求分析本条描述软件需求分析中要遵循的方法。应覆盖合同中论及它的所有条款。6.6软件设计本条应分成若干分条描述软件设计中所遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.6.1CSCI级设计决策6.6.2CSCI体系结构设计6.6.3CSCI详细设计6.7软件实现和配置项测试本条应分成若干分条描述软件实现和配置项测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.7.1软件实现6.7.2配置项测试准备6.7.3配置项测试执行6.7.4修改和再测试6.7.5配置项测试结果分析与记录6.8配置项集成和测试本条应分成若干分条描述配置项集成和测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.8.1配置项集成和测试准备6.8.2配置项集成和测试执行6.8.3修改和再测试6.8.4配置项集成和测试结果分析与记录6.9CSCI合格性测试本条应分成若干分条描述CSCI合格性测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.9.1CSCI合格性测试的独立性6.9.2在目标计算机系统(或模拟的环境)上测试6.9.3CSCI合格性测试准备6.9.4CSCI合格性测试演练6.9.5CSCI合格性测试执行6.9.6修改和再测试6.9.7CSCI合格性测试结果分析与记录6.10CSCI/HWCI集成和测试本条应分成若干分条描述CSCI/HWCI集成和测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.10.1CSCI/HWCI集成和测试准备6.10.2CSCI/HWCI集成和测试执行6.10.3修改和再测试 GB/T8567-2006《计算机软件文档编制规范》6.10.4CSCI/HWCI集成和测试结果分析与记录6.11系统合格性测试本条应分成若干分条描述系统合格性测试中要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。6.11.1系统合格性测试的独立性6.11.2在目标计算机系统(或模拟的环境)上测试6.11.3系统合格性测试准备6.11.4系统合格性测试演练6.11.5系统合格性测试执行6.11.6修改和再测试6.11.7系统合格性测试结果分析与记录6.12软件使用准备本条应分成若干分条描述软件应用准备中要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。6.12.1可执行软件的准备6.12.2用户现场的版本说明的准备6.12.3用户手册的准备6.12.4在用户现场安装6.13软件移交准备本条应分成若干分条描述软件移交准备要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。6.13.1可执行软件的准备6.13.2源文件准备6.13.3支持现场的版本说明的准备6.13.4“已完成”的CSCI设计和其他的软件支持信息的准备6.13.5系统设计说明的更新6.13.6支持手册准备6.13.7到指定支持现场的移交6.14软件配置管理本条应分成若干分条描述软件配置管理中要遵循的方法.各分条的计划应遵循合同中论及它的所有条款。6.14.1配置标识6.14.2配置控制6.14.3配置状态统计6.14.4配置审核6.14.5发行管理和交付6.15软件产品评估本条应分成若干分条描述软件产品评估中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.15.1中间阶段的和最终的软件产品评估6.15.2软件产品评估记录(包括所记录的具体条目)6.15.3软件产品评估的独立性6.16软件质量保证本条应分成若干分条描述软件质量保证中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.16.1软件质量保证评估6.16.2软件质量保证记录、包括所记录的具体条目6.16.3软件质量保证的独立性6.17问题解决过程(更正活动)本条应分成若干分条描述软件更正活动中要遵循的方法.各分条的计划应覆盖合同中论及它的所有条款。6.17.1问题/变更报告 GB/T8567-2006《计算机软件文档编制规范》它包括要记录的具体条目(可选的条目包括：项目名称，提出者，问题编号，问题名称，受影响的软件元素或文档，发生日期，类别和优先级，描述，指派的该问题的分析者，指派日期，完成日期，分析时间，推荐的解决方案，影响，问题状态，解决方案的批准，随后的动作，更正者，更正日期，被更正的版本.更正时间，已实现的解决方案的描述)。6.17.2更正活动系统6.18联合评审(联合技术评审和联合管理评审)本条应分成若干分条描述进行联合技术评审和联合管理评审要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款.6.18.1联合技术评审包括----组建议的评审6.18.2联合管理评审包括----组建议的评审6.19文档编制本条应分成若干分条描述文档编制要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款.应遵循本标准第5章文档编制过程中的有关文档编制计划的规定执行.6.20其他软件开发活动本条应分成若干分条描述进行其他软件开发活动要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款.6.20.1风险管理，包括已知的风险和相应的对策6.20.2软件管理指标，包括要使用的指标6.20.3保密性和私密性6.20.4分承包方管理6.20.5与软件独立验证与确认(IV&V)机构的接口6.20.6和有关开发方的协调6.20.7项目过程的改进6.20.8计划中未提及的其他活动7进度表和活动网络图本章应给出：a.进度表，标识每个开发阶段中的活动，给出每个活动的初始点、提交的草稿和最终结果的可用性、其他的里程碑及每个活动的完成点.b.活动网络图，描述项目活动之间的顺序关系和依赖关系，标出完成项目中有最严格时间限制的活动。8项目组织和资源本章应分成若干条描述各阶段要使用的项目组织和资源.8.1项目组织本条应描述本项目要采用的组织结构，包括涉及的组织机构、机构之间的关系、执行所需活动的每个机构的权限和职责。8.2项目资源本条应描述适用于本项目的资源。(若适用)应包括：a.人力资源，包括：1)估计此项目应投入的人力(人员/时间数);2)按职责(如：管理，软件工程，软件测试，软件配置管理，软件产品评估，软件质量保证和软件文档编制等)分解所投入的人力；3)履行每个职责人员的技术级别、地理位置和涉密程度的划分；b.开发人员要使用的设施，包括执行工作的地理位置、要使用的设施、保密区域和运用合同项目的设施的其他特性；c.为满足合同需要，需方应提高的设备、软件、服务、文档、资料及设施，给出一张何时需要上述各项的进度表；d.其他所需的资源，包括：获得资源的计划、需要的日期和每项资源的可用性. GB/T8567-2006《计算机软件文档编制规范》9培训9.1项目的技术要求根据客户需求和项目策划结果，确定本项目的技术要求，包括管理技术和开发技术。9.2培训计划根据项目的技术要求和项目成员的情况，确定是否需要进行项目培训，并制订培训计划。如不需要培训，应说明理由。10项目估算本章应分若干条说明项目估算的结果。10.1规模估算10.2工作量估算10.3成本估算10.4关键计算机资源估算10.5管理预留11风险管理本章应分析可能存在的风险，所采取的对策和风险管理计划。12支持条件12.1计算机系统支持。12.2需要需方承担的工作和提供的条件。12.3需要分包商承担的工作和提供的条件。13注解本章应包含有助于理解本文档的一般信息(例如原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.3软件测试计划(STP)说明：1.《软件测试计划》（STP)描述对计算机软件配置项CSCI,系统或子系统进行合格性测试的计划安排。内容包括进行测试的环境、测试工作的标识及测试工作的时间安排等。2.通常每个项目只有一个STP,使得需方能够对合格性测试计划的充分性作出评估。软件测试计划的正文的格式如下：1引言本章应分成以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。1.3文档概述本条应概括本文档的用途与内容，并描述与其使用有关的保密性或私密性要求。1.4与其他计划的关系(若有)本条应描述本计划和有关的项目管理计划之间的关系。1.5基线 GB/T8567-2006《计算机软件文档编制规范》给出编写本软件测试计划的输入基线，如软件需求规格说明。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章还应标识不能通过正常的供货渠道获得的所有文档的来源。3软件测试环境本章应分条描述每一预计的测试现场的软件测试环境。可以引用软件开发计划(SDP)中所描述的资源。3.x(测试现场名称)本条应标识一个或多个用于测试的测试现场，并分条描述每个现场的软件测试环境。如果所有测试可以在一个现场实施，本条及其子条只给出一次。如果多个测试现场采用相同或相似的软件测试环境，则应在一起讨论。可以通过引用前面的描述来减少测试现场说明信息的重复。3.x.1软件项(若适用)本条应按名字、编号和版本标识在测试现场执行计划测试活动所需的软件项(如操作系统、编译程序、通信软件、相关应用软件、数据库、输入文件、代码检查程序、动态路径分析程序、测试驱动程序、预处理器、测试数据产生器、测试控制软件、其他专用测试软件和后处理器等)。本条应描述每个软件项的用途、媒体(磁带、盘等)，标识那些期望由现场提供的软件项，标识与软件项有关的保密措施或其他保密性与私密性问题。3.x.2硬件及固件项(若适用)本条应按名字、编号和版本标识在测试现场用于软件测试环境中的计算机硬件、接口设备、通信设备、测试数据归约设备、仪器设备(如附加的外围设备(磁带机、打印机、绘图仪)、测试消息生成器、测试计时设备和测试事件记录仪等)和固件项。本条应描述每项的用途，陈述每项所需的使用时间与数量，标识那些期望由现场提供的项，标识与这些项有关的保密措施或其他保密性与私密性问题。3.x.3其他材料本条应标识并描述在测试现场执行测试所需的任何其他材料。这些材料可包括手册、软件清单、被测试软件的媒体、测试用数据的媒体、输出的样本清单和其他表格或说明。本条应标识需交付给现场的项和期望由现场提供的项。(若适用)本描述应包括材料的类型、布局和数量。本条应标识与这些项有关的保密措施或其他保密性与私密性问题。3.x.4所有权种类、需方权利与许可证本条应标识与软件测试环境中每个元素有关的所有权种类、需方权利与许可证等问题。3.x.5安装、测试与控制本条应标识开发方为执行以下各项工作的计划，可能需要与测试现场人员共同合作：a.获取和开发软件测试环境中的每个元素；b.使用前，安装与测试软件测试环境中的每项；c.控制与维护软件测试环境中的每项.3.x.6参与组织本条应标识参与现场测试的组织和它们的角色与职责。3.x.7人员本条应标识在测试阶段测试现场所需人员的数量、类型和技术水平，需要他们的日期与时间，及任何特殊需要，如为保证广泛测试工作的连续性与一致性的轮班操作与关键技能的保持。3.x.8定向计划本条应描述测试前和测试期间给出的任何定向培训。此信息应与3.x.7所给的人员要求有关。培训可包括用户指导、操作员指导、维护与控制组指导和对全体人员定向的简述。如果预料有大量培训的话，可单独制定一个计划而在此引用。3.x.9要执行的测试本条应通过引用第4章来标识测试现场要执行的测试。4计划本章应描述计划测试的总范围并分条标识，并且描述本STP适用的每个测试。 GB/T8567-2006《计算机软件文档编制规范》4.1总体设计本条描述测试的策略和原则，包括测试类型和测试方法等信息。4.1.1测试级本条所描述要执行的测试的级别，例如:CSCI级或系统级。4.1.2测试类别本条应描述要执行的测试的类型或类别(例如，定时测试、错误输入测试、最大容量测试)。4.1.3一般测试条件本条应描述运用于所有测试或一组测试的条件，例如：“每个测试应包括额定值、最大值和最小值；”“每个x类型的测试都应使用真实数据(livedata)；”“应度量每个CSCI执行的规模与时间。”并对要执行的测试程度和对所选测试程度的原理的陈述。测试程度应表示为某个已定义总量(如离散操作条件或值样本的数量)的百分比或其他抽样方法。也应包括再测试/回归测试所遵循的方法。4.1.4测试过程在渐进测试或累积测试情况下，本条应解释计划的测试顺序或过程。4.1.5数据记录、归约和分析本条应标识并描述在本STP中标识的测试期间和测试之后要使用的数据记录、归纳和分析过程。(若适用)这些过程包括记录测试结果、将原始结果处理为适合评价的形式，以及保留数据归约与分析结果可能用到的手工、自动、半自动技术。4.2计划执行的测试本条应分条描述计划测试的总范围。4.2.x(被测试项)本条应按名字和项目唯一标识符标识一个CSCI、子系统、系统或其他实体，并分以下几条描述对各项的测试。4.2.x.y(测试的项目唯一标识符)本条应由项目唯一标识符标识一个测试，并为该测试提供下述测试信息。根据需要可引用4.1中的一般信息。a.测试对象；b.测试级；c.测试类型或类别；d.需求规格说明中所规定的合格性方法；e.本测试涉及的CSCI需求(若适用)和软件系统需求的标识符(此信息亦可在第6章中提供)；f.特殊需求(例如，设备连续工作48小时、测试程度、特殊输入或数据库的使用)；g.测试方法，包括要用的具体测试技术，规定分析测试结果的方法。h.要记录的数据的类型；i.要采用的数据记录/归约/分析的类型；j.假设与约束，如由于系统或测试条件即时间、接口、设备、人员、数据库等的原因而对测试产生的预期限制；k.与测试有关的安全性、保密性与私密性要求。4.3测试用例a.测试用例的名称和标识；b.简要说明本测试用例涉及的测试项和特性；c.输入说明，规定执行本测试用例所需的各个输入，规定所有合适的数据库、文件、终端信息、内存常驻区域和由系统传送的值，规定各输入间所需的所有关系(如时序关系等)；d.输出说明，规定测试项的所有输出和特性(如：响应时间)，提供各个输出或特性的正确值；e.环境要求，见本文档第3章。5测试进度表本章应包含或引用指导实施本计划中所标识测试的进度表。包括： GB/T8567-2006《计算机软件文档编制规范》a.描述测试被安排的现场和指导测试的时间框架的列表或图表。b.每个测试现场的进度表，(若适用)它可按时间顺序描述以下所列活动与事件，根据需要可附上支持性的叙述。1)分配给测试主要部分的时间和现场测试的时间，2)现场测试前，用于建立软件测试环境和其他设备、进行系统调试、定向培训和熟悉工作所需的时间；3)测试所需的数据库/数据文件值、输入值和其他操作数据的集合；4)实施测试,包括计划的重测试；5)软件测试报告(STR)的准备、评审和批准。6需求的可追踪性本章应包括：a.从本计划所标识的每个测试到它所涉及的CSCI需求和(若适用)软件系统需求的可追踪性(此可追踪性亦可在4.2.x.y中提供，而在此引用)。b.从本测试计划所覆盖的每个CSCI需求和(若适用)软件系统需求到针对它的测试的可追踪性。这种可追踪性应覆盖所有适用的软件需求规格说明(SRS)和相关接口需求规格说明(IRS)中的CSCI需求，对于软件系统，还应覆盖所有适用的系统/子系统规格说明(SSS)及相关系统级IRS中的系统需求。7评价7.1评价准则7.2数据处理7.3结论8注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.4软件安装计划(SIP)说明：1.《软件安装计划》(SIP)是为在用户现场安装软件所作的计划。内容包括准备工作、用户培##训、从现有系统怎样转换等。2.仅当开发者被要求参与在用户现场安装软件.而且安装过程相当复杂时，才需要制定SIP和编写本文档。对嵌人硬件系统的软件来说，由于系统已经有了装备或布署计划，故不需要单独的SIP。软件安装计划的正文的格式如下：1引言本章应分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识。(若适用)包括标识号、标题、缩略词语、版本号和发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途，它并描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。1.3文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性或私密性要求。1.4与其他计划之间的关系(若有)本条应描述本计划和其他项目管理计划的关系。 GB/T8567-2006《计算机软件文档编制规范》2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。3安装概述本章应分以下几条概述安装过程。3.1描述本条应提供安装过程的一般描述，以便为文档的其余部分提供一个参考框架。内容包括：软件安装地点列表、安装进度和安装方法。3.2联系地点本条应为咨询与安装有关的问题提供联系的单位名称、办公室代号/代码和电话号码等。3.3支持材料本条应列出安装所需支持材料的类型、来源和数量。包括：磁带、盘、计算机打印纸和专用表格等。3.4培训本条应列出并描述开发方对操作和使用安装在现场的软件的人员所制定的培训计划。内容包括：一般培训、授课培训和实习培训。3.5任务本条应用常用术语列出并描述在软件安装过程中所涉及的各项任务，每项任务的描述应标识出完成该任务的组织，通常是用户、计算机操作人员或开发方。任务列表包括以下内容：a.安装的总体计划、协调和准备工作；b.安装小组的人员配备；c.安装小组住宿、交通和办公设施的安排；d.确保用于安装的手册在需要时可获得；e.确保安装前完成其他必要的准备工作；f.培训活动的计划和指导；g.培训学员；h.为安装提供所需的计算机和技术支持；i.从当前系统的转换。3.6人员本条应描述安装过程中所需人员的数量、类型和技术水平，其中包括轮班操作和办事人员的需求。3.7保密性与私密性本条应概述系统有关的保密性和私密性方面的考虑。4为软件中心操作员提供特定现场信息本章适用于以下情况：软件安装在计算机中心、其他集中式的或网络的软件装置上，用户可通过终端或采用批量输入/输出方式进行访问。如果不采用此类安装，则本章注明“不适用”。4.x现场名本条应标识一个或一组现场，再分条对它们进行论述。当多个现场的信息基本相同时，可合在一起进行论述。4.x.1进度表本条应给出安装期间要完成任务的进度表。按照每个任务的开始日期和完成日期的时间顺序描述，并加以必要的叙述。4.x.2软件清单本条应给出支持安装所需软件的详细清单。(若适用)用软件名称、标识号、版本号、发行号、配置、密级来标识这些软件。同时应标识这些软件是现场应具备的，还是为安装而交付的，并标识仅仅为了方便安装过程要使用的所有软件。4.x.3设施本条应详细描述安装期间所需的物理设施和食宿供应，(若适用)应包括以下内容： GB/T8567-2006《计算机软件文档编制规范》a.所需的教室、工作场所、培训辅助工具、每天的工作时间、工作天数和轮班安排；b.必须的可运转的和可用的硬件设备；c.安装队伍的交通和食宿安排。4.x.4安装队伍本条应描述安装队伍的组成情况。确定每个队伍成员的任务。4.x.5安装过程本条应描述完成安装的逐步过程。可引用其他文档，如操作员手册，在适当的地方包含有“警告”或“注意”标记作为安全提示。(若适用)安装过程为：a.软件安装；b.安装后做软件检验；c.用现场专用的数据初始化数据库和其他软件；d.从现行系统进行转换，可能涉及到新老系统并行运行；e.对操作手册和用户手册中的过程作演练性运行。4.x.6数据更新过程本条应描述安装期间要遵循的数据更新过程。如果数据更新过程与一般的更新或处理过程相同，可以引用其他文档，如操作员手册。5软件用户的现场专用信息本章应描述针对软件用户的安装计划。当涉及多种类型的用户时，例如不同地点的用户、执行不同功能的用户或属于不同组织的用户，应为每一类用户单独编写一章(从第5章到第n章)，并针对每一用户使用贴切的章标题。5.x现场名本条应标识一个或一组现场，再分条对其进行讨论。当这些地点的信息基本相同时，可合在一起进行讨论。5.x.1进度表本条应给出安装期间用户所完成任务的进度要求。按照每个任务的开始日期和完成日期的时间顺序描述，并加以必要的叙述。5.x.2安装过程本条应描述完成安装的逐步过程。可参考其他文档，如用户手册，在适当的地方包含有”警告”或”注意”标记作为安全提示。(若适用)安装过程为：a.如果操作员未曾执行过4.x.5条下的任务的话，则在此执行该项任务；b.初始化特定于用户的数据；c.设置查询和其他用户输入；d.进行样本处理；e.生成样本报告；f.从现行系统进行转换，可能涉及到新老系统并行运行；g.对用户手册中的过程作演练性运行。5.x.3数据更新过程本条应分条描述安装期间要遵循的用户数据更新过程。如果数据更新过程与一般的处理过程相同，可以引用其他文档，如用户手册和本文档的第4章等。6注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。如果第5章已经扩展到第6至n章，则本章应编号为第n章的下一章。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A，B等)编排。 GB/T8567-2006《计算机软件文档编制规范》7.5软件移交计划(STrP)说明：1.《软件移交计划)(STrP)指出可交付软件的生存周期支持所需要的硬件、软件和其他资源。描述开发方向支持部门移交应交付项目的计划。2.仅当软件支持概念要求把责任从开发方移交到一个独立的支持方时，才需要制定STrP。STrP可供需方用来修改计算机资源生存期管理计划。软件移交计划的正文的格式如下：1引言本章分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档.1.3文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性或私密性要求。1.4与其他计划之间的关系(若有)本条应描述本计划和其他项目管理计划的关系。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。3软件支持资源本章应分条标识和描述为了支持可交付软件所需的资源。这些资源应包括为了控制、复制和分发软件和相应的文档所需的资源，以及说明、设计、实现、文档编制、测试、评估、控制、复制和分发软件修改所需的资源。3.1设施本条应描述为了支持可交付软件所需的设施。这些设施包括：特殊的建筑、房间、实物模型、诸如升降地板或电缆的建筑特性、支持保密性和私密性需求的建筑特性(屏蔽层、地下室等)、支持安全性需求的建筑特性(烟雾报警器、安全灯等)和特殊的电源需求等。应描述每项的用途，(若适用)可包括图表。3.2硬件本条应标识和描述为了支持可交付软件所需的硬件和相关文档。硬件包括：计算机、外围设备、硬件模拟器、激发器、仿真器、诊断设备和非计算机设备。描述内容应包括：a.具体的型号、版本与配置；b.选择该硬件的理由；(若适用)对用户/操作员手册的引用或每项的说明；d.标识出需方所提供的硬件和文档、应交付给支持机构的项目、支持机构已有的项目、支持机构必须得到的项目或其他的状态描述；e.如果硬件项目是必须要得到的，则要给出当前供货来源信息，包括硬件项目现在是否可获得和交付时是否为期望获得的；f.关于制造商提供支持、许可证和资料版权等信息，包括制造商在当前和在交付时能否提供支持，能否给予支持机构许可证和许可证的限期等都必须加以说明；g.保密性、私密性方面的考虑、限制或其他感兴趣的条款。3.3软件本条应标识和描述为了支持可交付软件所需的软件和相关文档。软件包括：计算机辅助软件工程(CASE) GB/T8567-2006《计算机软件文档编制规范》工具,CASE工具中的资料、编译程序、测试工具、测试数据、模拟器、仿真器、实用程序、配置管理工具、数据库和数据文件以及其他软件。描述内容应包括：a.(若适用的话)具体名称、标识号、版本号、发行号及配置；b.选择该软件的理由；c.(若适用)对用户/操作员手册的引用或每项的说明；d.标识出需方所提供的软件和文档、应交付给支持机构的项目、支持机构已有的项目、支持机构必须得到的项目或其他的状态描述；e.如果软件项目是必须要得到的，则要给出当前供货来源信息，包括软件项目现在是否可获得和交付时是否可期望获得的；f.关于制造商提供的支持、许可证、资料版权的信息，包括制造商在当前和在交付时能否提供支持，能否给予支持机构许可证和许可证的限期等都必须加以说明；g.保密性、私密性方面的考虑、限制或其他感兴趣的条款。3.4其他文档本条应标识描述为了支持可交付软件所需的其他文档。例如，清单应包括可交付软件的计划、报告、研究材料、规格说明、设计说明、测试用例/测试过程、测试报告、用户/操作员手册和支持手册。本条应提供：a.(若适用)名称、标识号、版本号和发行号；b.清单中收人每个文档的理由；c.标识出需方所提供的文档、应交付给支持机构的项目、支持机构已有的项目、支持机构必须得到的项目或其他的状态描述；d.如果文档是必需要得到的，说明从哪里能得到它；e.有关许可证和资料版权的信息；f.保密性、私密性方面的考虑、限制或其他感兴趣的条款。3.5人员本条应描述为了支持可交付软件所需的人员，包括预期的人员数量、技能和专长的类型和级别、涉密审查。(若适用)应以实际参与项目开发的人员为基础来估计所需的人员。3.6其他资源本条应标识为了支持可交付软件所需的其他资源，包括磁带和磁盘等易耗品，估计所需资源的类型和数量。3.7各组成部分之间的相互关系本条应标识前面各条所标识的各个组成部分之间的关系。可以用图表形式表示这些关系。4推荐的过程本章应根据需要分条描述为了支持可交付软件和相关的支持环境，开发方希望向支持机构推荐的过程，包括建议和教训。5培训本章应适当地分成若干条描述开发方培训支持人员使其能够支持可交付软件的计划。内容包括：a.培训的进度安排、期限和地点；b.描述课程培训和实习培训；c.规定的预备条件(直接或引用)：1)熟悉运行软件和目标计算机；2)熟悉支持软件和宿主系统。6预期的变更区域本章应描述可交付软件预期的变更区域。7移交计划本章应根据需要分条描述开发方把可交付软件移交给支持机构的计划。按以下内容描述：a.为向支持机构移交可交付软件而要执行的所有活动，这些活动可能包括计划/协调会议，要交付给支持 GB/T8567-2006《计算机软件文档编制规范》机构的项的准备，软件支持环境的包装、运输、安装和检测，运行软件的包装、运输、安装和检测，以及支持人员的培训等；b.每项活动的角色和职责；c.执行移交活动所需的资源及这些资源的来源；d.实现移交活动的进度表和里程碑。进度表和里程碑必须与合同中的总进度一致；e.在支持环境中安装和检测可交付项的过程。8注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.6运行概念说明(OCD)说明：1.《运行概念说明》(OCD)从以下几方面描述一个建议的系统：说明它能满足用户什么需要，它与现有系统或过程的关系，以及它的使用方式等。2.OCD旨在需方、开发方、支持方和用户代理之间对所建议的系统的运行机理取得共识。取决于使用的目的,OCD可专注于向开发者表述用户的需求；或专注于向用户或其他感兴趣的对象表达开发者的思路。术语“系统”也可理解为系统的一部分。运行概念说明的正文的格式如下：1引言本章应分为以下几条。1.1标识本条应包含本文档适用系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语，版本号和发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。1.3文档概述本条应概括本文档的用途和内容，并描述与它的使用有关的保密性或私密性要求。2引用文件本章应列出本文档引用所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。3现行系统或状态本章分以下几条描述现行系统或状态。3.1背景、目标和范围本条应描述现行系统或状态的背景、任务或目标和范围。3.2运作策略和约束本条应描述适用于现行系统或状态的运作策略和约束。3.3现行系统或状态描述本条应给出现行系统或状态的描述，标识出不同运行状态和方式的差异(例如：常规、维护、训练、降级、紧急事件和备选场点)。状态和方式之间的区别是任意的，可以仅按状态描述系统，也可以仅按方式、方式中的状态、状态中的方式或其他有用的方式描述系统。如果系统不是以多种状态和方式运行，本条应如实陈述，而不需要进行人为的区分。描述包括以下内容： GB/T8567-2006《计算机软件文档编制规范》a.运行环境及其特性；b.主要的系统部件及这些部件之间的互连；c.与外部系统或过程的接口；d.现行系统的能力/功能；e.描述输入、输出、数据流、手工和自动处理的图表和相应的说明，使用户能够充分理解现行系统和状态；f.性能特性，如：速度、吞吐量、容量和频率；g.质量属性，例如：可靠性、可维护性、可用性、灵活性、可移植性、易用性和有效性；h.安全性、保密性、私密性和紧急情况下运行连续性的规定。3.4用户或相关人员本条应描述系统用户的类型或当前状态下所涉及到的人员(若适用)，包括：组织结构、培训/技能、职责、活动及彼此之间的交互。3.5支持概念本条应简述现行系统的支持概念，若适用于本文档，应包括：支持机构，设施，设备，支持软件，修复/替换准则，维护等级和周期，存储、分发和供应方法。4变更理由和种类本章应分以下几条。4.1变更理由本条应：a.描述需要新建或修改系统的用户需求、威胁、任务、目标、环境、接口、人员或其他因素的新的或修改的方面；b.简述现行系统或现状不能满足上述因素的不足和约束。4.2所需变更的说明本条应简述能满足4.1中所标识因素的新建的或修改的能力/功能、处理、接口或其他所需的变更。4.3变更之间的优先级别本条应指出所需变更之间优先级别。例如：把每个变更标识为本质的、期望的或可选的，对期望的和可选的变更给出优先级别。4.4考虑过但未纳入的变更应指出曾考虑过，但未包含在4.2中的变更，说明未包括它们的理由。4.5假设和约束对于适用于本章所标识的变更，本条应标识有关假设和约束。5新系统或修改后系统的概念本章应分以下各条描述新系统或修改后系统。5.1背景、目标和范围本条应描述新系统或修改后系统的背景、任务或目标和范围。5.2运行策略和约束本条应描述适用于新系统或修改后系统的运行策略和约束。5.3新系统或修改后系统的描述本条应提供对新系统或修改后系统的描述，标识出不同运行状态和方式的差异(例如：常规、维护、培训、降级、紧急事件、备选场点等)。状态和方式之间的区别是任意的，可以仅按状态描述系统，也可以仅按方式、方式中的状态、状态中的方式或其他有用的方式描述系统。如果系统的运行不是以多种状态和方式，本条应如实陈述，而不需要进行人为的区分。(若适用)描述包括以下的内容：a.运行环境及其特性；b.主要系统部件及这些部件之间的互连；c.与外部系统或过程的接口；d.新系统或修改后系统的能力/功能； GB/T8567-2006《计算机软件文档编制规范》e.描述输入、输出、数据流、手工和自动处理的图表和相应的说明，使用户能够充分理解新系统或修改后系统；f.性能特性，如：速度、吞吐量、容量和频率；g.质量属性，例如：可靠性、可维护性、可用性、灵活性、可移植性、易用性和有效性；h.安全性、保密性、私密性和紧急情况下运行连续性的规定。5.4用户/受影响人员本条应描述新系统或修改后系统的用户类型，(若适用)包括：组织结构、培训技能、职责和相互之间的交互。5.5支持概念本条应简述新系统或修改后系统的支持概念，(若适用)应包括：支持机构，设施，设备，支持软件，维修/更换标准，维护等级和周期，存储、分配和供应方法。6运行场景本章应描述一个或几个运行场景，举例说明新系统或修改后系统的作用、与用户的交互、与其他系统的接口和为该系统标识的所有状态或方式。(若适用)场景应包括：事件、动作、触发器、信息和交互等。可以使用影像等其他媒体来提供这些信息中的部分或全部。7影响综述本章应分以下几条。7.1操作方面的影响本条应描述对用户、需方、开发方和支持机构的可预计的操作影响。这些影响包括：与计算机操作中心接口的变化；过程的变化；新数据源的使用；输入到系统中的数据在数量、类型和时序上的变化；数据保留需要的变化；以及在紧急情况等条件下新的运行方式。7.2组织影响本条应描述对用户、需方、开发方和支持机构的可预计的组织影响。这些影响包括：职责的修改；职责或岗位的增加和撤销；培训或再培训的需要；在各种运行方式下人员在数量、技能级别、岗位标识和地点等方面的变化。7.3开发期间的影响本条应描述在系统开发工作中对用户、需方、开发方和支持机构可预计的影响。这些影响包括：关于新系统的会议/讨论；数据库的开发和修改；培训；新系统和现有系统的并行运行；对新系统测试期间的影响以及帮助或监控开发所需的其他活动。8建议系统的分析8.1优点概述本条应对新系统或修改后系统的优点提供定性和定量的总结，包括：新增的功能、增强的功能、改善的性能，(若适用)以及与在4.1中确认的缺陷的关系。8.2缺点/限制概述本条应对新系统或修改后系统的缺点或约束进行定性和定量概述，包括：降级或缺少的功能；降级或达不到期望的性能；高于期望的计算机硬件资源的使用；出现了不想要的运行影响；与用户假设的冲突；其他的约束条件。8.3应考虑的变通和折衷本条应标识和描述对系统或其特性应考虑的主要的变通办法，在其间所做的折衷以及作出决定的依据。9注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档所需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。 GB/T8567-2006《计算机软件文档编制规范》7.7系统/子系统需求规格说明(SSS)说明：1.《系统/子系统需求规格说明》(SSS)为一个系统或子系统指定需求和指定保证每个需求得到满足所使用的方法。与系统或子系统外部接口相关的需求可在SSS中或在该SSS引用到的一个或多个《接口需求规格说明》(IRS)中给出。2.这个SSS，可能还要用《接口需求规格说明》(IRS)加以补充，是构成系统或子系统设计与合格性测试的基础。贯穿本文的术语“系统”，如果适用的话，也可解释为“子系统”。所形成的文档应冠名为“系统需求规格说明”或“子系统需求规格说明”。系统/子系统需求规格说明的正文的格式如下：1引言本章分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、操作和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划中的运行现场；列出其他有关的文档。1.3文档概述本条应概括本文档的用途和内容，并描述与其使用有关的保密性和私密性要求。2引用文件本章应列出本文档所引用所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。3需求本章分条详述系统需求，是指功能、业务(包括接口、资源、性能、可靠性、安全性、保密性等)和数据需求。也就是，构成系统验收条件的系统特性。给每个需求指定项目唯一标识符以支持测试和可追踪性。并以一种可以定义客观测试的方式来陈述需求。对每个需求都应说明相关合格性方法(见第4章)，如果是子系统，则还要给出从该需求至系统需求的可追踪性(见5.a条)。描述的详细程度遵循以下规则：应包含构成系统验收条件的那些系统特性，需方愿意推迟到设计时留给开发方说明的那些特性。如果在给定条中没有需求可说明的话，应如实陈述。如果某个需求在多条中出现，可以只陈述一次而在其他条中引用之。3.1要求的状态和方式如果要求系统在多种状态和方式下运行，且不同状态和方式具有不同的需求的话，则要标识和定义每一状态和方式。状态和方式的例子包括：空闲、就绪、活动、事后分析、训练、降级、紧急情况和后备等。状态和方式的区别是任意的，可以仅用状态描述系统，也可以仅用方式、方式中的状态、状态中的方式或其他有效的方式描述。如果不需要多个状态和方式，不需人为加以区分，应如实陈述；如果需要多个状态和/或方式，还应使本规格说明中的每个需求或每组需求与这些状态和方式相关联，关联可在本条或本条引用的附录中用表格或其他的方法表示，也可在需求出现的地方加以注解。3.2需求概述3.2.1系统总体功能和业务结构描述系统总体功能和业务的结构。3.2.2硬件系统的需求说明对硬件系统的需求。3.2.3软件系统的需求说明对软件系统的需求。3.2.4接口需求说明硬件系统和软件系统之间的接口。 GB/T8567-2006《计算机软件文档编制规范》3.3系统能力需求本条应分条详细描述与系统每一能力相关联的需求。“能力”被定义为一组相关的需求。可以用“功能”、“性能”、“主题”、“目标”或其他适合用来表示需求的词来替代“能力”。3.3.x(系统能力)本条应标识必需的每一系统能力，并详细说明与该能力有关的需求。如果该能力可以更清晰地分解成若干子能力，则应分条对子能力进行说明。该需求应指出所需的系统行为，包括适用的参数，如响应时间、吞吐时间、其他时限约束、序列、精度、容量(大小/多少)、优先级别、连续运行需求和基本运行条件下的允许的偏差；(若适用)需求还应包括在异常条件、非许可条件或越界条件下所需的行为，错误处理需求和任何为保证在紧急时刻运行的连续性而引人到系统中的规定。在确定与系统所接收的输入和系统所产生的输出有关的需求时，应考虑在本文档3.4.x给出要考虑的主题列表。3.4系统外部接口需求本条应分条描述关于系统外部接口的需求(如有的话)。本条可引用一个或多个接口需求规格说明(IRS)或包含这些需求的其他文档。3.4.1接口标识和接口图本条应标识所需的系统外部接口。(若适用)每个接口标识应包括项目唯一标识符，并应用名称、序号、版本和引用文件指明接口的实体(系统、配置项和用户等)。该标识应说明哪些实体具有固定的接口特性(因而要对这些接口实体强加接口需求)，哪些实体正被开发或修改(从而接口需求已被施加于它们)。可用一个或多个接口图表来描述这些接口。3.4.x(接口的项目唯一标识符)本条(从3.4.2开始)应通过项目唯一标识符标识系统的外部接口，简单地标识接口实体，根据需要可分条描述为实现该接口而强加于系统的需求。该接口所涉及的其他实体的接口特性应以假设、或“当(未提到实体)这样做时，系统将„„”的形式描述，而不描述为其他实体的需求。本条可引用其他文档(如：数据字典、通信协议标准和用户接口标准)代替在此所描述的信息。(若适用)需求应包括下列内容，它们以任何适合于需求的顺序提供，并从接口实体的角度说明这些特性的区别(如对数据元素的大小、频率或其他特性的不同期望)：a.系统必须分配给接口的优先级别；b.要实现的接口的类型的需求(如：实时数据传送、数据的存储和检索等)；c.系统必须提供、存储、发送、访问、接收的单个数据元素的特性，如：1)名称/标识符；a)项目唯一标识符；b)非技术(自然语言)名称；c)标准数据元素名称；d)技术名称(如代码或数据库中的变量或字段名称)；e)缩写名或同义名；2)数据类型(字母数字和整数等)；3)大小和格式(如：字符串的长度和标点符号)；4)计量单位(如：米、元、秒)；5)范围或可能值的枚举(如：0~99)；6)准确度(正确程度)和精度(有效数字位数)；7)优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素是否可被更新、业务规则是否适用；8)保密性和私密性的约束；9)来源(设置/发送实体)和接收者(使用/接收实体)；d.系统必须提供、存储、发送、访问和接收的数据元素集合体(记录、消息、文件、数组、显示和报表等)的特性，如：1)名称/标识符；a)项目唯一标识符； GB/T8567-2006《计算机软件文档编制规范》b)非技术(自然语言)名称；c)技术名称(如代码或数据库的记录或数据结构)；d)缩写名或同义名；2)数据元素集合体中的数据元素及其结构(编号、次序和分组)；3)媒体(如盘)和媒体中数据元素/数据元素集合体的结构；4)显示和其他输出的视听特性(如：颜色、布局、字体、图标和其他显示元素、蜂鸣声和亮度等)；5)数抿元素集合体之间的关系。如排序/访问特性；6)优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素集合体是否可被修改、业务规则是否适用；7)保密性和私密性约束；8)来源(设置/发送实体)和接收者(使用/接收实体)；e.系统必须规定接口使用的通信方法所要求的特性。如：1)项目唯一标识符；2)通信链接/带宽/频率/媒体及其特性；3)消息格式化；4)流控制(如：序列编号和缓冲区分配)；5)数据传送速率，周期性/非周期性，传输间隔；6)路由、寻址和命名约定；7)传输服务，包括：优先级别和等级；8)安全性/保密性/私密性方面的考虑，如：加密、用户鉴别、隔离和审核等；f.系统必须规定接口使用的协议所要求的特性，如：1)项目唯一标识符；2)协议的优先级别/层次；3)组，包括：分段和重组、路由和寻址；4)合法性检查、错误控制和恢复过程；5)同步，包括：连接的建立、保持和终止；6)状态、标识、任何其他的报告特征；g.其他所需的特性，如：接口实体的物理兼容性(尺寸、公差、负荷、电压和接插件兼容性等)。3.5系统内部接口需求本条应指明系统内部接口的需求。如果所有内部接口留到设计时或在系统成分的需求规格说明中规定，那么必须如实说明。如果实施这样的需求，则可考虑本文档的3.4列出的主题。3.6系统内部数据需求本条应指明分配给系统内部数据的需求(若有)，包括对系统中数据库和数据文件的需求。如果所有有关内部数据的决策都留待设计时或留待系统部件的需求规格说明中给出，则需在此如实说明。如果要强加这种需求，则可考虑在本文档的3.4.x.c和3.4.x.d列出的主题。3.7适应性需求(若有)本条应指明要求系统提供的、与安装有关的数据(如：现场的经纬度)和要求系统使用的、根据运行需要可能变化的运行参数(如：表示与运行有关的目标常量或数据记录的参数)。3.8安全性需求(若有)本条应描述有关防止对人员、财产、环境产生潜在的危险或把此类危险减少到最低的系统需求，包括：危险物品使用的限制；为运输、操作和存储的目的而对爆炸物品进行分类；异常中止/异常出口规定；气体检测和报警设备；电力系统接地；排污；防爆(若适用)。描述还应包括有关系统核部件(若有)的需求，如：部件设计、意外爆炸的预防以及与核安全规则保持一致。3.9保密性和私密性需求(若有)本条应指明维持保密性和私密性的系统需求，包括：系统运行的保密性/私密性环境、提供的保密性或私密性的类型和程度、系统必须经受的保密性/私密性的风险、减少此类危险所需的安全措施、系统必须 GB/T8567-2006《计算机软件文档编制规范》遵循的保密性/私密性政策、系统必须提供的保密性/私密性审核以及保密性/私密性必须遵循的确认/认可准则。3.10操作需求说明本系统在常规操作、特殊操作以及初始化操作和恢复操作等方面的要求。3.11可使用性、可维护性、可移植性、可靠性和安全性需求说明本系统在可使用性、可维护性、可移植性、可靠性和安全性等方面的要求。3.12故障处理需求说明本系统在发生可能的软硬件故障时，对故障处理的要求。3.12.1软件系统出错处理说明属于软件系统的问题；给出发生错误时的错误信息；说明发生错误时可能采取的补救措施。3.12.2硬件系统冗余措施的说明说明哪些问题可以由硬件设计解决，并提出可采取的冗余措施；对硬件系统采取的冗余措施加以说明。3.13系统环境需求(若有)本条应指明系统运行必须的与环境有关的需求。对软件系统而言，运行环境包括支持系统运行的计算机硬件和操作系统(其他有关计算机资源方面的需求在下条描述)。对硬软件系统而言，运行环境包括系统在运输、存储和操作过程中必须经受的环境条件，如：自然环境条件(风、雨、温度、地理位置)、诱导环境(运动、撞击、噪音、电磁辐射)和对抗环境(爆炸、辐射)。3.14计算机资源需求本条应分条进行描述。根据系统性质，在以下各条中所描述的计算机资源应能够组成系统环境(对应软件系统)或系统部件(对应硬软件系统)。3.14.1计算机硬件需求本条应描述系统使用的或引人到系统中的计算机硬件需求，(若适用)包括：各类设备的数量、处理器、存储器、输入/输出设备、辅助存储器、通信/网络设备、其他所需的设备的类型、大小、能力(容量)及其他所要求的特征。3.14.2计算机硬件资源利用需求本条应描述系统的计算机硬件资源利用方面的需求，如：最大许可使用的处理器能力、存储器容量、输入/输出设备能力、辅助存储器容量和通信/网络设备能力。这些要求(如每个计算机硬件资源能力的百分比)还包括测量资源时所要求具备的条件。3.14.3计算机软件需求本条应描述系统必须使用或引人系统的计算机软件的需求，例如包括：操作系统、数据库管理系统、通信/网络软件、实用软件、输入和设备模拟器、测试软件和生产用软件。必须提供每个软件项的正确名称、版本和引用文件。3.14.4计算机通信需求本条应描述系统必须使用的或引人系统的计算机通信方面的需求，例如包括：连接的地理位置、配置和网络拓扑结构、传输技术、数据传输速率、网关、要求的系统使用时间、传送/接收数据的类型和容量、传送/接收/响应的时间限制、数据的峰值和诊断功能。3.15系统质量因素(若有)本条应描述系统质量因素方面的需求，例如包括：系统的功能性(实现全部所需功能的能力)、可靠性(产生正确、一致结果的能力„„如设备故障的平均间隔时间)、可维护性(易于服务、修改、更正的能力)、可用性(需要时进行访问和操作的能力)、灵活性(易于适应需求变化的能力)、软件可移植性(易于适应新环境变化的能力)、可重用性(在多个应用中使用的能力)、可测试性(易于充分测试的能力)、易用性(易于学习和使用的能力)和其他属性等的定量需求。3.16设计和构造的约束 GB/T8567-2006《计算机软件文档编制规范》(若有)本条应描述约束系统设计和构造的那些需求。对硬软件系统而言，本条应包括强加于系统的物理需求，这些需求可通过引用适当的商用标准和规范来指定。需求包括：a.特殊系统体系结构的使用或对体系结构方面的需求，例如：需要的子系统；标准部件、现有部件的使用；政府/需方提供的资源(设备、信息、软件)的使用；b.特殊设计或构造标准的使用；特殊数据标准的使用；特殊编程语言的使用；工艺需求和生产技术；c.系统的物理特性(如：重量限制、尺寸限制、颜色、保护罩)；部件的可交换性；从一地运输到另一地的能力；由单人或一组人携带或架设的能力；d.能够使用和不能使用的物品；处理有毒物品的需求以及系统产生电磁辐射的允许范围；e.铭牌、部件标记、系列号和批次号的标记、其他标识标记的使用；f.为支持在技术、威胁和任务等方面预期的增长和变化而必须提供的灵活性和可扩展性。3.17相关人员需求(若有)本条应描述与使用或支持系统的人员有关的需求，包括人员的数量、技术等级、责任期、培训需求、其他的信息，如：所提供的工作站数量、内在帮助和培训能力的需求八若有)还应包括强加于系统的人力行为工程需求。这些需求包括对人员在能力与局限性方面的考虑；在正常和极端条件下可预测的人为错误；人为错误造成严重影响的特定区域，例如对高度可调的工作站、错误消息的颜色和持续时间、关键指示器或键的物理位置以及听觉信号的使用需求。3.18相关培训需求(若有)本条应描述有关培训方面的系统需求。包括：系统中应包括的培训设备和培训材料。3.19相关后勤需求(若有)本条应描述有关后勤方面的系统需求，包括：系统维护、软件支持、系统运输方式、补给系统要求、对现有设施的影响、对现有设备的影响。3.20其他需求(若有)本条应描述在以上各条中没有涉及到的其他系统需求，包括在其他合同文件中没有涉及的系统文档的需求，如：规格说明、图表、技术手册、测试计划和测试过程以及安装指导材料。3.21包装需求(若有)本条应描述需交付的系统及其部件在包装、加标签和处理方面的需求。(如适用)可引用适当的规范和标准。3.22需求的优先次序和关键程度(若适用)本条应给出本规格说明中需求的、表明其相对重要程度的优先顺序、关键程度或赋予的权值，如：标识出那些认为对安全性、保密性或私密性起关键作用的需求，以便进行特殊的处理。如果所有需求具有相同的权值，本条应如实陈述。4合格性规定本章定义一组合格性方法，对于第3章中每个需求，指定为了确保需求得到满足所应使用的方法。可以用表格形式表述该信息，也可以在第3章的每个需求中注明要使用的方法。合格性方法包括：a.演示：依赖于可见的功能操作，直接运行系统或系统的一部分而不需要使用仪器、专用测试设备或进行事后分析。b.测试：使用仪器或其他专用测试设备运行系统或系统的尸部分，以便采集数据供事后分析使用。c分析：对从其他合格性方法中获得的积累数据进行处理，例如测试结果的归约、解释或推断。d.审查：对系统部件、文档等进行可视化检查。e.特殊的合格性方法。系统的任何特殊合格性方法，如：专用工具、技术、过程、设施、验收限制、标准样例的使用和生成等。5需求可追踪性对系统级的规格说明，本章不适用；对子系统级的规格说明，本章应包括：a.从本规格说明中每个子系统需求到其涉及的系统需求的可追踪性。(该可追踪性也可以通过对第3章中的每个需求进行注释的方法加以描述。)注：每一层次的系统改进可能导致对更高层次的需求不能直接进行追踪。例如：建立两个子系统的系统 GB/T8567-2006《计算机软件文档编制规范》体系结构设计可能会产生有关子系统接口的需求，而这些接口需求在系统需求中并没有被覆盖，这样的需求可以被追踪到诸如“系统实现”这样的一般需求，或被追踪到导致它们产生的系统设计决策上。b.从分配给被本规格说明所覆盖的子系统的每个系统需求到所涉及的子系统需求的可追踪性。分配给子系统的所有系统需求都应加以说明。追踪到接口需求规格说明(IRS)中所包含的子系统需求时，可引用IRS.6非技术性需求本章应包括：a.交付日期；b.里程碑点。7尚未解决的问题如需要，可说明系统需求中的尚未解决的遗留问题。8注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档所需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.8接口需求规格说明(IRS)说明：1.《接口需求规格说明》(IRS)描述为实现一个或多个系统、子系统、硬件配置项HWCI,计算机软件配置项CSCI、手工操作、其他系统部件之间的一个或多个接口，而强加在这些实体上的需求。2.这个IRS,还可以被用来补充《系统/子系统需求规格说明》(SSS)及《软件需求规格说明》(SRS)，作为系统和CSCI设计与合格性测试的基础。接口需求规格说明的正文的格式如下：1引言本章分为以下几条。1.1标识本条应包含本文档适用的系统接口实体和接口的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。1.3文档概述本条应概述本文档的用途和内容，并描述本文档使用过程中有关保密性或私密性要求。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。3需求本章应分以下几条详细说明为实现一个或多个系统、子系统、配置项、手工操作、其他系统部件之间的一个或多个接口而强加在这些实体上的需求。应为每个需求指定一个项目唯一标识符以支持测试和可追踪性，并且应以一种可以定义客观测试的方式来陈述需求。如果每个需求有关的合格性方法(见第4章)和对系统(或子系统)需求的可追踪性(见5.a条)在相应的章中没有提供的话，则应在此进行注解。描述的详细程度应遵循以下规则：包含作为接口实体的验收条件的那些接口实体特性；需方愿意推迟到设计时留给开发方处理的那些接口实体特性。如果某个需求在多条中出现，可以只陈述一次，而在其他条中加以引用。如果本说明中的接口实体要在彼此有着不同接口需求的状态和/或方式下运行的话，则该实体的每个需求或每组需求应与那些状态 GB/T8567-2006《计算机软件文档编制规范》和方式相关联，该关联可以在本条或本条引用的附录中用表格或其他方法给出；也可以在需求出现的地方加以注解。3.1接口标识和接口图对于本文档1.1中标识的每个接口，本条应包含项目唯一标识符，(若适用)并应用名字、编号、版本、文档引用指明接口实体(系统、配置项、用户等)。该标识应说明哪些实体具有固定的接口特性(因而要对这些接口实体强加接口需求)，哪些实体正被开发或修改(从而接口需求已被施加于它们)。可用一个或多个接口图来描述这些接口。3.x(接口的项目唯一标识符)本条(从3.2开始编号)应通过项目唯一标识符标识接口，应简要标识接口实体，并应根据需要划分为几条描述为实现该接口而强加于一个或多个接口实体的需求。如果某个实体的接口特性本文没有提及，但是需要在描述本文所包含的接口实体时提到，则这些特性应以假设、或“当[未提及实体]这样做时，[正在描述的实体]将„„”的形式描述，而不是描述成本文未提及实体的需求。本条可引用其他文档(例如数据字典、协议标准、用户接口标准)代替本条的描述信息。(若适用)本需求应包括以下内容，它们可以任何适合于需求的顺序提供，并且应从接口实体角度指出这些特性之间的区别(例如数据元素的大小、频率或其他特性的不同期望)：a.接口实体必须分配给接口的优先级别；b.要实现的接口的类型的需求(如：实时数据传送、数据的存储和检索等)；c.接口实体必须提供、存储、发送、访问和接收的单个数据元素的特性，如：1)名称/标识符；a)项目唯一标识符；b)非技术(自然语言)名称；c)标准数据元素名称；d)技术名称(如代码或数据库中的变量或字段名称)；e)缩写名或同义名；2)数据类型(字母数字、整数等)；3)大小和格式(如：字符串的长度和标点符号)；4)计量单位(如：米、元、纳秒)；5)范围或可能值的枚举(如：0~99)；6)准确度(正确程度)和精度(有效数字位数)；7)优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素是否可被更新、业务规则是否适用；8)保密性和私密性的约束；9)来源(设置/发送实体)和接收者(使用/接收实体)；d.接口实体必须提供、存储、发送、访问和接收的数据元素集合体(记录、消息、文件、显示和报表等)的特性，如：1)名称/标识符；a)项目唯一标识符；b)非技术(自然语言)名称；c)技术名称(如代码或数据库的记录或数据结构)；d)缩写名或同义名；2)数据元素集合体中的数据元素及其结构(编号、次序、分组)；3)媒体(如盘)和媒体中数据元素/数据元素集合体的结构；4)显示和其他输出的视听特性(如：颜色、布局、字体、图标和其他显示元素、蜂鸣声和亮度等)；5)数据元素集合体之间的关系。如排序/访问特性；6)优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素集合体是否可被修改、业务规则是否适用；7)保密性和私密性约束； GB/T8567-2006《计算机软件文档编制规范》8)来源(设置/发送实体)和接收者(使用/接收实体)；e.接口实体必须为接口使用通信方法的特性。如：l)项目唯一标识符；2)通信链接/带宽/频率/媒体及其特性；3)消息格式化；4)流控制(如：序列编号和缓冲区分配)；5)数据传送速率，周期性/非周期性，传输间隔；6)路由、寻址和命名约定；7)传输服务，包括：优先级别和等级；8)安全性/保密性/私密性方面的考虑，如：加密、用户鉴别、隔离和审核等；f.接口实体必须为接口使用协议的特性，如：1)项目唯一标识符；2)协议的优先级别/层次；3)分组，包括：分段和重组、路由和寻址；4)合法性检查、错误控制和恢复过程；5)同步，包括：连接的建立、保持和终止；6)状态、标识、任何其他的报告特征；g.其他所需的特性，如：接口实体的物理兼容性(大小、容限、负荷、电压和接插件兼容性等)。3.y需求的优先顺序和关键程度本条应编号为第3章的最后一条，(若适用)应给出本规格说明中需求的、表明其相对重要程度的优先顺序、关键程度或赋予的权值，如：标识出那些认为对安全性、保密性或私密性起关键作用的需求，以便进行特殊的处理。如果所有需求具有相同的权值，本条应如实描述。4合格性规定本章定义一组合格性方法，并应对第3章中每个需求指定为了确保需求得到满足所应使用的方法。可以用表格形式提供该信息，也可以在第3章的每个需求中注明其使用方法。合格性方法包括：a.演示：依赖于可见的功能操作，直接运行接口实体而不需要使用仪器、专用测试设备或进行事后分析；b.测试：使用仪器或其他专用测试设备运行接口实体为以后的分析收集数据；c.分析：对从其他合格性方法中获得的积累数据进行处理，例如测试结果的归约、解释或推论；d.审查：对接口实体、文档等进行可视化检查；e.特殊的合格性方法：任何应用到接口实体的特殊合格性方法，如：专用工具、技术、过程、设施和验收限制。5需求可追踪性本章不适用于系统级的接口实体。对本文中的子系统级或更低级的接口实体，本章应包括：a.从强加于本规格说明中实体上的每个需求到它所涉及的系统(或子系统)需求的可追踪性。(该可追踪性也可以通过对第3章中的每个需求进行注释的方法加以描述)；注：每个层次的系统细化都可能导致对更高层次的需求不能直接进行追踪。例如：建立多个CSCI的系统体系结构设计可能会产生有关CSCI如何接口的需求，即使在系统需求中没有覆盖这些接口。这样的需求可被追踪到诸如“系统实现”这样的一般需求，或被追踪到导致它们产生的系统设计决策上.b.从分配给接口实体的并影响本规格说明中某个接口的每个系统(或子系统)需求，到本规格说明中涉及它的接口需求的可追踪性。6注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在本文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。 GB/T8567-2006《计算机软件文档编制规范》7.9系统/子系统设计(结构设计)说明(SSDD)说明：1.《系统/子系统设计(结构设计)说明》(SSDD)描述了系统或子系统的系统级或子系统级设计与体系结构设计。SSDD可能还要用《接口设计说明》(IDD)和《数据库(顶层)设计说明》(DBDD)加以补充。2.SSDD连同相关的IDD和DBDD是构成进一步系统实现的基础。贯穿本文的术语“系统，，如果适用的话，也可解释为“子系统”。所形成的文档应冠名为“系统设计说明”或“子系统设计说明”。系统/子系统设计(结构设计)说明的正文的格式如下：1引言本章分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发布号。1.2系统概述本条应简述本文档适用的系统和软件的用途，它应包括：描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划中的运行现场；列出其他有关的文档。1.3文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性或私密性要求。1.4基线说明编写本系统设计说明书依据的设计基线。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。3系统级设计决策本章可根据需要分条描述系统级设计决策，即系统行为的设计决策(忽略其内部实现，从用户角度出发，描述系统将怎样运转以满足需求，)和其他对系统部件的选择和设计产生影响的决策。如果所有这些决策在需求中明确指出或推迟到系统部件的设计时给出的话，本章应如实陈述。对应于指定为关键性需求(如安全性、保密性和私密性需求)的设计决策应在单独的条中描述。如果设计决策依赖于系统状态或方式，应指明这种依赖关系。应给出或引用为理解这些设计所需要的设计约定。系统级设计决策例子如下：a.有关系统接收的输入和产生的输出的设计决策，包括与其他系统、配置项和用户的接口(在4.3.x标识了在本文档中所要考虑的主题)。如果接口设计说明ODD)中给出部分或全部该类信息，在此可以引用；b.对每个输入或条件进行响应的系统行为的设计决策，应包括：系统执行的动作、响应时间和其他性能特性、被模式化的物理系统的描述、所选择的方程式/算法/规则、对不允许的输入或条件的处理；c.系统数据库/数据文件如何呈现给用户的设计决策(在4.3.x标识了本文档中所要考虑的主题)。如果数据库(顶层)设计说明(DBDD)中给出部分或全部该类信息，在此可以引用；d.为满足安全性、保密性和私密性需求所选用的方法；e.硬件或硬软件系统的设计和构造选择。如：物理尺寸、颜色、形状、重量、材料和标志；f.为了响应需求而作出的其他系统级设计决策，如为提供所需的灵活性、可用性和可维护性而选择的方法。4系统体系结构设计本章分条描述系统体系结构设计。如果设计的部分或全部依赖于系统状态或方式，应指明这种依赖关系。如果设计信息在多条中出现，可以只描述一次，而在其他条加以引用。也需指出或引用为理解这些设计所需的设计约定。注：为简明起见，本章的描述是把一个系统直接组织成由硬件配置项(HWCI)、计算机软件配置项(CSCI)、 GB/T8567-2006《计算机软件文档编制规范》手工操作所组成，但应解释为它涵盖了把一个系统组织成子系统，子系统被组织成由HWCI.CSCI、手工操作组成，或其他适当变种的情况。4.1系统总体设计4.1.1概述4.1.1.1功能描述参考本系统的《系统/子系统需求规格说明》，说明对本系统要实现的功能、性能(包括：响应时间、安全性、兼容性、可移植性、资源使用等)要求。4.1.1.2运行环境参考本系统的《系统/子系统需求规格说明》，简要说明对本系统的运行环境(包括硬件环境和支持环境)的规定。4.1.2设计思想4.1.2.1系统构思说明本系统设计的系统构思。4.1.2.2关键技术与算法简要说明本系统设计采用的关键技术和主要算法。4.1.2.3关键数据结构简要说明本系统实现中的最主要的数据结构。4.1.3基本处理流程4.1.3.1系统流程图用流程图表示本系统的主要控制流程和处理流程。4.1.3.2数据流程图用数据流程图表示本系统的主要数据通路，并说明处理的主要阶段。4.1.4系统体系结构4.1.4.1系统配置项说明本系统中各配置项(子系统、模块、子程序和公用程序等)的划分，简要说明每个配置项的标识符和功能等(用一览表和框图的形式说明)。4.1.4.2系统层次结构分层次地给出各个系统配置项之间的控制与被控制关系。4.1.4.3系统配置项设计确定每个系统配置项的功能。若是较大的系统，可以根据需要对系统配置项作进一步的划分及设计。4.1.5功能需求与系统配置项的关系说明各项系统功能的实现同各系统配置项的分配关系(最好用矩阵图的方式)。4.1.6人工处理过程说明在本系统的运行过程中包含的人工处理过程(若有的话)。4.2系统部件本条应：a.标识所有系统部件(HWCI,CSCI、手工操作)，应为每个部件指定一个项目唯一标识符。注：数据库可作为一个CSCI或CSCI的一部分进行处理。b.说明部件之间的静态(如组成)关系。根据所选择的设计方法学，可能会给出多重关系。c.陈述每个部件的用途，并标识部件相对应的系统需求和系统级设计决策(作为一种变通，可在9.a中给出需求的分配)。d.标识每个部件的开发状态/类型，如果已知的话(如新开发的部件、对已有部件进行重用的部件、对已有设计进行重用的部件、再工程的已有设计或部件、为重用而开发的部件和计划用于第N开发阶段的部件等等)，对已有的设计或部件，此描述应提供诸如名称、版本、文档引用、地点等标识信息。e.对被标识用于该系统的每个计算机系统或其他计算机硬件资源的集合，描述其计算机硬件资源(如处理器、存储器、输入/输出设备、辅存器、通信/网络设备)。(若适用)每一描述应标识出使用资源的配置项，对 GB/T8567-2006《计算机软件文档编制规范》使用资源的每个CSCI说明资源使用分配情况(如分配给CSCI1：20％的资源、给CSCI2：30％的资源)，说明在什么条件下测量资源的使用情况，说明资源特性；1)计算机处理器描述，(若适用)应包括：制造商名称和型号、处理器速度/能力、指令集体系结构、适用的编译程序、字长(每个计算机字的位数)、字符集标准(如GB2312,GB18030等)和中断能力等；2)存储器描述.(若适用)应包括：制造商名称和型号，存储器大小、类型、速度和配置(如：256K高速缓冲存储器,16MBRAM(4MBx4))；3)输入/输出设备描述，(若适用)应包括：制造商名称和型号、设备类型和设备的速度或能力；4)外存描述，(若适用)应包括：制造商名称和型号、存储器类型、安装存储器的数量、存储器速度；5)通信/网络设备，(若适用)诸如：调制解调器、网卡、集线器、网关、电缆、高速数据线以及这些部件或其他部件的集合体的描述。(若适用)应包括：制造商名称和型号、数据传送速率/能力、网络拓扑结构、传输技术、使用的协议；6)(若适用)每个描述也应包括：增长能力、诊断能力以及与本描述相关的其他的硬件能力。f.给出系统的规格说明树，即：用一个图来标识和说明系统部件已计划的规格说明之间的关系.4.3执行概念本条应描述系统部件之间的执行概念。用图示和说明表示部件之间的动态关系，即系统运行期间它们是如何交互的，(若适用)包括：执行控制流，数据流，动态控制序列，状态转换图，时序图，部件的优先级别，中断处理，时序/序列关系，异常处理，并发执行，动态分配/去分配，对象、进程、任务的动态创建/删除，以及动态行为的其他方面。4.4接口设计本条应分条描述系统部件的接口特性，它应包括：部件之间的接口及它们与外部实体(如：其他系统、配置项、用户)之间的接口。注：本层不需要对这些接口进行完全设计提供本条的目的是为了把他们作为系统体系结构设计的一部分所做的接口设计决策记录下来如果在接口设计说明(IDD)或其他文档中含有部分或全部的该类信息，可以加以引用.4.4.1接口标识和图表本条用项目唯一标识符标识每个接口，(若适用)并用名称、编号、版本、文档引用来指明接口实体(如：系统、配置项、用户等)。该标识应叙述哪些实体具有固定接口特性(从而要把接口需求强加给接口实体)、哪些实体正被开发或修改(因而已把接口需求强加于它们)。应提供一个或多个接口图表来描述这些接口。4.4.x(接口的项目唯一标识符)本条(从4.4.2开始)应用项目唯一标识符标识接口，简要描述接口实体，并根据需要可分条描述接口实体单方或双方的接口特性。如果某个接口实体不在本文中(如，一个外部系统)，但其接口特性需要在描述本文叙述的接口实体时提到，则这些特性应以假设、或“当［未提到实体］这样做时，[本文提及的实体]将„„”的形式描述。本条可引用其他文档(例如数据字典、协议标准和用户接口标准)代替本条的描述信息。(若适用)本设计说明应包括以下内容，它们可以任何适合于要提供的信息的顺序给出，并且应从接口实体角度指出这些特性之间的区别(例如数据元素的大小、频率或其他特性的不同期望)：a.接口实体分配给接口的优先级别；b.要实现的接口的类型(如：实时数据传送、数据的存储和检索等)；c.接口实体将提供、存储、发送、访问和接收的单个数据元素的特性，如：1)名称/标识符：a)项目唯一标识符；b)非技术(自然语言)名称；c)标准数据元素名称；d)技术名称(如代码或数据库中变量或字段名称)；e)缩写名或同义名；2)数据类型(字母数字字符、整数等)；3)大小和格式(如：字符串长度和标点符号)； GB/T8567-2006《计算机软件文档编制规范》4)计量单位(如：米、元、纳秒)；5)范围或可能值的枚举(如:0-99)；6)准确度(正确程度)和精度(有效数字位数)；7)优先级别、时序、频率、容量、序列和其他约束，如：数据元素是否可被更新、业务规则是否适用；8)保密性和私密性约束；9)来源(设置/发送实体)和接收者(使用/接收实体)。d.接口实体必须提供、存储、发送、访问、接收的数据元素集合体(记录、消息、文件、数组、显示、报告等)的特性，如：1)名称/标识符；a)供追踪用的项目唯一标识符；b)非技术(自然语言)名称；c)技术名称(如代码或数据库的记录或数据结构)；d)缩写名或同义名；2)数据元素集合体中的数据元素及其结构(编号、次序和分组)；3)媒体(如盘)和媒体中数据元素/集合体的结构；4)显示和其他输出的视听特性(如：颜色、版面设计、字体、图和其他显示元素、蜂鸣声以及亮度)；5)数据元素集合体之间的关系。如排序/访间特性；6)优先级别、时序、频率、容量、序列和其他约束，如：集合体是否可被修改、业务规则是否适用；7)保密性和私密性约束；8)来源(设置/发送实体)和接收者(使用/接收实体)。e.接口实体为该接口使用通信方法的特性。如：1)项目唯一标识符；2)通信链路/带宽/频率/媒体及其特性；3)消息格式化；4)流控制(如：序列编号和缓冲区分配)；5)数据传送速率，周期性/非周期性和传输间隔；6)路由、寻址和命名约定；7)传输服务，包括：优先级别和等级；8)安全性/保密性/私密性方面的考虑，如：加密、用户鉴别、隔离和审核。f.接口实体为该接口使用协议的特性，如：1)项目唯一标识符；2)协议的优先级别/层次；3)分组，包括：分段和重组、路由和寻址；4)合法性检查、错误控制和恢复过程；5)同步，包括：连接的建立、保持、终止；6)状态、标识和其他的报告特征。g.其他所需的特性，如：接口实体的物理兼容性(尺寸、容限、负荷、电压和接插件兼容性等)。5运行设计5.1系统初始化说明本系统的初始化过程。5.2运行控制a.说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块和支持软件；b.说明每一种外界运行控制的方式方法和操作步骤；c.说明每种运行模块组合将占用各种资源的情况；d.说明系统运行时的安全控制。 GB/T8567-2006《计算机软件文档编制规范》5.3运行结束说明本系统运行的结束过程。6系统出错处理设计6.1出错信息包括出错信息表、故障处理技术等。6.2补救措施说明故障出现后可能采取的补救措施。7系统维护设计说明为了系统维护的方便，在系统内部设计中作出的安排。7.1检测点的设计说明在系统中专门安排用于系统检查与维护的检测点。7.2检测专用模块的设计说明在系统中专门安排用于系统检查与维护的专用模块。8尚待解决的问题说明在本设计中没有解决而系统完成之前应该解决的问题。9需求的可追踪性本章应包括：a.从本文中所标识的系统部件到其被分配的系统需求之间的可追踪性。(该可追踪性也可在4.2中提供)；b.从系统需求到其被分配给的系统部件之间的可追踪性。10注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.10接口设计说明(IDD)说明：1.《接口设计说明》(IDD)描述了一个或多个系统或子系统、硬件配置项HWCI、计算机软件配置项CSCI、手工操作或其他系统部件的接口特性。一个IDD可以说明任何数量的接口。2.IDD可用于补充《系统/子系统设计(结构设计)说明》(SSDD)、《软件(结构)设计说明》(SDD)和《数据库(顶层)设计说明》(DBDD)。IDD及其相伴的《接口需求规格说明》(IRS)用于沟通和控制接口的设计决策。接口设计说明的正文的格式如下：1引言本章应分以下几条。1.1标识本条应包含本文档适用的系统、接口实体和接口的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。1.3文档概述本条应概括本文档的用途与内容，并描述与其使用有关的保密性或私密性要求。1.4基线说明编写本系统设计说明书所依据的设计基线。 GB/T8567-2006《计算机软件文档编制规范》2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章也应标识不能通过正常的供货渠道获得的所有文档的来源。3接口设计本章应分条描述一个或多个系统、子系统、配置项、手工操作和其他系统部件的接口特性。如果设计的部分或全部依赖于系统状态或方式，则应指出这种依赖性。如果设计信息在多条中出现，则可只描述一次，而在其他条加以引用。如果此信息的部分或全部在别处提供，则此处可以引用。应给出或引用为了理解设计所需的设计约定。3.1接口标识和接口图对于1.1中所标识的每个接口，本条应陈述赋予该接口的项目唯一标识符，(若适用)并用名字、编号、版本和文档引用等标识接口实体(系统、配置项、用户等)。该标识应说明哪些实体具有固定的接口特性(因而要对这些接口实体强加接口需求)，哪些实体正被开发或修改(从而已将接口需求施加于它们)。(若适用)可用一个或多个接口图来描述这些接口。3.x(接口的项目唯一标识符)本条(从3.2开始编号)应通过项目唯一标识符标识接口，应简要标识接口实体，并且应根据需要划分为几条描述接口实体的单方或双方的接口特性。如果一给定的接口实体本文没有提及(例如，一个外部系统)，但是其接口特性需要在本文描述的接口实体时提到，则这些特性应以假设、或“当[未提到实体]这样做时，[被提到的实体]将„„”的形式描述。本条可引用其他文档(例如数据字典、协议标准、用户接口标准)代替本条的描述信息。(若适用)本设计说明应包括以下内容，它们可按适合于要提供的信息的任何次序给出，并且应从接口实体角度指出这些特性之间的区别(例如数据元素的大小、频率或其他特性的不同期望)。a.接口实体分配给接口的优先级别；b.要实现的接口的类型(如：实时数据传送、数据的存储和检索等)；c.接口实体必须提供、存储、发送、访问、接收的单个数据元素的特性，如：1)名称/标识符；a)项目唯一标识符；b)非技术(自然语言)名称；c)标准数据元素名称；d)技术名称(如代码或数据库中的变量或字段名称)；e)缩写名或同义名；2)数据类型(字母数字、整数等)；3)大小和格式(如：字符串的长度和标点符号)；4)计量单位(如：米、元、纳秒)；5)范围或可能值的枚举(如：0-99)；6)准确度(正确程度)和精度(有效数字位数)；7)优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素是否可被更新和业务规则是否适用；8)保密性和私密性的约束；9)来源(设置/发送实体)和接收者(使用/接收实体)；d.接口实体必须提供、存储、发送、访问和接收的数据元素集合体(记录、消息、文件、显示和报表等)的特性，如：1)名称/标识符；a)项目唯一标识符；b)非技术(自然语言)名称；c)技术名称(如代码或数据库的记录或数据结构)；d)缩写名或同义名；2)数据元素集合体中的数据元素及其结构(编号、次序和分组)； GB/T8567-2006《计算机软件文档编制规范》3)媒体(如盘)和媒体中数据元素/数据元素集合体的结构；4)显示和其他输出的视听特性(如：颜色、布局、字体、图标和其他显示元素、蜂鸣声、亮度等)；5)数据元素集合体之间的关系，如排序/访问特性；6)优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素集合体是否可被修改、业务规则是否适用；7)保密性和私密性约束；8)来源(设置/发送实体)和接收者(使用/接收实体)；e.接口实体必须为接口使用通信方法的特性。如：1)项目唯一标识符；2)通信链接/带宽/频率/媒体及其特性；3)消息格式化；4)流控制(如：序列编号和缓冲区分配)；5)数据传送速率，周期性/非周期性，传输间隔；6)路由、寻址、命名约定；7)传输服务，包括优先级别和等级；8)安全性/保密性/私密性方面的考虑，如：加密、用户鉴别、隔离和审核等；f.接口实体必须为接口使用协议的特性，如：1)项目唯一标识符；2)协议的优先级别/层次；3)分组，包括分段和重组、路由、寻址；4)合法性检查、错误控制和恢复过程；5)同步，包括连接的建立、维护、终止；6)状态、标识、任何其他的报告特征；g.其他所需的特性，如：接口实体的物理兼容性(尺寸、容限、负荷、电压和接插件兼容性等)。4需求的可追踪性本章应包括：a.从本文提到的每个接口实体到该实体的接口设计所涉及的系统或CSCI需求的可追踪性；b.从影响本IDD所覆盖的接口的每个系统或CSCI需求到涉及它的接口实体的可追踪性。5注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档所需要的术语和定义，所有缩略语和它们在本文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A，B等)编排。7.11软件需求规格说明(SRS)说明：1.《软件需求规格说明》(SRS)描述对计算机软件配置项CSCI的需求，及确保每个要求得以满足的所使用的方法。涉及该CSCI外部接口的需求可在本SRS中给出：或在本SRS引用的一个或多个《接口需求规格说明》(IRS)中给出。2.这个SRS，可能还要用IRS加以补充，是CSCI设计与合格性测试的基础。软件需求规格说明的正文的格式如下：1范围本章应分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发 GB/T8567-2006《计算机软件文档编制规范》行号。1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。1.3文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性或私密性要求。1.4基线说明编写本系统设计说明书所依据的设计基线。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和发行日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。3需求本章应分以下几条描述CSCI需求，也就是，构成CSCI验收条件的CSCI的特性。CSCI需求是为了满足分配给该CSCI的系统需求所形成的软件需求。给每个需求指定项目唯一标识符以支持测试和可追踪性。并以一种可以定义客观测试的方式来陈述需求。如果每个需求有关的合格性方法(见第4章)和对系统(若适用，子系统)需求的可追踪性(见5.a条)在相应的章中没有提供，则在此进行注解。描述的详细程度遵循以下规则：应包含构成CSCI验收条件的那些CSCI特性，需方愿意推迟到设计时留给开发方说明的那些特性。如果在给定条中没有需求的话，本条应如实陈述。如果某个需求在多条中出现，可以只陈述一次而在其他条直接引用。3.1所需的状态和方式如果需要CSCI在多种状态和方式下运行，且不同状态和方式具有不同的需求的话，则要标识和定义每一状态和方式，状态和方式的例子包括：空闲、准备就绪、活动、事后分析、培训、降级、紧急情况和后备等。状态和方式的区别是任意的，可以仅用状态描述CSCI,也可以仅用方式、方式中的状态、状态中的方式或其他有效方式描述。如果不需要多个状态和方式，不需人为加以区分，应如实陈述；如果需要多个状态或方式，还应使本规格说明中的每个需求或每组需求与这些状态和方式相关联，关联可在本条或本条引用的附录中用表格或其他的方法表示，也可在需求出现的地方加以注解。3.2需求概述3.2.1目标a.本系统的开发意图、应用目标及作用范围(现有产品存在的问题和建议产品所要解决的问题)。b.本系统的主要功能、处理流程、数据流程及简要说明。c.表示外部接口和数据流的系统高层次图。说明本系统与其他相关产品的关系，是独立产品还是一个较大产品的组成部分(可用方框图说明)。3.2.2运行环境简要说明本系统的运行环境(包括硬件环境和支持环境)的规定。3.2.3用户的特点说明是哪一种类型的用户，从使用系统来说，有些什么特点。3.2.4关键点说明本软件需求规格说明书中的关键点(例如：关键功能、关键算法和所涉及的关键技术等)。3.2.5约束条件列出进行本系统开发工作的约束条件。例如：经费限制、开发期限和所采用的方法与技术，以及政治、社会、文化、法律等。3.3需求规格3.3.1软件系统总体功能/对象结构对软件系统总体功能/对象结构进行描述，包括结构图、流程图或对象图。3.3.2软件子系统功能/对象结构对每个主要子系统中的基本功能模块/对象进行描述，包括结构图、流程图或对象图。 GB/T8567-2006《计算机软件文档编制规范》3.3.3描述约定通常使用的约定描述(数学符号、度量单位等)。3.4CSCI能力需求本条应分条详细描述与CSCI每一能力相关联的需求。“能力”被定义为一组相关的需求。可以用“功能”、“性能”、“主题”、“目标”或其他适合用来表示需求的词来替代“能力”。3.4.x(CSCI能力)本条应标识必需的每一个CSCI能力，并详细说明与该能力有关的需求。如果该能力可以更清晰地分解成若干子能力，则应分条对子能力进行说明。该需求应指出所需的CSCI行为，包括适用的参数，如响应时间、吞吐时间、其他时限约束、序列、精度、容量(大小/多少)、优先级别、连续运行需求、和基于运行条件的允许偏差：(若适用)需求还应包括在异常条件、非许可条件或越界条件下所需的行为，错误处理需求和任何为保证在紧急时刻运行的连续性而引人到CSCI中的规定。在确定与CSCI所接收的输入和CSCI所产生的输出有关的需求时，应考虑在本文3.5.x给出要考虑的主题列表。对于每一类功能或者对于每一个功能，需要具体描写其输入、处理和输出的需求。a.说明描述此功能要达到的目标、所采用的方法和技术，还应清楚说明功能意图的由来和背景。b.输入包括：1)详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定和有效输入范围等。2)指明引用的接口说明或接口控制文件的参考资料。c.处理定义对输入数据、中间参数进行处理以获得预期输出结果的全部操作。包括：1)输入数据的有效性检查。2)操作的顺序，包括事件的时间设定。3)异常情况的响应，例如，溢出、通信故障、错误处理等。4)受操作影响的参数。5)用于把输入转换成相应输出的方法。6)输出数据的有效性检查。d.输出1)详细说明该功能的所有输出数据，例如，输出目的地、数量、度量单位、时间关系、有效输出范围、非法值的处理、出错信息等。2)有关接口说明或接口控制文件的参考资料。3.5CSCI外部接口需求本条应分条描述CSCI外部接口的需求。(如有)本条可引用一个或多个接口需求规格说明(IRS)或包含这些需求的其他文档。外部接口需求，应分别说明：a.用户接口；b.硬件接口；c.软件接口；d.通信接口的需求。3.5.1接口标识和接口图本条应标识所需的CSCI外部接口，也就是CSCI和与它共享数据、向它提供数据或与它交换数据的实体的关系。(若适用)每个接口标识应包括项目唯一标识符，并应用名称、序号、版本和引用文件指明接口的实体(系统、配置项、用户等)。该标识应说明哪些实体具有固定的接口特性(因而要对这些接口实体强加接口需求)，哪些实体正被开发或修改(从而接口需求已施加给它们)。可用一个或多个接口图来描述这些接口。3.5.x(接口的项目唯一标识符)本条(从3.5.2开始)应通过项目唯一标识符标识CSCI的外部接口，简单地标识接口实体，根据需要可分 GB/T8567-2006《计算机软件文档编制规范》条描述为实现该接口而强加于CSCI的需求。该接口所涉及的其他实体的接口特性应以假设或“当[未提到实体]这样做时，CSCI将„„”的形式描述，而不描述为其他实体的需求。本条可引用其他文档(如：数据字典、通信协议标准、用户接口标准)代替在此所描述的信息。(若适用)需求应包括下列内容，它们以任何适合于需求的顺序提供，并从接口实体的角度说明这些特性的区别(如对数据元素的大小、频率或其他特性的不同期望)：a.CSCI必须分配给接口的优先级别；b.要实现的接口的类型的需求(如：实时数据传送、数据的存储和检索等)；c.CSCI必须提供、存储、发送、访间、接收的单个数据元素的特性，如：1)名称/标识符；a)项目唯一标识符；b)非技术(自然语言)名称；c)标准数据元素名称；d)技术名称(如代码或数据库中的变量或字段名称)；e)缩写名或同义名；2)数据类型(字母数字、整数等)；3)大小和格式(如：字符串的长度和标点符号)；4)计量单位(如：米、元、纳秒)；5)范围或可能值的枚举(如：0-99)；6)准确度(正确程度)和精度(有效数字位数)；7)优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素是否可被更新和业务规则是否适用；8)保密性和私密性的约束；9)来源(设置/发送实体)和接收者(使用/接收实体)；d.CSCI必须提供、存储、发送、访问、接收的数据元素集合体(记录、消息、文件、显示和报表等)的特性，如：1)名称/标识符；a)项目唯一标识符；b)非技术(自然语言)名称；c)技术名称(如代码或数据库的记录或数据结构)；d)缩写名或同义名；2)数据元素集合体中的数据元素及其结构(编号、次序、分组)；3)媒体(如盘)和媒体中数据元素/数据元素集合体的结构；4)显示和其他输出的视听特性(如：颜色、布局、字体、图标和其他显示元素、蜂鸣器以及亮度等)；5)数据元素集合体之间的关系。如排序/访问特性；6)优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素集合体是否可被修改和业务规则是否适用；7)保密性和私密性约束；8)来源(设置/发送实体)和接收者(使用/接收实体)；e.CSCI必须为接口使用通信方法的特性。如：1)项目唯一标识符；2)通信链接/带宽/频率/媒体及其特性；3)消息格式化；4)流控制(如：序列编号和缓冲区分配)；5)数据传送速率，周期性/非周期性，传输间隔；6)路由、寻址、命名约定；7)传输服务，包括优先级别和等级；8)安全性/保密性/私密性方面的考虑，如：加密、用户鉴别、隔离和审核等； GB/T8567-2006《计算机软件文档编制规范》f.CSCI必须为接口使用协议的特性，如：1)项目唯一标识符；2)协议的优先级别/层次；3)分组，包括分段和重组、路由和寻址；4)合法性检查、错误控制和恢复过程；5)同步，包括连接的建立、维护和终止；6)状态、标识、任何其他的报告特征；g.其他所需的特性，如：接口实体的物理兼容性(尺寸、容限、负荷、电压和接插件兼容性等)。3.6CSCI内部接口需求本条应指明CSCI内部接口的需求(如有的话)。如果所有内部接口都留待设计时决定，则需在此说明这一事实。如果要强加这种需求，则可考虑本文档的3.5给出的一个主题列表。3.7CSCI内部数据需求本条应指明对CSCI内部数据的需求，(若有)包括对CSCI中数据库和数据文件的需求。如果所有有关内部数据的决策都留待设计时决定，则需在此说明这一事实。如果要强加这种需求，则可考虑在本文档的3.5.x.c和3.5.x.d给出的一个主题列表。3.8适应性需求(若有)本条应指明要求CSCI提供的、依赖于安装的数据有关的需求(如：依赖现场的经纬度)和要求CSCI使用的、根据运行需要进行变化的运行参数(如：表示与运行有关的目标常量或数据记录的参数)。3.9保密性需求(若有)本条应描述有关防止对人员、财产、环境产生潜在的危险或把此类危险减少到最低的CSCI需求，包括：为防止意外动作(如意外地发出“自动导航关闭”命令)和无效动作(发出一个想要的“自动导航关闭”命令时失败CSCI必须提供的安全措施。3.10保密性和私密性需求(若有)本条应指明保密性和私密性的CSCI需求，包括：CSCI运行的保密性/私密性环境、提供的保密性或私密性的类型和程度.CSCI必须经受的保密性/私密性的风险、减少此类危险所需的安全措施、CSCI必须遵循的保密性/私密性政策、CSCI必须提供的保密性/私密性审核、保密性/私密性必须遵循的确证/认可准则。3.11CSCI环境需求(若有)本条应指明有关CSCI必须运行的环境的需求。例如，包括用于CSCI运行的计算机硬件和操作系统(其他有关计算机资源方面的需求在下条中描述)。3.12计算机资源需求本条应分以下各条进行描述。3.12.1计算机硬件需求本条应描述cSc1使用的计算机硬件需求，(若适用)包括：各类设备的数量、处理器、存储器、输入/输出设备、辅助存储器、通信/网络设备和其他所需的设备的类型、大小、容量及其他所要求的特征。3.12.2计算机硬件资源利用需求本条应描述CSCI计算机硬件资源利用方面的需求，如：最大许可使用的处理器能力、存储器容量、输入/输出设备能力、辅助存储器容量、通信/网络设备能力。描述(如每个计算机硬件资源能力的百分比)还包括测量资源利用的条件。3.12.3计算机软件需求本条应描述CSCI必须使用或引人CSCI的计算机软件的需求，例如包括：操作系统、数据库管理系统、通信/网络软件、实用软件、输入和设备模拟器、测试软件、生产用软件。必须提供每个软件项的正确名称、版本、文档引用。3.12.4计算机通信需求本条应描述CSCI必须使用的计算机通信方面的需求，例如包括：连接的地理位置、配置和网络拓扑结构、传输技术、数据传输速率、网关、要求的系统使用时间、传送/接收数据的类型和容量、传送/接收/响应的时间限制、数据的峰值、诊断功能。 GB/T8567-2006《计算机软件文档编制规范》3.13软件质量因素(若有)本条应描述合同中标识的或从更高层次规格说明派生出来的对CSCI的软件质量方面的需求，例如包括有关CSCI的功能性(实现全部所需功能的能力)、可靠性(产生正确、一致结果的能力)、可维护性(易于更正的能力)、可用性(需要时进行访间和操作的能力)、灵活性(易于适应需求变化的能力)、可移植性(易于修改以适应新环境的能力)、可重用性(可被多个应用使用的能力)、可测试性(易于充分测试的能力)、易用性(易于学习和使用的能力)以及其他属性的定量需求。3.14设计和实现的约束(若有)本条应描述约束CSCI设计和实现的那些需求。这些需求可引用适当的标准和规范。例如需求包括：a.特殊CSCI体系结构的使用或体系结构方面的需求，例如：需要的数据库和其他软件配置项；标准部件、现有的部件的使用；需方提供的资源(设备、信息、软件)的使用；b.特殊设计或实现标准的使用；特殊数据标准的使用；特殊编程语言的使用；c.为支持在技术、风险或任务等方面预期的增长和变更区域，必须提供的灵活性和可扩展性.3.15数据说明本系统的输入、输出数据及数据管理能力方面的要求(处理量、数据量)。3.16操作说明本系统在常规操作、特殊操作以及初始化操作、恢复操作等方面的要求。3.17故障处理说明本系统在发生可能的软硬件故障时，对故障处理的要求。包括：a.说明属于软件系统的问题；b.给出发生错误时的错误信息；c.说明发生错误时可能采取的补救措施。3.18算法说明用于实施系统计算功能的公式和算法的描述。包括：a.每个主要算法的概况；b.用于每个主要算法的详细公式。3.19有关人员需求(若有)本条应描述与使用或支持CSCI的人员有关的需求，包括人员数量、技能等级、责任期、培训需求、其他的信息。如：同时存在的用户数量的需求，内在帮助和培训能力的需求，(若有)还应包括强加于CSCI的人力行为工程需求，这些需求包括对人员在能力与局限性方面的考虑：在正常和极端条件下可预测的人为错误，人为错误造成严重影响的特定区域，例如包括错误消息的颜色和持续时间、关键指示器或关键的物理位置以及听觉信号的使用的需求。3.20有关培训需求(若有)本条应描述有关培训方面的CSCI需求。包括：在CSCI中包含的培训软件。3.21有关后勤需求(若有)本条应描述有关后勤方面的CSCI需求，包括：系统维护、软件支持、系统运输方式、供应系统的需求、对现有设施的影响、对现有设备的影响。3.22其他需求(若有)本条应描述在以上各条中没有涉及到的其他CSCI需求。3.23包装需求(若有)本条应描述需交付的CSCI在包装、加标签和处理方面的需求(如用确定方式标记和包装8磁道磁带的交付)。(若适用)可引用适当的规范和标准。3.24需求的优先次序和关键程度(若适用)本条应给出本规格说明中需求的、表明其相对重要程度的优先顺序、关键程度或赋予的权值，如：标识出那些认为对安全性、保密性或私密性起关键作用的需求，以便进行特殊的处理。如果所有需求具有相同的权值，本条应如实陈述。 GB/T8567-2006《计算机软件文档编制规范》4合格性规定本章定义一组合格性方法，对于第3章中每个需求，指定所使用的方法，以确保需求得到满足。可以用表格形式表示该信息，也可以在第3章的每个需求中注明要使用的方法。合格性方法包括：a.演示：运行依赖于可见的功能操作的CSCI或部分CSCI,不需要使用仪器、专用测试设备或进行事后分析；b.测试：使用仪器或其他专用测试设备运行CSCI或部分CSCI,以便采集数据供事后分析使用；c.分析：对从其他合格性方法中获得的积累数据进行处理，例如测试结果的归约、解释或推断；d.审查：对CSCI代码、文档等进行可视化检查；e.特殊的合格性方法。任何应用到CSCI的特殊合格性方法，如：专用工具、技术、过程、设施、验收限制。5需求可追踪性本章应包括：a.从本规格说明中每个CSCI的需求到其所涉及的系统(或子系统)需求的可追踪性。(该可追踪性也可以通过对第3章中的每个需求进行注释的方法加以描述).注：每一层次的系统细化可能导致对更高层次的需求不能直接进行追踪。例如：建立多个CSCI的系统体系结构设计可能会产生有关CSCI之间接口的需求，而这些接口需求在系统需求中并没有被覆盖，这样的需求可以被追踪到诸如“系统实现”这样的一般需求，或被追踪到导致它们产生的系统设计决策上。b.从分配到被本规格说明中的CSCI的每个系统(或子系统)需求到涉及它的CSCI需求的可追踪性。分配到CSCI的所有系统(或子系统)需求应加以说明。追踪到IRS中所包含的CSCI需求可引用IRS.6尚未解决的问题如需要，可说明软件需求中的尚未解决的遗留问题。7注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A，B等)编排。7.12数据需求说明(DRD)说明：1.数据需求说明(DRD)的编制目的是为了向整个开发时期提供关于被处理数据的描述和数据采集要求的技术信息。数据需求说明的正文格式如下：1引言本章应分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识。(若适用)包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。1.3文档概述本条应概述本文档的用途与内容，预期的读者并描述与其使用有关的保密性或私密性要求。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章也应标识不能通过正常的供货 GB/T8567-2006《计算机软件文档编制规范》渠道获得的所有文档的来源。3数据的逻辑描述对数据进行逻辑描述时，可把数据分为动态数据和静态数据。静态数据，是指在运行过程中主要作为参考的数据，它们在很长的一段时间内不会发生变化，一般不随运行而变更。动态数据，包括所有在运行中要发生变化的数据以及在运行中要输入、输出的数据。进行描述时应把各数据元素逻辑地分成若干组，例如函数、源数据或对于其应用更为恰当的逻辑分组。给出每一数据元素的名称(包括缩写和代码)、定义(或物理意义)度量单位、值域、格式和类型等有关信息。3.1静态数据列出所有作为控制或参考用的静态数据元素。3.2动态输入数据列出动态输入数据元素(包括在常规运行中或联机操作中要变更的数据)。3.3动态输出数据列出动态输出数据元素(包括在常规运行中或联机操作中要变更的数据)。3.4内部生成数据列出向用户或开发单位中的维护调试人员提供的内部生成数据。3.5数据约定说明对数据要求的制约。逐条列出对进一步扩充或使用方面的考虑而提出的对数据要求的限制(容量、文件、记录和数据元的个数的最大值)。对于在设计和开发中确定是临界性的限制更要明确指出。4数据的采集4.1要求和范围按数据元的逻辑分组来说明数据采集的要求和范围，指明数据的采集方法，说明数据采集工作的承担者是用户还是开发者，具体内容包括：a.输入数据的来源。例如是单个操作员、数据输入站，专业的数据输入公司或它们的一个分组；b.数据输入(指把数据输入至处理系统内部)所用的媒体和硬设备。如果只有指定的输入点的输入是合法的，则必须对此加以说明；c.接收者。说明输出数据的接收者；d.输出数据的形式和设备。列出输出数据的形式和硬设备。无论接收者收到的数据是打印输出，还是显示器上的一组字符、一帧图形，或一声警铃，或向开关线圈提供一个电脉冲，或常用媒体如磁盘、磁带、光盘等，均应具体说明；e.数据值的范围。给出每一个数据元的合法值的范围；f.量纲。给出数字的度量单位、增量的步长、零点的定标等。在非数字量的情况下，要给出每一种合法值的形式和含义；g.更新和处理的频度。给出预定的对输入数据的更新和处理的频度。如果数据的输入是随机的，应给出更新处理的频度的平均值，或变化情况的某种其他度量。4.2输入的承担者说明预定的对数据输入工作的承担者。如果输入数据同某一接口软件有关，还应说明该接口软件的来源。4.3预处理对数据的采集和预处理过程提出专门的规定，包括适合应用的数据格式、预定的数据通信媒体和对输入的时间要求等。对于需经模拟转换或数字转换的数据量，要给出转换方法和转换因子等有关信息，以便软件系统使用这些数据。4.4影响说明这些数据要求对于设备、软件、用户、开发方所可能产生的影响，例如要求用户单位增设某个机构等。5注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。 GB/T8567-2006《计算机软件文档编制规范》附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.13软件(结构)设计说明(SDD)说明：1.《软件(结构)设计说明》(SDD)描述了计算机软件配置项(CSCI的设计。它描述了CSCI级设计决策、CSCI体系结构设计(概要设计)和实现该软件所需的详细设计。SDD可用接口设计说明IDD和数据库(顶层)设计说明DBDD加以补充。2.SDD连同相关的IDD和DBDD是实现该软件的基础。向需方提供了设计的可视性，为软件支持提供了所需要的信息。3.IDD和DBDD是否单独成册抑或与SDD合为一份资料视情况繁简而定。软件(结构)设计说明的正文的格式如下：1引言本章应分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识。(若适用)包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。1.3文档概述本条应概述本文档的用途与内容，并描述与其使用有关的保密性或私密性要求。1.4基线说明编写本系统设计说明书所依据的设计基线。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章也应标识不能通过正常的供货渠道获得的所有文档的来源。3CSCI级设计决策本章应根据需要分条给出CSCI级设计决策，即CSCI行为的设计决策(忽略其内部实现，从用户的角度看，它如何满足用户的需求)和其他影响组成该CSCI的软件配置项的选择与设计的决策。如果所有这些决策在CSCI需求中均是明确的，或者要推迟到CSCI的软件配置项设计时指出，本章应如实陈述。为响应指定为关键性的需求(如安全性、保密性、私密性需求)而作出的设计决策，应在单独的条中加以描述。如果设计决策依赖于系统状态或方式，则应指出这种依赖性。应给出或引用理解这些设计所需的设计约定。CSCI级设计决策的例子如下：a.关于CSCI应接受的输入和产生的输出的设计决策，包括与其他系统、HWCI,CSCI和用户的接口(本文的4.5.x标识了本说明要考虑的主题)。如果该信息的部分或全部已在接口设计说明(IDD)中给出，此处可引用。b.有关响应每个输入或条件的CSCI行为的设计决策，包括该CSCI要执行的动作、响应时间及其他性能特性、被模式化的物理系统的说明、所选择的方程式/算法/规则和对不允许的输入或条件的处理。c.有关数据库/数据文件如何呈现给用户的设计决策(本文的4.5.x标识了本说明要考虑的主题)。如果该信息的部分或全部已在数据库(顶层)设计说明(DBDD)中给出，此处可引用。d.为满足安全性、保密性、私密性需求而选择的方法。e.对应需求所做的其他CSCI级设计决策，例如为提供所需的灵活性、可用性和可维护性所选择的方法。4CSCI体系结构设计本章应分条描述CSCI体系结构设计。如果设计的部分或全部依赖于系统状态或方式，则应指出这种依赖 GB/T8567-2006《计算机软件文档编制规范》性。如果设计信息在多条中出现，则可只描述一次，而在其他条引用。应给出或引用为理解这些设计所需的设计约定。4.1体系结构4.1.1程序(模块)划分用一系列图表列出本CSCI内的每个程序(包括每个模块和子程序)的名称、标识符、功能及其所包含的源标准名。4.1.2程序(模块)层次结构关系用一系列图表列出本CSCI内的每个程序(包括每个模块和子程序)之间的层次结构与调用关系。4.2全局数据结构说明本章说明本程序系统中使用的全局数据常量、变量和数据结构。4.2.1常量包括数据文件名称及其所在目录，功能说明，具体常量说明等。4.2.2变量包括数据文件名称及其所在目录，功能说明，具体变量说明等。4.2.3数据结构包括数据结构名称，功能说明，具体数据结构说明(定义、注释、取值„)等。4.3CSCI部件本条应：a.标识构成该CSCI的所有软件配置项。应赋予每个软件配置项一个项目唯一标识符。注:软件配置项是CSCI设计中的一个元素，如CSCI的一个主要的分支、该分支的一个组成部分、一个类、对象、模块、函数、例程或数据库.软件配置项可以出现在一个层次结构的不同层次上，并且可以由其他软件配置项组成.设计中的软件配置项与实现它们的代码和数据实体(例程、过程、数据库、数据文件等)或包含这些实体的计算机文件之间，可以有也可以没有一对一的关系。一个数据库可以被处理为一个CSCI，也可被处理为一个软件配置项。SDD可以通过与所采用的设计方法学一致的名字来引用软件配置项。b.给出软件配置项的静态关系(如“组成”)。根据所选择的软件设计方法学可以给出多种关系(例如，采用面向对象的设计方法时，本条既可以给出类和对象结构，也可以给出CSCI的模块和过程结构)。c.陈述每个软件配置项的用途，并标识分配给它的CSCI需求与CSCI级设计决策(需求的分配也可在6.a中提供)。d.标识每个软件配置项的开发状态/类型(如新开发的软件配置项、重用已有设计或软件的软件配置项、再工程的已有设计或软件、为重用而开发的软件等)。对于已有设计或软件，本说明应提供标识信息，如名称、版本、文档引用、库等。e.描述CSCI(若适用，每个软件配置项)计划使用的计算机硬件资源(例如处理器能力、内存容量、输入/输出设备能力、辅存容量和通信/网络设备能力)。这些描述应覆盖该CSCI的资源使用需求中提及的、影响该cscl的系统级资源分配中提及的、以及在软件开发计划的资源使用度量计划中提及的所有计算机硬件资源。如果一给定的计算机硬件资源的所有使用数据出现在同一个地方，如在一个SDD中，则本条可以引用它。针对每一计算机硬件资源应包括如下信息：1)得到满足的CSCI需求或系统级资源分配；2)使用数据所基于的假设和条件(例如，典型用法、最坏情况用法、特定事件的假设)；3)影响使用的特殊考虑(例如虚存的使用、覆盖的使用、多处理器的使用或操作系统开销、库软件或其他的实现开销的影响)；4)所使用的度量单位(例如处理器能力百分比、每秒周期、内存字节数、每秒千字节)；5)进行评估或度量的级别(例如软件配置项,CSCI或可执行程序)。f.指出实现每个软件配置项的软件放置在哪个程序库中。4.4执行概念本条应描述软件配置项间的执行概念。为表示软件配置项之间的动态关系，即CSCI运行期间它们如何交互的，本条应包含图示和说明，(若适用)包括执行控制流、数据流、动态控制序列、状态转换图、时序图、配 GB/T8567-2006《计算机软件文档编制规范》置项之间的优先关系、中断处理、时间/序列关系、异常处理、并发执行、动态分配与去分配、对象/进程/任务的动态创建与删除和其他的动态行为。4.5接口设计本条应分条描述软件配置项的接口特性，既包括软件配置项之间的接口，也包括与外部实体，如系统、配置项及用户之间的接口。如果这些信息的部分或全部已在接口设计说明(IDD)、本文的第5章或其他地方说明的话，可在此处引用。4.5.1接口标识与接口图本条应陈述赋予每个接口的项目唯一标识符，(若适用)并用名字、编号、版本和文档引用等标识接口实体(软件配置项、系统、配置项、用户等)。接口标识应说明哪些实体具有固定接口特性(从而把接口需求强加给接口实体)，哪些实体正在开发或修改(因而已把接口需求分配给它们)。(若适用)应该提供一个或多个接口图以描述这些接口。4.5.x(接口的项目唯一标识符)本条(从4.5.2开始编号)应用项目唯一标识符标识接口，应简要标识接口实体，并且应根据需要划分为几条描述接口实体的单方或双方的接口特性。如果一给定的接口实体本文没有提到(例如，一个外部系统)，但是其接口特性需要在本SDD描述的接口实体时提到，则这些特性应以假设、或“当[未提到实体]这样做时，[提到的实体]将„„”的形式描述。本条可引用其他文档(例如数据字典、协议标准、用户接口标准)代替本条的描述信息。本设计说明应包括以下内容，(若适用)它们可按适合于要提供的信息的任何次序给出，并且应从接口实体角度指出这些特性之间的区别(例如数据元素的大小、频率或其他特性的不同期望)。a.由接口实体分配给接口的优先级；b.要实现的接口的类型(例如实时数据传输、数据的存储与检索等)；c.接口实体将提供、存储、发送、访问、接收的单个数据元素的特性，例如：1)名称/标识符；a)项目唯一标识符；b)非技术(自然语言)名称；c)标准数据元素名称；d)缩写名或同义名；2)数据类型(字母数字、整数等)；3)大小与格式(例如字符串的长度与标点符号)；4)计量单位(如米、元、纳秒等)；5)范围或可能值的枚举(如0^-99)；6)准确度(正确程度)与精度(有效数位数)；7)优先级、时序、频率、容量、序列和其他约束，如数据元素是否可被更新，业务规则是否适用；8)保密性与私密性约束；9)来源(设置/发送实体)与接收者(使用/接收实体)。d.接口实体将提供、存储、发送、访问、接收的数据元素集合体(记录、消息、文件、数组、显示、报表等)的特性，例如：1)名称/标识符；a)项目唯一标识符；b)非技术(自然语言)名称；c)技术名称(如代码或数据库中的记录或数据结构名)；d)缩写名或同义名；2)数据元素集合体中的数据元素及其结构(编号、次序、分组)；3)媒体(如盘)及媒体上数据元素/集合体的结构；4)显示和其他输出的视听特性(如颜色、布局、字体、图标及其他显示元素、蜂鸣声、亮度等)；5)数据集合体之间的关系，如排序/访问特性；6)优先级、时序、频率、容量、序列和其他约束，如数据集合体是否可被更新，业务规则是否适用； GB/T8567-2006《计算机软件文档编制规范》7)保密性与私密性约束；8)来源(设置/发送实体)与接收者(使用/接收实体)。e.接口实体为该接口使用通信方法的特性，例如：1)项目唯一标识符；2)通信链路/带宽/频率/媒体及其特性；3)消息格式化；4)流控制(如序列编号与缓冲区分配)；5)数据传输率、周期或非周期和传送间隔；6)路由、寻址及命名约定；7)传输服务，包括优先级与等级；8)安全性/保密性/私密性考虑，如加密、用户鉴别、隔离、审核等。f.接口实体为该接口使用协议的特性，例如：1)项目唯一标识符；2)协议的优先级/层；3)分组，包括分段与重组、路由及寻址；4)合法性检查、错误控制、恢复过程；5)同步，包括连接的建立、保持、终止；6)状态、标识和其他报告特性。g.其他特性，如接口实体的物理兼容性(尺寸、容限、负荷、电压、接插件的兼容性等)。5CSCI详细设计本章应分条描述CSCI的每个软件配置项。如果设计的部分或全部依赖于系统状态或方式，则应指出这种依赖性。如果该设计信息在多条中出现，则可只描述一次，而在其他条引用。应给出或引用为理解这些设计所需的设计约定。软件配置项的接口特性可在此处描述，也可在第4章或接口设计说明(IDD)中描述。数据库软件配置项，或用于操作/访问数据库的软件配置项，可在此处描述，也可在数据库(顶层)设计说明(DBDD)中描述。5.x(软件配置项的项目唯一标识符或软件配置项组的指定符)本条应用项目唯一标识符标识软件配置项并描述它。(若适用)描述应包括以下信息。作为一种变通，本条也可以指定一组软件配置项，并分条标识和描述它们。包含其他软件配置项的软件配置项可以引用那些软件配置项的说明，而无需在此重复。a.(若有)配置项设计决策，诸如(如果以前未选)要使用的算法；b.软件配置项设计中的约束、限制或非常规特征；c.如果要使用的编程语言不同于该CSCI所指定的语言.应该指出，并说明使用它的理由；d.如果软件配置项由过程式命令组成或包含过程式命令(如数据库管理系统(DBMS)中用于定义表单与报表的菜单选择、用于数据库访问与操纵的联机DBMS查询、用于自动代码生成的图形用户接口(GUI)构造器的输入、操作系统的命令或shell脚本)，应有过程式命令列表和解释它们的用户手册或其他文档的引用；e.如果软件配置项包含、接收或输出数据，(若适用)应有对其输入、输出和其他数据元素以及数据元素集合体的说明。(若适用)本文的4.5.x提供要包含主题的列表。软件配置项的局部数据应与软件配置项的输入或输出数据分开来描述。如果该软件配置项是一个数据库，应引用相应的数据库(顶层)设计说明(DBDD)；接口特性可在此处提供，也可引用本文第4章或相应接口设计说明。f.如果软件配置项包含逻辑，给出其要使用的逻辑，(若适用)包括：1)该软件配置项执行启动时，其内部起作用的条件；2)把控制交给其他软件配置项的条件；3)对每个输入的响应及响应时间，包括数据转换、重命名和数据传送操作；4)该软件配置项运行期间的操作序列和动态控制序列，包括：a)序列控制方法；b)该方法的逻辑与输入条件，如计时偏差、优先级赋值； GB/T8567-2006《计算机软件文档编制规范》C)数据在内存中的进出；d)离散输入信号的感知，以及在软件配置项内中断操作之间的时序关系；5)异常与错误处理。6需求的可追踪性本章应包括：a.从本SDD中标识的每个软件配置项到分配给它的CSCI需求的可追踪性(亦可在4.1中提供)；b.从每个CSCI需求到它被分配给的软件配置项的可追踪性。7注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.14数据库(顶层)设计说明(DBDD)说明：1.《数据库(顶层)设计说明)(DBDD)描述了数据库的设计。所谓数据库指存储在一个或多个计算机文件中的相关数据的集合，它们可由用户或计算机程序通过数据库管理系统(DBMS)加以访问。DBDD还描述了存取或操纵数据所使用的软件配置项。2.DBDD是实现数据库及相关软件配置项的基础。它向需方提供了设计的可视性，为软件支持提供了所需要的信息。3.DBDD是否单独成册或与SDD合为一份资料视情况繁简而定。数据库(顶层)设计说明的正文的格式如下：1引言本章应分为以下几条。1.1标识本条应包含本文档适用的数据库的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。1.2数据库概述本条应简述本文档适用的数据库的用途。它应描述数据库的一般性质；概括它的开发、使用和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。1.3文档概述本条应概括本文档的用途与内容，并描述与其使用有关的保密性或私密性要求。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。也应标识不能通过正常的供货渠道获得的所有文档的来源。3数据库级设计决策本章应根据需要分条给出数据库级设计决策，即数据库行为设计决策(从用户的角度看，该数据库如何满足它的需求而忽略内部实现)和其他影响数据库进一步设计的决策。如果所有这些决策在系统或CSCI需求中均是明确的，本章应如实陈述。对应于指定为关键性需求(如安全性、保密性、私密性需求)的设计决策，应在单独的条中加以描述。如果设计决策依赖于系统状态或方式，则应指出这种依赖性。如果设计决策的部分或全部已在定制的或商用的数据库管理系统(DBMS)的文档中作了描述，本章可引用它们。应给出或引用理解设计所需的设计约定。数据库级设计决策的例子如下：a.关于该数据库应接受的查询或其他输入和它应产生的输出(显示、报告、消息、响应等)的设计决策，包括与其他系统、HWCI,CSCI和用户的接口(本文的5.x.d标识了本说明要考虑的主题)。如果该信息的部分或全部已在接口设计说明(IDD)中给出，此处可引用。b.有关响应每次输入或查询的数据库行为的设计决策，包括动作、响应时间和其他性能特性、所选择的 GB/T8567-2006《计算机软件文档编制规范》方程式/算法/规则、配置和对不允许的输入的处理。c.有关数据库/数据文件如何呈现给用户的设计决策。(本文的4.x标识了本说明要考虑的主题).d.有关要使用什么数据库管理系统(包括名字、版本/发行)的设计决策和为适应需求的变化而引人到数据库内部的灵活性类型的设计决策。e.有关数据库要提供的可用性、保密性、私密性和运行连续性的层次与类型的设计决策。f.有关数据库的分布(如客户机/服务器)、主数据库文件更新与维护的设计决策，包括一致性的维护、同步的建立/重建与维护、完整性与业务规则的实施等。g.有关备份与恢复的设计决策，包括数据与处理分布策略、备份与恢复期间所允许的动作、对例如音像等新技术或非标准技术的特殊考虑。h.有关重组、排序、索引、同步与一致性的设计决策，包括自动的盘管理与空间回收、优化策略、存储与空间大小、数据库内容的填充与历史数据的捕获等方面的考虑。4数据库详细设计本章应根据需要分条描述数据库的详细设计。设计级别数以及每一级别的名称应基于所用的设计方法学。数据库设计级别的例子包括：概念设计、内部设计、逻辑设计和物理设计。如果这些设计决策的部分或全部依赖于系统状态或方式，则应指出这种依赖性。应给出或引用为理解这些设计所需的设计约定。注：本文用术语“数据元素集合体”表示在给定的设计级别(如概念设计、内部设计、逻辑设计、物理设计)中具有结构特征(数据元素的编号/次序/分组)的任何实体、关系、模式、字段、表、数组等；同时用术语“数据元素”表示在给定的级别中没有结构特征的关系、属性、字段、配置项、数据元素等。4.x(数据库设计级别的名称)本条应标识一个数据库设计级别，并用所选择的设计方法的术语描述数据库的数据元素和数据元素集合体。(若适用)描述信息应包括以下内容，它们可按适合于要提供的信息的任何次序给出。a.数据库设计中的单个数据元素特性，例如：1)名称/标识符；a)项目唯一标识符；b)非技术(自然语言)名称；c)标准数据元素名；d)技术名称(如数据库中的字段名)；e)缩写名或同义名；2)数据类型(字母数字、整数等)；3)大小与格式(例如字符串的长度与标点符号)；4)计量单位(如米、元、纳秒等)；5)范围或可能值的枚举(如0-99)；6)准确度(正确程度)与精度(有效位数)；7)优先级、时序、频率、容量、序列和其他约束，如数据元素是否可被更新，业务规则是否适用；8)保密性与私密性约束；9)来源(设置/发送实体)与接收者(使用/接收实体)。b.数据库设计中的数据元素集合体(记录、消息、文件、数组、显示、报表等)的特性，例如：1)名称/标识符；a)项目唯一标识符；b)非技术(自然语言)名称；c)技术名称(如代码或数据库中的记录或数据结构名)；d)缩写名或同义名；2)数据元素集合体中的数据元素及其结构(编号、次序、分组)；3)媒体(如盘)及媒体上数据元素/集合体的结构；4)显示和其他输出的视听特性(如颜色、布局、字体、图标及其他显示元素、蜂鸣声、亮度等)；5)数据元素集合体之间的关系，如排序/访问特性； GB/T8567-2006《计算机软件文档编制规范》6)优先级、时序、频率、容量、序列和其他约束，如数据集合体是否可被更新，业务规则是否适用；7)保密性与私密性约束；8)来源(设置/发送实体)与接收者(使用/接收实体)。5用于数据库访问或操纵的软件配置项的详细设计本章应分条描述用于数据库访问或操纵的每个软件配置项。如果该信息的部分或全部已在别处提供，如在软件(结构)设计说明(SDD)、定制的DBMS的SDD,商用的DBMS的用户手册等处，在此可引用该信息，而无需重复说明。如果设计的部分或全部依赖于系统状态或方式，则应指出这种依赖性。如果该设计信息在多条中出现，则可只描述一次，而在其他条引用。应给出或引用为理解设计所需的设计约定。5.x(软件配置项的项目唯一标识符或软件配置项组的指定符)本条应用项目唯一标识符标识软件配置项并描述它。(若适用)描述应包括以下信息。作为一种变通.本条也可以指定一组软件配置项，并分条标识和描述它们。包含其他软件配置项的软件配置项可以引用那些软件配置项的说明，而无需在此重复。a.(若有)配置项设计决策，诸如(如果以前未选)要使用的算法；b.软件配置项设计中的约束、限制或非常规特征；c.如果要使用的编程语言不同于该CSCI所指定的语言，应该指出，并说明使用它的理由；d.如果软件配置项由过程式命令组成或包含过程式命令(如数据库管理系统(DBMS)中用于定义表单与报表的菜单选择、用于数据库访问与操纵的联机DBMS查询、用于自动代码生成的图形用户接口(GUI)构造器的输入、操作系统的命令或命令解释程序(shell)脚本)，应有过程式命令列表和对解释它们的用户手册或其他文档的引用；e.如果软件配置项包含、接收或输出数据，(若适用)应有对其输入、输出和其他数据元素以及数据元素集合体的说明。(若适用)本文的4.x.6提供要包含主题的列表。软件配置项的局部数据应与软件配置项的输入或输出数据分开来描述。如果该软件配置项是一个数据库，应引用相应的数据库(顶层)设计说明(DBDD)：接口特性可在此处提供，也可引用相应接口设计说明。如果一给定的接口实体本文没有提及(例如，一个外部系统)，但是其接口特性需要在本DBDD描述的接口实体时提到，则这些特性应以假设、或“当[未提及实体]这样做时，[软件配置项]将„„”的形式描述。本条可引用其他文档(例如数据字典、协议标准、用户接口标准)代替本条的描述信息。本设计说明应包括以下内容，(若适用)它们可按适合于要提供的信息的任何次序给出，并且应从接口实体角度指出这些特性之间的区别(例如数据元素的大小、频率等)。1)接口的项目唯一标识符；2)(若适用)用名字、编号、版本和文档引用来标识接口实体(软件配置项、配置项、用户等)；3)由接口实体分配给接口的优先级；4)要实现的接口的类型(例如实时数据传输、数据的存储与检索等)；5)接口实体将提供、存储、发送、访问、接收的单个数据元素的特性。本文档4.x.a标识了要提及的主题；6)接口实体将提供、存储、发送、访问、接收的数据元素集合体(记录、消息、文件、数组、显示、报表等)的特性。本文档的4.x.6标识了要提及的主题；7)接口实体为该接口使用通信方法的特性，例如：a)项目唯一标识符；b)通信链路/带宽/频率/媒体及其特性；c)消息格式化；d)流控制(如序列编号与缓冲区分配)；e)数据传输率、周期或非周期和传送间隔；f)路由、寻址及命名约定；g)传输服务，包括优先级与等级；h)安全性/保密性/私密性考虑，如加密、用户鉴别、隔离、审核等。8)接口实体为该接口使用协议的特性，例如：a)项目唯一标识符； GB/T8567-2006《计算机软件文档编制规范》b)协议的优先级/层次；c)分组，包括分段与重组、路由及寻址；d)合法性检查、错误控制、恢复过程；e)同步，包括连接的建立、维护、终止；f)状态、标识和其他报告特征。9)其他特性，如接口实体的物理兼容性(尺寸、容量、负荷、电压、接插件的兼容性等)；f.如果软件配置项包含逻辑，给出其要使用的逻辑，(若适用)包括：1)该软件配置项执行启动时，其内部起作用的条件：2)把控制交给其他软件配置项的条件；3)对每个输入的响应及响应时间，包括数据转换、重命名和数据传送操作；4)该软件配置项运行期间的操作序列和动态控制序列，包括：a)序列控制方法；b)该方法的逻辑与输入条件，如计时偏差、优先级赋值；c)数据在内存中的进出；d)离散输入信号的读出，以及在软件配置项内中断操作之间的时序关系；5)异常与错误处理。6需求的可追踪性本章应包括：a.从本DBDD所提到的每个数据库或其他软件配置项到它们所涉及的系统或CSCI需求的可追踪性；b.从已经分配给本DBDD所提及的数据库或软件配置项的每个系统或CSCI需求到涉及它们的数据库或软件配置项的可追踪性。7注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.15软件测试说明(STD)说明：1.《软件测试说明》(STD)描述执行计算机软件配置项CSCI,系统或子系统合格性测试所用到的测试准备、测试用例及测试过程。2.通过STD需方能够评估所执行的合格性测试是否充分。软件测试说明的正文的格式如下：1引言本章应分成以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。1.3文档概述本条应概述本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。2引用文件 GB/T8567-2006《计算机软件文档编制规范》本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章还应标识不能通过正常的供货渠道获得的所有文档的来源。3测试准备本章应分以下几条，(若适用)应包括用“警告”或“注意”标记的安全提示和保密性与私密性考虑。3.x(测试的项目唯一标识符)本条应用项目唯一标识符标识一个测试并提供简要说明，应分为以下几条。当所需信息与前面为另一测试所指出的信息重复时，此处可作引用而无需重复。3.x.1硬件准备本条应描述为进行测试工作需要做的硬件准备过程。有关这些过程可以引用已出版的操作手册。(若适用)应提供以下内容：a.要使用的特定硬件，用名字和(若适用)编号标识；b.任何用于连接硬件的开关设置和电缆；c.说明硬件、互联控制和数据路径的一个或多个图示；d.使硬件处于就绪状态的分步指令。3.x.2软件准备本条应描述为测试准备被测项和其他有关软件，包括用于测试的数据的必要过程。有关这些过程，可以引用已出版的软件手册。(若适用)应提供下述信息：a.测试中要使用的特定软件；b.被测项的存储媒体(如磁带、盘)；c.任何相关软件(如模拟器、测试驱动程序、数据库)的存储媒体；d.加载软件的指令，包括所需的顺序；e.多个测试用例共同使用的软件初始化指令。3.x.3其他测试前准备本条应描述进行测试前所需的其他人员活动、准备或过程。4测试说明本章应分为以下几条。(若适用)应包括用“警告”或“注意”标记的安全提示和保密性与私密性考虑。4.x(测试的项目唯一标识符)本条应用项目唯一标识符标识一个测试，并分为以下几条。当所需信息与以前提供的信息重复时，此处可作引用而无需重复。4.x.y(测试用例的项目唯一标识符)本条应用项目唯一标识符标识一个测试用例，说明其目的并提供简要描述。下述各条提供测试用例的详细说明。4.x.y.1涉及的需求本条应标识测试用例所涉及的CSCI需求或系统需求(此信息亦可在5.a中提供)。4.x.y.2先决条件本条应标识执行测试用例前必须建立的先决条件，(若适用)应讨论以下内容：a.软、硬件配置；b.测试开始之前需设置或重置的标志、初始断点、指针、控制参数或初始数据；c.运行测试用例所需的预置硬件条件或电气状态；d.计时度量所用的初始条件；e.模拟环境的条件；f.测试用例特有的其他特殊条件。4.x.y.3测试输入本条应描述测试用例所需的测试输入，(若适用)应提供以下内容：a.每一测试输入的名称、用途和说明(如值的范围、准确度)；b.测试输入的来源与用于选择测试输入的方法； GB/T8567-2006《计算机软件文档编制规范》c.测试输入是真实的还是模拟的；d.测试输入的时间或事件序列；e.控制输入数据的方式：1)用最小/合理数量的数据类型和值测试各项；2)对过载、饱和及其他“最坏情况”影响，用各种有效数据类型和值试验被测各项；3)对非常规输入处理用无效数据类型和值试验被测各项；4)如需要允许再测试。4.x.y.4预期测试结果本条应标识测试用例的所有预期测试结果。(若适用)应提供中间结果和最终结果。4.x.y.5评价结果的准则本条应标识用于评价测试用例的中间和最终测试结果的准则。(若适用)应对每一测试结果提供以下信息：a.输出可能变化但仍能接受的范围或准确度；b.构成可接受的测试结果的输入和输出条件的最少组合或选择；c.用时间或事件数表示的最大/最小允许的测试持续时间；d.可能发生的中断、停机或其他系统故障的最大数目；e.允许的处理错误的严重程度；f.当测试结果不明确时执行重测试的条件；g.把输出解释为“指出在输入测试数据、测试数据库/数据文件或测试过程中的不规则性”的条件；h.允许表达测试的控制、状态和结果的指示方式，以及表明下一个测试用例(或许是辅助测试软件的输出)准备就绪的指示方式；i.以上未提及的其他准则。4.x.y.6测试过程本条应定义测试用例的测试过程。测试过程应被定义为以执行步骤顺序排列的、一系列单独编号的步骤。为便于文档维护，可以将测试过程作为附录并在此引用。每个测试过程的适当详细程度依赖于被测试软件的类型。对于某些软件，每次键击可以是一个单独的测试过程步骤；而对于大多数软件，每一步骤可以包括逻辑相关的一串键击或其他动作。适当的详细程度应该有利于规定预期结果并把它们与实际结果进行比较。(若适用)每一测试过程应提供：a.每一步骤所需的测试操作员的动作和设备操作，(若适用)包括以下方面的命令：1)初始化测试用例并运用测试输入；2)检查测试条件；3)执行测试结果的临时评价；4)记录数据；5)暂停或中断测试用例；6)如果需要，请求数据转储或其他帮助；7)修改数据库/数据文件；8)如果不成功，重复测试用例；9)根据该测试用例的要求，应用替代方式；10)终止测试用例。b.对每一步骤的预期结果与评价准则c.如果测试用例涉及多个需求，需标识出哪一个(些)测试过程步骤涉及哪些需求。(亦可在第5章中提供)d.程序停止或指示的错误发生后要采取的动作，如：1)为便于引用，根据指示器记录关键的数据；2)暂停或中止对时间敏感的测试支持软件和测试仪器；3)收集与测试结果有关的系统记录和操作员记录。e.归约和分析测试结果所采用的过程，(若适用)应完成下述各项：1)检测是否已产生了输出； GB/T8567-2006《计算机软件文档编制规范》2)标识由测试用例所产生数据的媒体和位置；3)评价输出，作为继续测试序列的基础；4)与所需的输出对照，评价测试输出。4.x.y.7假设和约束本条应标识所做的任何假设，以及在描述测试用例中由于系统或测试条件而引人的约束或限制，如时间、接口、设备、人员与数据库/数据文件的限制。如果对指定的限制和参数放弃或例外得到批准的话，应对它们加以标识，并且本条应指出它们对测试用例的影响与冲击。5需求的可追踪性本章应包括：a.从本文中的每个测试用例到它所涉及的系统或CSCI需求的可追踪性。如果测试用例涉及多个需求，应包含从每一组测试过程步骤到所涉及的需求的可追踪性(此可追踪性亦可在4.x.y.1中提供).b.从本文所提及的每个系统或CSCI需求到涉及它们的测试用例的可追踪性。对于CSCI测试，是从CSCI软件需求规格说明(SRS)和有关接口需求规格说明(IRS)中的CSCI需求到涉及它们的测试用例的可追踪性。对于系统测试，是从在系统的系统/子系统规格说明(SSS)及有关IRS中的每个系统需求到涉及它们的测试用例的可追踪性。如果测试用例涉及多个需求，则可追踪性应指明涉及每一个需求的具体测试过程步骤。6注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.16软件测试报告(STR)说明：1.《软件测试报告》(STR)是对计算机软件配置项CSCl,软件系统或子系统，或与软件相关项目执行合格性测试的记录。2.通过STR，需方能够评估所执行的合格性测试及其测试结果。软件测试报告的正文的格式如下：1引言本章应分成以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。1.3文档概述本条应概括本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章还应标识不能通过正常的供货渠道获得的所有文档的来源。3测试结果概述本章应分为以下几条提供测试结果的概述。3.1对被测试软件的总体评估本条应： GB/T8567-2006《计算机软件文档编制规范》a.根据本报告中所展示的测试结果，提供对该软件的总体评估；b.标识在测试中检测到的任何遗留的缺陷、限制或约束。可用问题/变更报告提供缺陷信息；c.对每一遗留缺陷、限制或约束，应描述：1)对软件和系统性能的影响，包括未得到满足的需求的标识；2)为了更正它，将对软件和系统设计产生的影响；3)推荐的更正方案/方法。3.2测试环境的影响本条应对测试环境与操作环境的差异进行评估，并分析这种差异对测试结果的影响。3.3改进建议本条应对被测试软件的设计、操作或测试提供改进建议。应讨论每个建议及其对软件的影响。如果没有改进建议，本条应陈述为“无”。4详细的测试结果本章应分为以下几条提供每个测试的详细结果。注：“测试”一词是指一组相关测试用例的集合。4.x(测试的项目唯一标识符)本条应由项目唯一标识符标识一个测试，并且分为以下几条描述测试结果。4.x.1测试结果小结本条应综述该项测试的结果。应尽可能以表格的形式给出与该测试相关联的每个测试用例的完成状态(例如，“所有结果都如预期的那样”，“遇到了问题”，“与要求的有偏差”等)。当完成状态不是“所预期的”时，本条应引用以下几条提供详细信息。4.x.2遇到了问题本条应分条标识遇到一个或多个问题的每一个测试用例。4.x.2.y(测试用例的项目唯一标识符)本条应用项目唯一标识符标识遇到一个或多个问题的测试用例，并提供以下内容：a.所遇到问题的简述；b.所遇到问题的测试过程步骤的标识；c.(若适用)对相关问题/变更报告和备份数据的引用；d.试图改正这些问题所重复的过程或步骤次数，以及每次得到的结果；e.重测试时，是从哪些回退点或测试步骤恢复测试的。4.x.3与测试用例/过程的偏差本条应分条标识与测试用例/测试过程出现偏差的每个测试用例。4.x.3.y(测试用例的项目唯一标识符)本条应用项目唯一标识符标识出现一个或多个偏差的测试用例，并提供：a.偏差的说明(例如，出现偏差的测试用例的运行情况和偏差的性质，诸如替换了所需设备、未能遵循规定的步骤、进度安排的偏差等)。(可用红线标记表明有偏差的测试过程)；b.偏差的理由；c.偏差对测试用例有效性影响的评估。5测试记录本章尽可能以图表或附录形式给出一个本报告所覆盖的测试事件的按年月顺序的记录。测试记录应包括：a.执行测试的日期、时间和地点；b.用于每个测试的软硬件配置，(若适用)包括所有硬件的部件号/型号/系列号、制造商、修订级和校准日期；所使用的软件部件的版本号和名称；c.(若适用)与测试有关的每一活动的日期和时间，执行该项活动的人和见证者的身份。6评价6.1能力。6.2缺陷和限制。 GB/T8567-2006《计算机软件文档编制规范》6.3建议。6.4结论。7测试活动总结总结主要的测试活动和事件。总结资源消耗，如：7.1人力消耗。7.2物质资源消耗。8注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.17软件配置管理计划(SCMP)说明《软件配置管理计划》(SCMP)说明在项目中如何实现配置管理。软件配置管理计划的正本格式如下：1引言本章应分成以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。1.3文档概述本条应概括本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。1.4组织和职责描述软件配置管理(SCM)负责人和软件配置控制委员会(SCCB)的组成以及他们在项目中的职责和权限；说明与项目配置管理相关的人员，如项目经理、部门SCM组长的职责；描述以上人员之间的关系。为了能够清晰的表述，可选用图表的方式进行说明。1.5资源描述项目配置管理活动所需的各种资源，包括人员、培训、工具、设备、设施等等。其中人员是指人力成本，它是根据项目开发计划中的总工时计算得出的。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章还应标识不能通过正常的供货渠道获得的所有文档的来源。3管理描述负责软件配置管理的机构、任务、职责及其有关的接口控制。3.1机构描述在各阶段中负责软件配置管理的机构。描述的内容如下：a.描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构；b.说明项目和子项目与其他有关项目之间的关系；c.指出在软件生存周期各阶段中的软件开发或维护机构与配置控制委员会的相互关系。3.2任务 GB/T8567-2006《计算机软件文档编制规范》描述在软件生存周期各阶段中的配置管理任务以及要进行的评审和检查工作，并指出各个阶段的阶段产品应存放在哪一类软件库中(软件开发库、软件受控库或软件产品库)。3.3职责描述与软件配置管理有关的各类机构或成员的职责，并指出这些机构或成员相互之间的关系：a.指出负责各项软件配置管理任务(如配置标识、配置控制、配置状态记录以及配置的评审与检查)的机构的职责；b.指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系；c.说明由本计划第3.2条指明的生存周期各阶段的评审、检查和审批过程中的用户职责以及相关的开发和维护活动；d.指出与项目有关的各个机构的代表的软件配置管理职责；e.指出其他特殊职责，例如为满足软件配置管理要求所必要的批准要求。3.4接口控制描述：a.接口规格说明标识和文档控制的方法；b.对已交付的接口规格说明和文档进行修改的方法；c.对要完成的软件配置管理活动进行跟踪的方法；d.记录和报告接口规格说明和文档控制状态的方法；e.控制软件和支持它运行的硬件之间的接口的方法。3.5实现规定实现软件配置管理计划的主要里程碑，例如：a.建立配置控制委员会；b.确定各个配置基线；c.建立控制接口协议；d.制订评审与检查软件配置管理计划和规程；e.制订相关的软件开发、测试和支持工具的配置管理计划和规程。3.6适用的标准、条例和约定3.6.1指明所适用的软件配置管理标准、条例和约定必须说明这些标准、条例和约定要实现的程度。3.6.2描述要在本项目中编写和实现的软件配置管理标准、条例和约定这些标准、条例和约定可以包括以下内容：a.软件结构层次树中软件位置的标识方法；b.程序和模块的命名约定；c.版本级别的命名约定；d.软件产品的标识方法；e.规格说明、测试计划与测试规程、程序设计手册及其他文档的标识方法；f.媒体和文档管理的标识方法；g.文档交付过程；h.软件产品库中软件产品人库、移交或交付的过程；i.问题报告、修改请求和修改次序的处理过程；j.配置控制委员会的结构和作用；k.软件产品交付给用户的验收规程；l.软件库的操作，包括准备、存储和更新模块的方法；m.软件配置管理活动的检查；n.问题报告、修改请求或修改次序的文档要求，指出配置修改的目的和影响；o.软件进人配置管理之前的测试级别； GB/T8567-2006《计算机软件文档编制规范》P.质量保证级别，例如，在进人配置管理之前，验证软件满足有关基线的程度。4软件配置管理活动本章描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等四方面的软件配置管理活动的需求。4.1配置标识4.1.1本条必须详细说明软件项目的基线(即最初批准的配置标识)把它们与本计划的3.2条描述的生存周期的特定阶段相联系。在软件生存周期中，主要有三种基线，它们是功能基线、分配基线和产况，基线。对于每个基线，必须描述下列内容：a.每个基线的项(包括应交付的文档和程序)；b.与每个基线有关的评审与批准事项以及验收标准；c.在建立基线的过程中用户和开发者参与情况。例如，在产品基线中，要定义的元素可以包括：a.产品的名字和命名规则；b.产品标识编号；c.对每一个新交付的版本，要给出版本交付号、新修改的描述、修改交付的方法、对支持软件的修改要求以及对有关文档的修改要求；d.安装说明；e.已知的缺陷和故障；f.软件媒体和媒体标识。4.1.2本条必须描述本项目所有软件代码和文档的标题、代号、编号以及分类规程例如，对代码来说：a.编译日期可以作为每个交付模块标识的一部分；b.在构造模块源代码的顺序行号时，应使它适合于模块作进一步的修改。4.2配置控制4.2.1本条必须描述在本计划3.2条描述的软件生存周期中各个阶段使用的修改批准权限的级别.4.2.2本条必须定义对已有配置的修改申请进行处理的方法其中包括：a.详细说明在本计划第3.2条描述的软件生存周期各个阶段中提出修改申请的程序(可以用注上自然语言的流程图来表达)；b.描述实现已批准的修改申请(包括源代码、目标代码和文档的修改)的方法；c.描述软件库控制的规程，其中包括库存软件控制、对于适用基线的读写保护、成员保护、成员标识、档案维护、修改历史以及故障恢复等七项规程；d.如果有必要修补目标代码，则要描述其标识和控制的方法。4.2.3对于各个不同层次的配置控制组和其他修改管理机构本条必须：a.定义其作用，并规定其权限和职责；b.如果已组成机构，则指明该机构的领导人及其成员；c.如果还没有组成机构，则说明怎样任命该机构的领导人、成员及代理人；d.说明开发者和用户与配置控制组的关系。4.2.4当要与不属于本软件配置管理计划适用范围的程序和项目进行接口时，本条必须说明对其进行配置控制的方法如果这些软件的修改需要其他机构在配置控制组评审之前或之后进行评审，则本条必须描述这些机构的组成、它们与配置控制组的关系以及它们相互之间的关系。4.2.5本条必须说明与特殊产品(如非交付的软件、现存软件、用户提供的软件和内部支持软件)有关的配置控制规程.4.3配置状态的记录和报告本条必须： GB/T8567-2006《计算机软件文档编制规范》a.指明怎样收集、验证、存储、处理和报告配置项的状态信息；b.详细说明要定期提供的报告及其分发办法；c.如果有动态查询，要指出所提供的动态查询的能力；d.如果要求记录用户说明的特殊状态时，要描述其实现手段。例如，在配置状态记录和报告中，通常要描述的信息有：a.规格说明的状态；b.修改申请的状态；c.修改批准的报告；d.产品版本或其修改版的状态；e.安装、更新或交付的实现报告；f.用户提供的产品(如操作系统)的状态；g.有关开发项目历史的报告。4.4配置的检查和评审本条必须：a.定义在本计划的3.2条所定义的软件生存周期的特定点上执行的检查和评审中软件配置管理计划的作用；b.规定每次检查的评审所包含的配置项；c.指出用于标识和解决在检查和评审期间发现的问题的工作流程。5工具、技术和方法本章必须指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法。例如，可以包括用于下列任务的工具，技术和方法：a.软件媒体和媒体文档的标识。b.把文档和媒体置于软件配置管理的控制之下，并把它正式地交付给用户。例如，要给出对软件库内的源代码和目标代码进行控制的工具、技术和方法的描述；如果用到数据库管理系统，则还要对该系统进行描述。又如，要指明怎样使用软件库工具、技术和方法来处理软件产品的交付。c.编制关于程序及其有关文档的修改状态的文档。因此必须进一步定义用于准备多种级别(如项目负责人、配置控制小组、软件配置管理人员和用户)的管理报告的工具、技术和方法。6对供货单位的控制供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购买的、其他开发单位开发的或从软件开发单位现存软件库中选用的软件能满足规定的软件配置管理需求。管理规程应该规定在本软件配置管理计划的执行范围内控制供货单位的方法；还应解释用于确定供货单位的软件配置管理能力的方法以及监督它们遵循本软件配置管理计划需求的方法。7记录的收集、维护和保存本章必须指明要保存的软件配置管理文档，指明用于汇总、保护和维护工程文档的方法和设施(其中包括要使用的后备设施)，并指明要保存的期限。8配置项和基线8.1配置项命名规则根据组织的《标识规范》，对不同类型的配置项建立命名规则。配置项类型命名规则的说明8.2配置项的识别和基线的划分列出识别到的所有配置项和所属的配置基线，并明确配置项的标识、作者(或负责人)和配置时间。配置基线配置项名称配置项标识作者/负责人配置时间 GB/T8567-2006《计算机软件文档编制规范》8.3变更和发布描述配置项和基线变更、发布的流程以及相应的批准权限。为了能够清晰的表述，应选用图表的方式进行说明。9备份说明配置库和配置管理库的备份方式、频度、责任人。10日程表列出项目配置管理活动的日程表，并确保配置管理活动的日程表与项目开发计划以及质量保证计划保持一致。阶段活动日期11注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A，B等)编排。附表附表1:产品发布清单产品发布清单项目名称项目标识发布范围产品发布清单序号产品名称所属基线密级版本号是否收回规定收回时间发布列表发布对象序号发布人发布日期回收日期备注姓名所属部门确认签名项目标识：按照《标识规范》为项目分配的标识号发布范围：产品发布到公司内外哪些部门所属基线：随着项目的进展，产品当前配置到的项目基线密级：绝密、机密、秘密、普通发布对象:产品被发布到的责任人 GB/T8567-2006《计算机软件文档编制规范》附表2:配置变更申请单配置变更申请表1.项目(系统)名称：2.变更标识号：3.基线类别：4.申请人姓名：5.申请日期：6.变更描述：7.变更理由：评估8.估计工时：11.受影响配置项：版本:9.需要资源：10.评估人：日期变更批准12.审批人：16.变更配置项:版本:意见：日期13.变更实施人：日期：14.完成日期:15.实际工时:基线更新批准17审批人：18.SQA批准：意见：日期：日期：19更新人：20.备注:日期：变更标识号：项目标识＋变更序号基线类别：正式基线变更、(非正式基线变更)开发基线变更需要资源：需要哪些工具、哪方面的人员、哪方面的培训受影响配置项:估计将受影响的配置项变更配置项：实际发生变更的配置项 GB/T8567-2006《计算机软件文档编制规范》附表3:配置问题报告单配置问题报告单1.项目(系统)名称：2.问题标识号：3.基线类别：4.报告人姓名：5.报告日期：6.问题描述：7.影响范围：评估8.估计工时：11.受影响配置项：版本:9.需要资源：10.评估人：日期变更批准12.审批人：16.变更配置项:版本:意见：日期13.变更实施人：日期：14.完成日期:15.实际工时:基线更新批准17审批人：18.SQA批准：意见：日期：日期：19更新人：20.备注:日期：问题标识号：项目标识＋向题序号基线类别：需求、设计、代码、交付基线等影响范围：估计将受影响的功能组件、模块、配置等需要资源：需要哪些工具、哪方面的人员、哪方面的培训受影响配置项：估计将受影响的配置项变更配置项：实际发生变更的配置项 GB/T8567-2006《计算机软件文档编制规范》附表4:配置变更和问题登录表配置变更和问题登录表项目名称：配置管理员：修改前版本/纳入基线状态及标识号申请人申请日期概述受影响配置项批准情况实施人完成日期修改后版本日期标识日期标识号：变更申请标识号或问题标识号批准情况：批准、拒绝、延缓状态及标识日期：配置项当前的变更状态(参见本程序文件)及记录当前状态的时间附表5:配置状态统计报告配置状态统计报告项目名称:统计人：统计日期：变更状态基线标识配置项标序号版本号序号版本号变更或变更开受影响配置项及变更完纳入基状态及/名称识/名称变更人变更简述问题编号始日期变更后版本号成日期线日期标识日期“基线标识”前的“序号”:指基线的序号“配置项标识”前的“序号”：指配置项在该基线中的序号 GB/T8567-2006《计算机软件文档编制规范》附表6:配置审核报告配置审核报告项目名称:审核类型：基线审核软件发布审核审核人员：日期：工作产品审核应完成的工作产品完成情况变更情况审核变更/问题编号变更开始日期变更计划完成日期是否完成相关项更新情况版本描述文件完备性审核版本号:版本说明评价:配置项追溯关系审核配置项追溯关系维护情况:质量检查点和质量保证活动审核质量检查点的设置及检查活动完成情况:质量保证活动完成情况:相关项更新情况:指定配置变更请求或问题报告单中所有受影响配置项的变更情况说明(是否完成、实施状态)版本说明评价、配置项追溯关系维护情况：是否完整、准确，存在哪些问题7.18软件质量保证计划(SQAP)说明《软件质量保证计划》(SQAP)规定在项目中采用的软件质量保证的措施、方法和步骤。软件质量保证计划的正文的格式如下：1引言本章应分成以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他 GB/T8567-2006《计算机软件文档编制规范》有关文档。1.3文档概述本条应概述本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。1.4组织和职责描述SQA负责人在项目中的职责和权限；相应的高层经理、与SQA紧密配合的项目经理的职责；部门内部SQA组长的职责和与项目SQA负责人的关系。1.5资源描述出项目质量保证活动所需的各种资源，包括人员、培训、工具、设备、设施，等等。其中人员是指人力成本，它是根据项目开发计划中的总工时计算得出的。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。也应标识不能通过正常的供货渠道获得的所有文档的来源。3管理必须描述负责软件质量保证的机构、任务及其有关的职责。3.1机构必须描述与软件质量保证有关的机构的组成，还必须清楚地描述来自项目委托单位、项目承办单位、软件开发单位或用户中负责软件质量保证的各个成员在机构中的相互关系。3.2任务必须描述计划所涉及的软件生存周期中有关阶段的任务，特别是要把重点放在描述这些阶段所应进行的软件质量保证活动上。3.3职责必须指明软件质量保证计划中规定的每一个任务的负责单位或成员的责任。4文档必须列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档，并描述对文档进行评审与检查的准则。4.1基本文档为了确保软件的实现满足需求，至少需要下列基本文档：a.软件需求规格说明(或软件规格说明)。b.软件(结构)设计说明。c.测试计划与测试报告。d.软件验证与确认计划。软件验证与确认计划必须描述所采用的软件验证与确认的方法(例如评审、检查、分析、演示或测试等)，以用来验证软件需求(规格)说明中的需求是否已由软件(结构)设计说明描述的设计实现；软件(结构)设计说明表达的设计是否已由编码实现。软件验证与确认计划还可用来确认编码的执行是否与软件需求(规格)说明中所规定的需求相一致。软件验证和确认报告必须描述软件验证与确认计划的执行结果。这里必须包括软件质量保证计划所需要的所有评审、检查和测试的结果。4.2用户文档例如，用户手册、操作手册等。4.3其他文档除上述文档外，还应包括以下文档：a.项目开发计划(其中可包括软件配置管理计划，必要时该计划也可单列)。b.项目进展报表。c.项目开发各阶段的评审报表。d.项目总结报告。5.标准、规程和约定必须列出软件开发过程中要用到的标准、规程和约定，并列出监督和保证执行的措施。 GB/T8567-2006《计算机软件文档编制规范》6.评审和检查必须规定所要进行的技术和管理两方面的评审和检查工作，并编制或引用有关的评审和检查规程以及通过与否的技术准则。至少要进行下列各项评审和检查工作：6.1软件需求(规格)评审在软件需求分析阶段结束后必须进行软件需求评审，以确保在软件需求(规格)说明中所规定的各项需求的合适性。6.2系统/子系统设计评审在系统/子系统设计结束后必须进行系统/子系统设计的评审，以评价软件(结构)设计说明中所描述的软件设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。6.3软件设计评审在软件设计结束后必须进行软件设计的评审，以评价软件(结构)设计说明中所描述的软件设计，在功能、算法和过程描述等方面的合适性。6.4软件验证与确认计划评审在制订软件验证与确认计划之后要对它进行评审，以评价软件验证与确认计划中所规定的验证与确认方法的合适性与完整性。6.5功能检查在软件发行前，要对软件进行功能检查，以确认已经满足在软件需求规格说明中规定的所有需求。6.6物理检查在验收软件前，要对软件进行物理检查，以验证程序和文档已经一致并已做好了交付的准备。6.7综合检查在软件验收时，要允许用户或用户委托的专家对所要验收的软件进行设计抽样的综合检查，以验证代码和设计文档的一致性、接口规格说明之间的一致性(硬件和软件)、设计实现和功能需求之间的一致性、功能需求和测试描述的一致性。6.8管理评审要对计划的执行情况定期(或按阶段)进行管理评审；这些评审必须由独立于被评审单位的机构或授权的第三方主持进行。7项目策划阶段的SQA活动描述SQA负责人参与制定项目的软件开发计划和配置管理计划的活动，以及它们三者之间的关系。8评审和审核8.1过程的评审描述对项目进行过程评审的方法和依据，并在下表中列出项目定义的过程以及相应的过程评审。8.2工作产品的审核描述进行产品审核的方法和依据，并在下表中列出项目过程应产生的工作产品和质量记录，以及需要由SQA负责人审核的工作产品和相应的产品审核活动。8.3不符合问题的解决描述过程评审和产品审核的结果怎样形成记录，应形成哪些记录。描述处理在评审中出现的不符合问题的解决方法。阶段项目定义的过程工作产品质量记录评审/审核活动9软件配置管理必须编制有关软件配置管理的条款，或单独制订文档。在这些条款或文档中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施；必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。10工具、技术和方法 GB/T8567-2006《计算机软件文档编制规范》必须指明用以支持特定软件项目质量保证工作的工具、技术和方法，描述它们的用途。11媒体控制必须指出保护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化。12对供货单位的控制供货单位包括项目承办单位、软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的规程，从而保证项目承办单位从软件销售单位购买的、其他开发单位(或子开发单位)开发的或从开发(或子开发)单位现存软件库中选用的软件能满足规定的需求。13记录的收集、维护和保存必须指明需要保存的软件质量保证活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限。14日程表列出项目质量保证活动的日程表，并确保质量保证的日程表与项目开发计划以及配置管理计划保持一致。阶段活动日期15注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。附表1:问题报告单问题报告单标题记录编号保存期配置人姓名提交日期年月日配置状态1评审中2修改中3修改完成未测评4测评通过(关闭)5以后关闭问题类别确定和审批确定是否修改设计A(需修改设计)B(不修改设计)设计变更理由(B类不填)项目负责人签字：日期：项目信息项目名项目标识号问题分析问题所在阶段需求分析系统设计实现测试安装验收运行维护问题描述(如空间不够可加附页):姓名问题发现日期年月日报告人单位联系电话 GB/T8567-2006《计算机软件文档编制规范》B类问题解决记录问题报告单标题问题报告单编号姓名项目组问题解决人开始日期完成日期确认项目组长签字日期问题解决说明(如空间不够可加附页):附表2：设计变更报告单设计变更报告单标题记录编号评审报告编号评审日期年月日标题问题报告单编号项目名项目标识号姓名联系电话修改人单位修改描述(如空间不够可加附页):附表3:计划修订申请单计划修订申请单标题记录编号配置人姓名提交日期年月日配置状态1评审中2修订中3修订完成未评审4评审通过(关闭)项目名项目标识号姓名联系电话修改人单位申请修订的主要理由:审批意见:审批人职务审批人签字日期 GB/T8567-2006《计算机软件文档编制规范》附表4:项目月报表##月份项目月报总部名称记录编号质量管理员提交日期年月日项目名项目标识号计划完成情况已完成项(包括质量保证活动):已完成项(包括质量保证活动):存在的主要问题和困难:下月主要安排开发:质量保证:附表5：设计评审报告设计评审报告标题记录编号评审性质评审复审评审日期年月日项目名项目标识号评审对象名称阶段名开发策划需求分析系统设计实现测试安装验收设计变更计划完成情况评审内容(如空间不够可加附页):评审结论(如空间不够可加附页):评审组长签字签字日期 GB/T8567-2006《计算机软件文档编制规范》附表6：评审人员名单评审人员名单标题评审报告编号姓名单位职称/职务联系电话签名7.19开发进度月报(DPMR)说明：开发进度月报的编制目的是及时向有关管理部门汇报项目开发的进展和情况，以便及时发现和处理开发过程中出现的问题。一般地，开发进度月报是以项目组为单位每月编写的，如果被开发的软件系统规模比较大，整个工程项目被划分给若干个分项目组承担，开发进度月报将以分项目组为单位按月编写。开发进度月报的正文格式如下：1引言本章应分成以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。1.3文档概述本条应概述本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。应说明：a.开发中的软件系统的名称和标识符；b.分项目名称和标识符；c.分项目负责人签名；d.本期月报编写人签名；e.本期月报的编号及所报告的年月。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。也应标识不能通过正常的供货渠道获得的所有文档的来源。3工程进度与状态3.1进度列出本月内进行的各项主要活动，并且说明本月内遇到的重要事件，这是指一个开发阶段(即软件生存周期内各个阶段中的某一个，例如需求分析阶段)的开始或结束，要说明阶段的名称及开始(或结束)的日期。3.2状态说明本月的实际工作进度与计划相比，是提前了、按期完成了或是推迟了？如果与计划不一致，要说明原因及准备采取的措施。4资源耗用与状态4.1资源耗用主要说明本月份内耗用的工时与机时。 GB/T8567-2006《计算机软件文档编制规范》4.1.1工时分为三类：a.管理用工时。包括在项目管理(制订计划、布置工作、收集数据、检查汇报工作等)方面耗用的工时；b.服务工时。包括为支持项目开发所必须的服务工作及非直接的开发工作所耗用的工时；c.开发用工时。要分各个开发阶段填写。4.1.2机时说明本月内耗用的机时，以小时为单位，说明计算机系统的型号。4.2状态说明本月内实际耗用的资源与计划相比，是超出了、相一致、还是不到计划数？如果与计划不一致，说明原因及准备采取的措施。5经费支出与状态5.1经费支出5.1.1支持性费用列出本月内支出的支持性费用，一般可按如下七类列出，并给出本月支持费用的总和：a.房租或房屋折旧费；b.工资、奖金、补贴；c.培训费。包括教师的酬金及教室租金；d.资料费。包括复印及购买参考资料的费用；e.会议费。召集有关业务会议的费用；f.旅差费；g.其他费用。5.1.2设备购置费列出本月内实际支出的设备购置费，一般可分如下三类：a.购买软件的名称与金额；b.购买硬设备的名称、型号、数量及金额；c.已有硬设备的折旧费。5.2状态说明本月内实际支出的经费与计划相比较，是超过了、相符合、还是不到计划数？如果与计划不一致，说明原因及准备采取的措施。6下个月的工作计划7建议本月遇到的重要问题和应引起重视的问题及因此产生的建议。8注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.20项目开发总结报告(PDSR)说明：项目开发总结报告的编制是为了总结本项目开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。项目开发总结报告的正文格式如下：1引言本章应分成以下几条。 GB/T8567-2006《计算机软件文档编制规范》1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。1.3文档概述本条应概述本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。也应标识不能通过正常的供货渠道获得的所有文档的来源。3实际开发结果3.1产品说明最终制成的产品，包括：a.本系统(CSCI)中各个软件单元的名字，它们之间的层次关系，以千字节为单位的各个软件单元的程序量、存储媒体的形式和数量；b.本系统共有哪几个版本，各自的版本号及它们之间的区别；c.所建立的每个数据库。如果开发计划中制订过配置管理计划，要同这个计划相比较。3.2主要功能和性能逐项列出本软件产品所实际具有的主要功能和性能，对照可行性分析(研究)报告、项目开发计划、功能需求说明书的有关内容，说明原定的开发目标是达到了、未完全达到、或超过了。3.3基本流程用图给出本程序系统的实际的基本的处理流程。3.4进度列出原计划进度与实际进度的对比，明确说明实际进度是提前了，还是延迟了，分析主要原因。3.5费用列出原定计划费用与实用支出费用的对比，包括：a.工时，以人月为单位，并按不同级别统计；b.计算机的使用时间，区别CPU时间及其他设备时间；c.物料消耗、出差费等其他支出。明确说明，经费是超过了，还是节余了，分析主要原因。4开发工作评价4.1对生产效率的评价给出实际生产效率，包括：a.程序的平均生产效率，即每人月生产的行数；b.文件的平均生产效率，即每人月生产的千字数。并列出原计划数作所对比。4.2对产品质量的评价说明在测试中检查出来的程序编制中的错误发生率，即每千条指令(或语句数)中的错误指令数(或语句数)。如果开发中制订过质量保证计划或配置管理计划，要同这些计划相比较。4.3对技术方法的评价给出在开发中所使用的技术、方法、工具、手段的评价。4.4出错原因的分析给出对于开发中出现的错误的原因分析。 GB/T8567-2006《计算机软件文档编制规范》4.5风险管理a.初期预计的风险；b.实际发生的风险；c.风险消除情况。5缺陷与处理分别列出在需求评审阶段、设计评审阶段、代码测试阶段、系统测试阶段和验收测试阶段发生的缺陷及处理情况。6经验与教训列出从这项开发工作中得到的最主要的经验与教训及对今后的项目开发工作的建议。7注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。附表附表:项目总结报告项目总结报告项目编写审批一般性信息1.生产效率2.质量3.项目工期初始估算实际延误起始日期4.过程裁剪情况5.使用的工具风险管理1.初期预估的风险规模估算项估算规模实际规模工作量1.团队最大规模2.估算工作量3.实际工作量4.工作量在各阶段的分布阶段任务(人时)审查(人时)返工(人时)总计(人时)总计(人时)质量成本(COQ)COQ=(审查工作量＋返工工作量＋测试工作量＋培训工作量)/总工作量×100% GB/T8567-2006《计算机软件文档编制规范》质量成本(COQ)值COQ=5.工作量在各阶段的分布比例和偏差估算值实际值阶段偏差(％)工作量(人日)工作量(％)工作量(人日)工作量(％)总计100100缺陷1.缺陷分布情况估算值实际值缺陷检测阶段偏差(％)缺陷数量占总缺陷数(％)缺陷数量占总缺陷数(％)需求评审设计评审代码测试系统测试验收测试总计1001002.缺陷消除率缺陷引人阶段缺陷消除率缺陷检测阶段需求设计实现其他(％)需求评审设计评审代码测试系统测试验收测试因果分析偏差偏差原因提交的过程资产总结论 GB/T8567-2006《计算机软件文档编制规范》7.21软件产品规格说明(SPS)说明：1.《软件产品规格说明》(SPS)包含有或引用了可执行软件、源文件以及软件支持的信息。包括一个计算机软件配置项(CSCI)“已建成”的设计信息和编辑、构造及修改的过程等。2.SPS可被用于订购可执行软件和/或对应于该CSCI的源文件。它是针对该CSCI的基本的软件支持文档。注意，不同的组织对软件的订购和移交有着不同的策略。这种策略应在使用这个文档之前决定。软件产品规格说明的正文的格式如下：1引言本章应分成以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。1.3文档概述本条应概述本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。也应标识不能通过正常的供货渠道获得的所有文档的来源。3需求本章应分为以下几条，规定必须满足的需求，以实现软件交付和建立另一软件实体，以使其被认为是该CSCI的一个有效拷贝。注：本章将软件自身作为被认为是CSCI的一个有效拷贝软件实体所必须匹配的准则。被更新的软件设计不作为需求，而被放在第5章，仅作为用于修改、增强或其他支持该软件时所使用的信息。如果此规格说明的任何部分被置于需方配置的控制之下，只应限于第3章。建立产品基线的是软件自身，而不是软件的设计说明.3.1可执行软件本条应通过引用所附的或其他形式提供的电子媒体给出CSCI的可执行软件，它应包括在目标计算机上安装和操作该软件所需的批处理文件、命令文件、数据文件或其他软件文件。为使一软件实体被认为是CSCI可执行软件的有效拷贝，它必须精确匹配这些文件。3.2源文件本条应通过引用所附的或其他形式提供的电子媒体给出该CSCI的源文件，它应包括重新产生CSCI的可执行软件所需的批处理文件、命令文件、数据文件或其他文件。为使一软件实体被认为是该CSCI源文件的有效拷贝，它必须精确匹配这些文件。3.3打包需求(若有)本条应陈述打包和标记CSCI拷贝的需求。4合格性规定本条应陈述用于证明给定软件实体是CSCI有效拷贝要使用的方法。例如，针对可执行文件所使用的方法可以这样制定，即3.1条中引用到的每个可执行文件在当前所讨论软件中有相同命名的对等实体，并且可通过按位比较、检查和、或其他方法表明每个这样的对等实体和对应的可执行文件是相同的。针对源文件所使用的方法是与3.2条中引用的源文件进行比较。5软件支持信息本章应分为以下几条提供为了支持CSCI所需的信息。5.1“已建成”软件设计本条应包含描述“已建成”CSCI设计的信息，或引用包含此信息的一个附录或其他可交付的文档。(若适 GB/T8567-2006《计算机软件文档编制规范》用)此信息应与软件(结构)设计说明(SDD)、接口设计说明(IDD)和数据库(顶层)设计说明(DBDD)所要求的信息相同。如果这些文档或其等价物要随“已建成”CSCI交付，本条应引用它们。否则，此信息应在本文档中提供。可以引用头文件、注释、源代码清单中的代码提供的信息，此处无需重复。如果SDD,IDD或DBDD是以附录的形式提供的话，无需变更其条号与页码。5.2编译/建立过程本条应描述从源文件创建可执行文件和准备向固件或其他分布媒体中加载可执行文件所要使用的编译/建立过程，或引用描述此信息的附录。应指定所用的编译程序/汇编程序，包括版本号：其他所需的软、硬件，包括版本号；要使用的设置、选项或约定；和编译/汇编、连接和建立CSCI和包含CSCI的软件系统/子系统的过程，包括对不同现场、配置、版本的变更等。CSCI级之上的建立过程可以在一个SPS中给出，而在其他SPS中引用。5.3修改过程本条应描述修改CSCI必须遵循的过程。(若适用)包括或引用下述信息：a.支持设施、设备和软件，以及它们的使用过程；b.CSCI所使用的数据库/数据文件，以及使用与修改它们的过程；c.设计、编码、及其他应遵循的约定；d.(若有)与上述不同的编译/建立过程；e.应遵循的集成与测试过程。5.4计算机硬件资源使用本条应描述“已建成的"CSCI对计算机硬件资源(如处理器能力、内存容量、输入/输出设备能力、辅存容量和通信/网络设备能力)的量化的使用情况。应覆盖包括在CSCI使用需求中的、影响CSCI的系统级资源分配中的、或软件开发计划中的所有计算机硬件资源。如果一个给定的计算机硬件资源的所有使用数据出现在同一个地方，如在一个SPS中，则本条可以引用它。针对每一计算机硬件资源，应包括：a.得到满足的CSCI需求或系统级资源分配(到CSCI需求的可追踪性可在6.c中提供)；b.使用数据所基于的假设和条件(例如，典型用法、最坏情况用法、特定事件的假设)；c.影响使用的特殊考虑(例如虚存的使用、覆盖、多处理器或操作系统开销的影响、库软件或其他的实现开销等)；d.所采用的计量单位(例如处理器能力百分比、每秒周期、存储器字节数、每秒千字节等)；e.所进行的评估或计量的级别(例如软件配置项、CSCI,或可执行程序)。6需求的可追踪性本章应包括：a.从每一CSCI源文件到它所实现的软件配置项的可追踪性；b.从每一软件配置项到实现它的源文件的可追踪性；c.从5.4中给定的每一计算机硬件资源使用计量到它所涉及的CSCI需求的可追踪性。(此可追踪性也可在5.4中提供)；d.从有关计算机硬件资源使用的每一CSCI需求到5.4中给定的使用计量的可追踪性。7注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.22软件版本说明(SVD)说明：1.《软件版本说明》(SVD)标识并描述了由一个或多个计算机软件配置项(CSCI)组成的一个软件的版本。它被用于发行、追踪以及控制软件的版本。 GB/T8567-2006《计算机软件文档编制规范》2.术语”版本”可用于软件的最初发行，用于其后续的发行，或用于在几乎同时发行的软件的多种形式之一(例如，用于不同的场所等)。软件版本说明的正文的格式如下：1引言本章应分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。它也应标识SVD预期的接受者和该标识影响发行软件的内容的程度(例如，源代码可能不向所有的接受者发行)。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统和软件的一般特性；概述系统的开发、运行与维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关的文档。1.3文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性或私密性要求。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。也应标识不能通过正常的供货渠道获得的所有文档的来源。3版本说明本章应分为以下几条。3.1发行材料清单(若适用)本条应通过标识号、标题、缩略语、日期、版本号和发行号列出构成发行软件的所有物理媒体(例如列表、磁带、磁盘)和有关的文档。它应包括适用于这些项的保密性和私密性要求、处理它们的安全措施(例如对静电和磁场的关注)和关于复制和许可证条款的说明和制约。3.2软件内容清单(若适用)本条应通过标识号、标题、缩略语、日期、版本号和发行号列出构成发行软件版本的所有计算机文件。应包含适用的保密性和私密性要求。3.3已安装的变更本条应包含一张列表，记录当前的软件版本自上一个版本后引人的所有变更。如果使用了变更类别，则变更应按这些类别进行划分。(若适用)本条应标识与每一变更和(若有)每一变更对系统运行和其他软硬件接口产生的影响相关的问题报告、变更建议和变更通告。本条不适用于最初的软件版本。3.4适应性资料本条应标识或引用包含在软件版本中的所有场地专用的资料。对于第一版之后的软件版本，本条应描述对适应性资料做的变更。3.5相关文档(若适用)本条应按标识号、标题、缩略语、日期、版本号和发行号列出与发行软件有关但未包含在其中的所有文档。3.6安装指令(若适用)本条应提供或引用以下信息：a.安装该软件版本的指令；b.为使该版本可用而必须安装的其他变更的标识，包括未包含在软件版本中的场地专用的适应性资料；c.与安装有关的保密性、私密性和安全提示；d.判定版本是否被正确安装的过程；e.安装中遇到问题后的求助联系地点。3.7可能的问题和已知的错误本条应标识软件版本在发行时可能存在的问题或已知的错误、解决问题和错误应采取的步骤、以及说明(直 GB/T8567-2006《计算机软件文档编制规范》接或通过引用)如何识别、避免、更正或处理问题和错误的处理措施。给出的信息应适合于SVD预期的受众(例如一个用户机构可能需要避免错误的建议，支持机构则需要改正错误的建议)。4注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.23软件用户手册(SUM)说明：1.《软件用户手册》(SUM)描述手工操作该软件的用户应如何安装和使用一个计算机软件配置项(CSCI),一组CSCI,一个软件系统或子系统。它还包括软件操作的一些特别的方面，诸如，关于特定岗位或任务的指令等。2.SUM是为由用户操作的软件而开发的，具有要求联机用户输入或解释输出显示的用户界面。如果该软件是被嵌人在一个硬件一软件系统中，由于已经有了系统的用户手册或操作规程，所以可能不需要单独的SUM.软件用户手册的正文的格式如下：1引言本章应分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统和软件的一般特性；概述系统的开发、运行与维护历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关的文档。1.3文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性或私密性要求。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。也应标识不能通过正常的供货渠道获得的所有文档的来源。3软件综述本章应分为以下几条。3.1软件应用本条应简要说明软件预期的用途。应描述其能力、操作上的改进以及通过本软件的使用而得到的利益。3.2软件清单本条应标识为了使软件运行而必须安装的所有软件文件，包括数据库和数据文件。标识应包含每份文件的保密性和私密性要求和在紧急时刻为继续或恢复运行所必需的软件的标识。3.3软件环境本条应标识用户安装并运行该软件所需的硬件、软件、手工操作和其他的资源。(若适用)包括以下标识：a.必须提供的计算机设备，包括需要的内存数量、需要的辅存数量及外围设备(诸如打印机和其他的输入/输出设备)；b.必须提供的通信设备；c.必须提供的其他软件，例如操作系统、数据库、数据文件、实用程序和其他的支持系统；d.必须提供的格式、过程或其他的手工操作；e.必须提供的其他设施、设备或资源。 GB/T8567-2006《计算机软件文档编制规范》3.4软件组织和操作概述本条应从用户的角度出发，简要描述软件的组织与操作。(若适用)描述应包括：a.从用户的角度来看的软件逻辑部件和每个部件的用途/操作的概述；b.用户期望的性能特性，例如：1)可接受的输入的类型、数量、速率；2)软件产生的输出的类型、数量、精度和速率；3)典型的响应时间和影响它的因素；4)典型的处理时间和影响它的因素；5)限制，例如可追踪的事件数目；6)预期的错误率；7)预期的可靠性。c.该软件执行的功能与所接口的系统、组织或岗位之间的关系；d.为管理软件而采取的监督措施(例如口令)。3.5意外事故以及运行的备用状态和方式(若适用)本条应解释在紧急时刻以及在不同运行状态和方式下用户处理软件的差异。3.6保密性和私密性本条应包含与该软件有关的保密性和私密性要求的概述。(若适用)应包括对非法制作软件或文档拷贝的警告。3.7帮助和问题报告本条应标识联系点和应遵循的手续，以便在使用软件时遇到的问题时获得帮助并报告间题。4访问软件本章应包含面向首次/临时的用户的逐步过程。应向用户提供足够的细节，以使用户在学习软件的功能细节前能可靠地访问软件。在合适的地方应包含用“警告”或“注意”标记的安全提示。4.1软件的首次用户本条应分为以下几条。4.1.1熟悉设备合适的话，本条应描述以下内容：a.打开与调节电源的过程；b.可视化显示屏幕的大小与能力；c.光标形状，如果出现了多个光标如何标识活动的光标，如何定位光标和如何使用光标；d.键盘布局和不同类型键与点击设备的功能；e.关电过程，如果需要特殊的操作顺序的话。4.1.2访问控制本条应提供用户可见的软件访问与保密性特点的概述。(若适用)本条应包括以下内容：a.怎样获得和从谁那里获得口令；b.如何在用户的控制下添加、删除或变更口令；c.与用户生成的输出报告及其他媒体的存储和标记有关的保密性和私密性要求。4.1.3安装和设置本条应描述为标识或授权用户在设备上访问或安装软件、执行安装、配置软件、删除或覆盖以前的文件或数据和键人软件操作的参数必须执行的过程。4.2启动过程本条应提供开始工作的步骤，包括任何可用的选项。万一遇到困难时，应包含一张问题定义的检查单。4.3停止和挂起工作本条应描述用户如何停止或中断软件的使用和如何判断是否是正常结束或终止。5使用软件指南本章应向用户提供使用软件的过程。如果过程太长或太复杂，按本章相同的段结构添加第6章，第7章„„， GB/T8567-2006《计算机软件文档编制规范》标题含义与所选择的章有关。文档的组织依赖于被描述的软件的特性。例如，一种办法是根据用户工作的组织、他们被分配的岗位、他们的工作现场和他们必须完成的任务来划分章。对其他的软件而言，让第5章成为菜单的指南，让第6章成为使用的命令语言的指南，让第7章成为功能的指南更为合适。在5.3的子条中给出详细的过程。依赖于软件的设计，可能根据逐个功能，逐个菜单，逐个事务或其他的基础方式来组织条。在合适的地方应包含用“警告”或“注意”标记的安全提示。5.1能力为了提供软件的使用概况，本条应简述事务、菜单、功能或其他的处理相互之间的关系。5.2约定本条应描述软件使用的任何约定，例如使用的颜色、使用的警告铃声、使用的缩略词语表和使用的命名或编码规则。5.3处理过程本条应解释后续条(功能、菜单、屏幕)的组织，应描述完成过程必需的次序。5.3.x(软件使用的方面)本条的标题应标识被描述的功能、菜单、事务或其他过程。(若适用)本条应描述并给出以下各项的选择与实例，包括：菜单、图标、数据录人表、用户输入、可能影响软件与用户的接口的来自其他软硬件的输入、输出、诊断或错误消息、或报警和能提供联机描述或指导信息的帮助设施。给出的信息格式应适合于软件特定的特性.但应使用一种二致的描述风格，例如对菜单的描述应保持一致，对事务描述应保持一致。5.4相关处理本条应标识并描述任何关于不被用户直接调用，并且在5.3中也未描述的由软件所执行的批处理、脱机处理或后台处理。应说明支持这种处理的用户职责。5.5数据备份本条应描述创建和保留备份数据的过程，这些备份数据在发生错误、缺陷、故障或事故时可以用来代替主要的数据拷贝。5.6错误，故障和紧急情况时的恢复本条应给出从处理过程中发生的错误、故障中重启或恢复的详细步骤和保证紧急时刻运行的连续性的详细步骤。5.7消息本条应列出完成用户功能时可能发生的所有错误消息、诊断消息和通知性消息，或引用列出这些消息的附录。应标识和描述每一条消息的含义和消息出现后要采取的动作。5.8快速引用指南如果适用于该软件的话，本条应为使用该软件提供或引用快速引用卡或页。如果合适，快速引用指南应概述常用的功能键、控制序列、格式、命令或软件使用的其他方面。6注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。如果第5章扩展到了第6章至第N章，本章应编号为第N章之后的下一章。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。7.24计算机操作手册(COM)说明：1.《计算机操作手册}(COM)提供操作指定的计算机及其外部设备所需的信息。本手册侧重计算机自身，而不是运行在其上的特定的软件2.COM主要针对一些新开发的计算机、专用计算机、无现成的商用操作手册或其他操作手册可用的其他的计算机。 GB/T8567-2006《计算机软件文档编制规范》计算机操作手册的正文的格式如下：1引言本章应分为以下几条。1.1标识本条应包含本文档所适用的计算机系统的制造商名、型号和其他的标识信息。1.2计算机系统概述本条应简述本文档所适用的计算机系统的用途。1.3文档概述本条应概述本文档的用途和内容并描述与其使用有关的保密性或私密性要求。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。也应标识不能通过正常的供货渠道获得的所有文档的来源。3计算机系统操作本章应分为以下几条。在合适的地方应包含用“警告”或“注意”标记的安全防范提示。3.1计算机系统的准备和关机本条应分为以下几条。3.1.1加电和断电本条应包含计算机系统加电和断电的必要规程。3.1.2启动过程本条应包含启动计算机系统操作必需的步骤(若适用)，包括设备加电、操作前准备、自检和启动计算机系统的典型命令。3.1.3关机本条应包含终止计算机系统操作的必要规程。3.2操作过程本条应分为以下几条。如果有多种操作方式，应为每一种方式提供相应的说明。3.2.1输入和输出过程本条应描述与计算机系统有关的输入和输出媒体(例如磁盘、磁带)，描述在这些媒体上的读写过程，简述操作系统的控制语言，并列出交互消息和响应过程(例如使用的终端、口令、键)。3.2.2监视过程本条应包含监视计算机系统的操作所应遵循的过程。它应描述可用的指示器，对这些指示器的解释和必须遵循的规程及专用监视过程。3.2.3脱机过程本条应包含操作所有与计算机系统有关的脱机设备的必须的过程。3.2.4其他过程本条应包含操作员要遵循的任何附加的过程(例如计算机系统报警、计算机系统保密性或私密性要求、切换到冗余的计算机系统，或在紧急情况下保证操作连续性的其他措施。)3.3问题处理过程本条应标识在第3章前几条中所描述的操作步骤中可能发生的问题。它应陈述错误消息或与该问题相关的其他指示信息，并应描述针对每一发生的问题要遵循的自动和手工的过程(若适用)，包括评价技术、要求关闭计算机系统的条件、联机干预或非正常退出的过程、在操作中断或非正常退出后采取的重新启动计算机系统操作的步骤，以及记录有关故障的过程。4诊断功能本章应分为以下几条描述为标识和定位计算机系统内的故障而可能采取的诊断措施。4.1诊断功能综述本条应概述计算机系统的诊断功能。包括错误消息语法和故障隔离的层次结构。本条应描述每一个诊断功能的目的。 GB/T8567-2006《计算机软件文档编制规范》4.2诊断过程本条应分为以下几条描述计算机系统要遵循的诊断过程，包括：a.执行每一诊断过程需要的硬件、软件或固件的标识；b.执行每一诊断过程的分步指令；c.诊断消息和相应的要求动作。4.3诊断工具本条应分为以下几条描述计算机系统可用的诊断工具。这些工具可能是硬件、软件或固件。本条应用名字和编号来标识每一个工具，并描述这种工具和它的应用。5注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理说明)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A，B等)编排。7.25计算机编程手册(CPM)说明：1.《计算机编程手册》(CPM)提供了一个程序员理解如何在给定的计算机上编程所需的信息.本手册专注于计算机本身，而不是运行于计算机上的特定软件。2.CPM主要针对新开发的计算机、特定用途的计算机、其他不能利用商用的或其他编程手册的计算机。计算机编程手册的正文的格式如下，1引言本章应分为以下几条1.1标识本条应包含本文档适用的计算机系统的制造商名、型号和其他的标识信息。1.2计算机系统概述本条应简述本文档适用的计算机系统的用途。1.3文档概述本条应概括本文档的用途和内容，并描述与其使用有关的保密性或私密性要求。2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。也应标识不能通过正常的供货渠道获得的所有文档的来源。3编程环境适当的话，本章应分条提供以下信息：a.计算机系统的部件和配置；b.操作特性、能力和限制，(若适用)，包括：1)机器时钟周期；2)字长；3)内存容量和特性；4)指令集的特性；5)中断能力；6)操作方式(例如批处理、交互式、特权级、非特权级)；7)操作寄存器；8)错误指示器；9)输入/输出特性；10)特殊特性。 GB/T8567-2006《计算机软件文档编制规范》c.在计算机系统上执行编译与汇编所需的设备(例如磁带、磁盘、其他外围设备)描述。(若适用)按名字与版本号标识编辑程序、连接程序、连接编辑程序、编译程序、汇编程序、交叉编译程序、交叉汇编程序和使用的其他实用程序。并引用描述它们的用法的相应手册。要着重强调如何加载、执行、记录结果所必需的特殊的标志或指令。4编程信息适当的话，本章应分条提供以下信息：a.描述计算机指令集体系结构的编程特点。(若适用)包括：1)数据表示(例如字节、字、整数、浮点数、双精度)；2)指令格式和寻址方式；3)专用寄存器和字(例如堆栈指针、程序计数器)；4)控制指令(例如分支、跳转、子程序和过程调用指令、特权级指令和它们的操作方式)；5)子程序和过程(例如不可重人、可重人、宏代码例程、变元表、参数传递约定)；6)中断处理；7)计时器与时钟；8)内存保护特点(例如只读内存)；9)其他的特点，例如指令或数据的高速缓存的体系结构。b.每一条指令的描述，(若适用)，包括：1)用法；2)语法；3)条件码集合；4)执行时间；5)机器码格式；6)记忆码约定；7)其他的特性。c.输入/输出控制编程描述，(若适用)，包括：1)计算机内存的初始加载和校验；2)串行和并行数据通道；3)离散的输入、输出；4)接口部件；5)外围设备的设备号、操作码、内存单元。d.与计算机系统有关的其他的、受限的或专用的编程技术(例如微程序控制节的简述)；e.说明上述的编程特点的实例，包括计算机系统各类指令正确用法的实例；f.与计算机系统有关的错误检测与诊断功能，包括条件码、溢出和寻址异常中断、输入/输出错误状态指示器。5注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。------------------------------------------------------------------------------------附录A(规范性附录)面向对象软件的文档编制A.1综述 GB/T8567-2006《计算机软件文档编制规范》在一个面向对象的软件系统建模中，一般地说，应产生下列文档：总体说明文档；用况图文档；类图文档；顺序图文档，协作图文档；状态图文档；活动图文档；构件图文档；部署图文档；其中有的文档有时会引人包图来管理信息组织的复杂性。开发者也可根据所承担项目的实际情况，灵活取舍或增补。当开发者强调过程控制时，也可以形成需求定义文档、分析文档和设计文档等。其中每种文档的内容包含一个或多个上面提到的各种图文档。A.2总体说明文档以文本方式，对整个系统作一些必要的说明。内容包括系统的目标、意义、应用范围、项目背景和文档组成等。但不必对系统的总体进行详细地说明，只需作提纲掣领式的简单介绍。另外，还要说明系统的建模文档由哪几种具体的文档组成、每种文档的份数以及对各种文档的组织等。A.3用况图文档A.3.1图形文档即所绘制的用况图。A.3.2文字说明用况图文档由以下部分组成：用况图综述、参与者描述、用况描述、用况图中元素间的关系描述和其他与用况图有关的说明。A.3.2.1用况图综述从总体上阐述整个用况图的目的、结构、功能以及组织。以文字描述文档所包含的部分。A.3.2.2参与者描述列出一个用况图中的每个参与者的名称，可按字母顺序或其他某种有规律的次序排列。必要时要对参与者附有必要的文字说明，也可以说明它所涉及到的用况和交互图的名称。A.3.2.3用况描述对于一个用况图中的每个用况，记录如下的信息。要按某种顺序排列它们。a)名称每个用况有一个在图内唯一的名字，并且该名字要反映出它所描述的功能。书写位置是在用况描述的第一行。b)行为描述用自然语言分别描述参与者的行为和系统行为，建议把参与者的行为靠左对齐书写，把系统行为靠较右的位置对齐书写。在描述较复杂的含有循环或条件分支的行为时，可使用一些结构化编程语言的控制语句，如while,for，if-then-else等。当要表明控制语句的作用范围时，可使用括号，如｛、｝或begin,end等，也可以使用标号，以便更清楚地表示控制走向。如有必要，可使用顺序图、状态图或协作图描述参与者的行为和系统行为。c)用况图中元素间的关系描述产生一份描述用况图中的参与者与用况间、用况间以及参与者间关系的文字性描述文档。具体地由下面几部分构成：1)关系的名称；2)关系的类型：关联，泛化，包含，扩展； GB/T8567-2006《计算机软件文档编制规范》3)关系所涉及的类目：对关系所连接的类目应指明名称和类型(参与者或用况)。d)其他与用况图有关的说明与该用况图有关的但上面文档中没有涉及的其他信息的描述。A.4类图文档A.4.1图形文档即所绘制的类图。A.4.2文字说明文字描述由以下部分组成：类图综述、类描述、关联描述、泛化描述、依赖描述和其他与类图有关的说明。在实际使用时，这些部分是可选的。A.4.2.1类图综述从总体上阐述整个类图的目的、结构、功能及组织。以文字描述文档所包含的部分。A.4.2.2类描述类描述包括类整体说明、属性说明、服务说明、关联说明、泛化说明、依赖说明及其他说明。a)类的整体说明对整个类及其对象的情况加以说明，内容包括：1)类名：应是中文名或英文名；2)解释：对类的责任的文字描述；3)一般类：描述该类是从那些类泛化而来的；4)状态转换图：描述该类的实例的状态图的名称列表；5)主动性：有无主动性；6)永久性：有无永久性；7)引用情况：若此类为其他类图所定义，则要标明它所属于的类图；若此类被其他类图引用，则标明所引用的类图；8)多重性9)其他：是否有特别的数据完整性或安全性要求等。b)属性说明逐个地说明类的属性。每个属性的详细说明包括以下内容：1)属性名：中文属性名或英文属性名；2)多重性：该属性的多重性；3)解释：该属性的作用；4)数据类型；5)聚合关系：如果这个属性的作用是为了表明聚合关系，则在这里说明这种关系；6)组合关系：如果这个属性的作用是为了表明组合关系，则在这里说明这种关系；7)关联关系：如果这个属性是为了实现该类的对象和其他对象之间的链而设置的，则在这里明确地说明这一点；8)实现要求：该属性的取值范围、精度、初始值及其他描述。c)服务说明逐个地说明类中的每个服务。每个服务的详细说明包括以下内容：1)服务名：中文服务名或英文服务名；2)主动性：有无主动性；3)多态性：有无多态性；4)解释：该服务的作用；5)服务的活动图：详细描述活动具体细节的活动图的名称列表；6)约束条件及其他：若该服务的执行有前置条件、后置条件或执行时间的要求等其他需要说明的事项，则在此说明。d)关联描述该类所涉及的所有的关联。每个与该类相关的关联可有关联名。 GB/T8567-2006《计算机软件文档编制规范》e)泛化描述该类所涉及的所有的泛化。每个与该类相关的关联可有泛化名。f)依赖描述该类所涉及的所有依赖。每个与该类相关的依赖可有依赖名。A.4.2.3关联描述类图中的每一关联都应有如下的描述：a)关联名称：中文关联名或英文关联名；b)关联的类型：应是一般二元关联、聚合、组合、多元关联、自关联、限定关联、导出关联、其他关联；c)关联所连接的类：按照一定顺序列举出关联所连接的类；d)关联端点：对每一个关联端点描述如下：1)导航性：是否有导航性；2)排序：是否排序；3)聚合：是否有聚合，如果有，则要指明是聚合还是组合；4)多重性；5)可变性：应是无、只增加、冻结；6)角色：角色名用中文名和英文名表示均可；7)可见性：用＋、一、＃表示；8)接口说明符。A.4.2.4泛化描述类图中的每一个泛化都有如下的描述：a)泛化关系中的父类；b)泛化关系中的子类；c)泛化关系中的区分器；d)泛化关系中的限制符：应是完全、不完全、重叠和不相交。A.4.2.5依赖描述类图中的每一个依赖都有如下的描述：a)依赖名称，b)依赖所涉及的类的名称；c)依赖的类型；d)依赖的附加说明。A.4.2.6其他描述文档与该类图有关的但上面文档中没有涉及的其他信息的描述。A.5顺序图文档A.5.1图形文档即所绘制的顺序图。A.5.2文字说明顺序图的文字说明文档应包含：顺序图综述、顺序图中的对象与参与者描述、对象接收/发送信息的描述和其他与顺序图有关的说明。A.5.2.1顺序图综述从总体上描述该顺序图的目的，以及所涉及的对象和参与者。A.5.2.2顺序图中的对象与参与者描述对顺序图中的所有的对象和参与者，依次进行如下的描述：a)对象类型：是参与者还是类；b)对象名称；c)是否为主动对象：是或否，此描述针对对象而言，对于参与者不应有此描述；d)其他与对象或参与者有关的信息. GB/T8567-2006《计算机软件文档编制规范》A.5.2.3对象接收发送消息的描述对顺序图中的每一个对象或参与者，详细地描述其接收/发送消息的类型、时序及与其他消息之间的触发关系。对每一个对象和参与者应按照时间顺序分别列出该对象或参与者所接收/发送的全部消息。对每一条消息应包含下面的内容：a)消息名称；b)是发送消息还是接受消息；c)消息类型；d)若为接收消息，应列出该消息所直接触发的消息的名称列表；e)是否为自接收消息；f)消息的发送对象名称；g)消息的接收对象名称。A.5.2.4其他与顺序图有关的说明与顺序图有关的补充信息。A.6协作图文档A.6.1图形文档即所绘制的协作图。A.6.2文字说明协作图的文字说明应包含下列部分：协作图综述、协作图中的对象或角色描述、对象或角色接收/发送消息的描述、对象或角色间的链描述和其他与协作图有关的说明。A.6.2.1协作图综述从总体上描述该协作图的目的以及其所涉及的对象或类元角色。A.6.2.2协作图中的对象或角色描述对协作图中的所有类元角色或对象，依次列出下面的各项：a)名称；b)类型：类元角色或对象；c)是否为主动对象或角色：是或否；d)其他与类元对象有关的信息。A.6.2.3对象或角色接收/发送消息的描述对协作图中的每一个类目角色或实例，详细地描述其接收/发送消息的类型及时序，以及与其他消息的触发关系。每一类目角色或实例应有下列描述：a)对象或角色名称；b)列出该对象所接收/发送的全部消息流，对每一条消息应包含下面的信息：1)消息名称；2)消息的格式：参见概念和表示法部分；3)是发送消息还是接收消息；4)消息类型；5)若为接收消息应列出该消息所直接触发的消息序列；6)是否为自接收消息；7)消息的发送类目角色或实例；8)消息的接收类目角色或实例。A.6.2.4对象或角色间的链描述对象间或角色间的链应由下面的成分构成：a)链名称；b)链所连接的角色或对象的名称；c)链上的角色名，每个角色应包含下列信息：1)角色名：中文名或英文名； GB/T8567-2006《计算机软件文档编制规范》2)可见性：＋、一或＃；3)特殊的衍型Global,Local,Parameter,Self,Vote,Broadcast;d)其他与链有关的信息。A.6.2.5其他与协作图有关的说明与协作图有关的补充信息。A.7状态图文档A.7.1图形文档即所绘制的状态图。A.7.2文字说明状态图的文字说明应包含：状态图综述、状态图的状态描述、状态图的转换描述和其他与状态图有关的说明。A.7.2.1状态图综述从总体上，该状态图描述一个对象在外部激励的作用下进行的状态变迁、所涉及到的状态和转换以及设置该状态图的目的等。A.7.2.2状态图的状态描迷描述一个状态图的所有的状态，对每一个具体状态应包括以下各项：a)状态的名称：中文名或英文名；b)状态的类型：简单状态，并发组合状态，顺序组合状态，子状态，初始伪状态，终状态，结合状态，历史状态，引用状态，桩状态，同步状态；c)入口动作；d)出口动作；e)内部转换：由一系列的内部转换项组成。每个内部转换项有下列格式：动作标号/动作表达式；f)若为组合状态应列举出其所包含的子状态；g)其他与该状态有关的信息。A.7.2.3状态图的转换描述本文档用来描述一个状态图的所有的状态转换，每一个具体转换应包括以下各项：a)转换的源状态；b)转换的目标状态；c)转换串：事件特征标记‘["监护条件‘]’‘/’动作表达式；d)转换中的分支：同步条、结合点、动态选择点。A.7.2.4其他与状态图有关的说明与状态图有关的补充信息。A.8活动图文档A.8.1图形文档即所绘制的活动图。A.8.2文字说明活动图的文字说明包含：活动图综述、活动图中的动作状态描述、活动图中的转换描述和其他与活动图有关的说明。A.8.2.1活动图综述从总体上，活动图描述一个对象的一个操作的活动序列，或者是多个对象为完成某一目的而进行的协作所涉及的活动序列，以及设置该活动图的目的等。若活动图用于描述系统的其他目的，也按本格式描述。A.8.2.2活动图中的动作状态描述本文档用来描述一个活动图的所有的动作状态，每个具体动作状态包括以下内容：a)名称：中文名或英文名；b)类型：一般动作状态，子动作状态，信号发送，信号接收，初始伪动作状态，终动作状态，历史状态；c)入口转换； GB/T8567-2006《计算机软件文档编制规范》d)出口转换；e)活动伪码；f)其他与该状态有关的信息。A.8.2.3活动图中的转换描述本文档用来描述一个活动图的所有的转换，每一个具体转换包括以下内容：a)转换的名称；b)源动作状杰：c)终动作状态；d)转换中的分支：包括分叉、同步条、决策和合并；e)转换中的控制分叉：包括控制分叉的名称、与分叉相连的入口和出口元素的名称。A.8.2.4其他与状态图有关的说明与状态图有关的补充信息，如泳道的划分、对象流、信号发送和信号接收等信息。A.9构件图文档A.9.1图形文档即所绘制的构件图。A.9.2文字说明构件图的文字说明文档包含：构件图综述、构件巴中的构件描述、构件图中的关系描述和其他与构件图有关的说明。A.9.2.1构件图的综述从总体上，构件图描述构件间的依赖关系、设置该构件图的目的等.A.9.2.2构件图中的构件描述构件图中的每一个构件包含下列描述：a)构件名称；b)构件的接口；c)构件所涉及的关系；d)在逻辑上构件所实现的类；e)构件的类型。A.9.2.3构件图中的关系描述a)关系的名称；b)关系的起始构件的名称；c)关系的结束构件的名称；d)关系的类型：实现依赖、使用依赖或其他依赖。A.9.2.4其他与构件图有关的说明其他与构件图有关的信息。A.10部署图文档A.10.1图形文档即所绘制的部署图。A.10.2文字说明部署图的文字说明文档包含：部署图综述、部署图中的节点描述、部署图中的关系描述和其他与部署图有关的说明。A.10.2.1部署图综述从总体上描述部署图的目的以及节点之间的相互关系等。A.10.2.2部署图中的节点描述对部署图中的每一个节点包含下列描述：a)节点名称；b)节点中的构件实例； GB/T8567-2006《计算机软件文档编制规范》c)节点所涉及的链的名称；d)节点的类型。A.10.2.3部署图中的关系描述a)关系的名称；b)关系的起始节点(或构件)的名称；c)关系的结束节点(或构件)的名称；d)关系的类型：实现依赖、使用依赖、其他依赖或通讯链。A.10.2.4其他与部署图有关的说明其他与部署图有关的信息。A.11包图文档为了管理模型的信息组织的复杂性，在比较复杂的模型中，通常将关系联系比较密切的图形元素划分到一个包里面。A.11.1图形文档即所绘制的包图。A.11.2文字说明包图的文字说明文档包含：包图的综述、包图中的包描述和其他与包图有关的说明。A.11.2.1包图的综述从总体上描述包图的名称、目的以及与其他包的相互关系等。A.11.2.2包图中的包描述包图中的每一个包包含下列描述：a)包的名称；b)包的种类：类包、用况包或其他；c)详细描述该包所包含的建模元素所在的文档；d)与该包有关系的其他包，应包括如下信息：l)包的名称；2)与该包的关系：依赖(访问和移人)、泛化，要注明方向性。A.11.2.3其他与包图有关的说明其他与包图有关的信息。------------------------------------------------------------------------------------参考文献GB9385-1988《计算机软件需求规格说明编制指南》。GB9386-1988《计算机软件测试文件编制规范》。GB/T12504-1990《计算机软件质量保证计划规范》。GB/T12505-1990《计算机软件配置管理计划规范》。SJ/T11291-2003《面向对象的软件系统建模规范第3部分：文档编制》。SJ20778-2000《软件开发与文档编制》。ISO/IECJTCI/SC7N21061999/04/15《软件工程—用户文档过程》'