1、ICS 45.060 S 04 中华人民11: _，、GB 春日国国家标准GB/T 28808-20 12/IEC 62279: 2002 轨道交通通信、信号和处理系统控制和防护系统软件Railway applications-Communication, signaling and processing systems Software for railway control and protection systems (lEC 62279: 2002 , IDT) 2012-11-05发布fki 一主唁m 中华人民共和国国家质量监督检验检度总局中国国家标准化管理委员会2013-02-01
2、实施发布GB/T 28808一2012/IEC62279: 2002 目次前言.皿引言.凹l 范围-2 规范性引用文件3 术语和定义24 目标和一致性-5 软件安全完整性等级.5.1 目标-5.2 要求6 人员和职责6. 1 目标-6.2 要求7 生命周期和文档-7.1 目标77.2 要求8 软件需求规范. 8.1 目标98.2 输入文档8. 3 输出文档98. 4 要求.9 软件结构119.1 目标119.2 输入文档119. 3 输出文档. 9.4 要求1110 软件设计和实现四10.1 目标四川.2输入文档1210. 3 输出文档1210.4 要求1211 软件验证和测试1411. 1
3、目标1411. 2 输入文档1411. 3 输出文档M11. 4 要求GB/T 28808-20 12/IEC 62279: 2002 12 软件/硬件集成12.1 目标1612. 2 输入文档-12. 3 输出文档1712.4 要求1713 软件确认1713. 1 目标1713.2 输入文档1813.3 输出文档.13.4 要求14 软件评估四14. 1 目标1914. 2 输入文档14. 3 输出文档1914.4 要求1915 软件质量保证. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 15.1 目标
4、m15.2 输入文档2015.3 输出文档2015.4 要求mm 软件维护. . .,. 21 16. 1 目标n16.2 输入文档.2116.3 输出文档2116.4 要求2217 基于应用数据配置的系统. . . . . . . . . . . . . . . . . . . . . . . . 22 17.1 目标2217.2 输入文档17.3 输出文档2317.4 要求n附录A(规范性附录)技术和措施的选择准则31附录B(资料性附录)技术参考资料c附录NA(资料性附录)与规范性引用国际文件有关的我国文件81H GB/T 28808一2012/IEC62279: 2002 目。吕本标准按
5、照GB/T1. 1一2009给出的规则起草。本标准采用翻译法等同采用IEC62279: 2002(轨道交通通信、信号和处理系统控制和防护系统软件。与本标准中规范性引用文件有一致性对应关系的我国文件见附录NA。本标准做了下列编辑性修改:一一一将第3章中引用的IEC60050-191、ISO/IEC2382、ISO/IEC9126、IEEE610. 12文件补充到第2章规范性引用文件中;一一修改了IEC62279: 2002中第2章的脚注1，因为IEC62278已发布;脚注1改为对ISO9000、ISO 9000-3、ISO9001提醒存在新版文件;一一采用等同采用IEC62425: 2007的G
6、B/T28809-2012代替ENV50129; 一一修订正文中引用的ISO9000、ISO9000-3、ISO9001的版本号，与第2章声明的版本号一致;一一IEC62279: 2002的一级子列项编号采用的是i)、ii)、或1)、2)、，本标准中统一修改为字母编号形式:a)、b)、;一一附录B中，对每章内的单列一行的黑体字符目标、描述和参考文献进行编号，以符合中文习惯。本标准由中华人民共和国铁道部提出。本标准由全国牵引电气设备与系统标准化技术委员会CSAC/TC278)归口。本标准主要起草单位:同济大学、铁道部标准计量研究所。本标准参加起草单位:株洲|南车时代电气股份有限公司、北京全路通信
7、信号研究设计院。本标准主要起草人:徐中伟、赵天时、王奇。本标准参加起草人:范样成、孙超、严云升、陈邦兴、黄银霞、呼爱蝉、牛道恒。阳山GB/T 28808-20 12/IEC 62279 : 2002 引本标准与GB/T21562 (IEC 62278)和GB/T28809-2012 (IEC 62425: 2007 , IDT)配套使用。GB/T 21562 (lEC 62278)适用于大范围的系统问题，而GB/T28809-2012 (1EC 62425: 2007 ，IDT)适用于整个轨道交通控制和防护系统中某单个系统的批准过程。为提供满足安全完整性要求的软件，本标准关注于通过更全面考虑后
8、提出软件安全完整性要求所要采用的方法。本标准从IEC/TC65第九工作组(WG9)早期工作中得到很多指导。同时.对铁路信号工程师协会(lRSE)的工作也加以了考虑，特别是关注相同主题的1号技术报告。本标准的关键思想是其对软件安全完整性等级的考虑。软件失效的后果越严重，软件安全完整性等级也就越高。本标准确定了从最低0级到最高4级的5个软件安全完整性等级的技术和措施。其中1级4级指的是安全相关软件，0级指的是非安全相关软件。将0级包括进本标准是为了让非安全相关系统软件开发向安全相关系统软件开发实现顺利过渡。附表给出了各个软件安全完整性等级和非安全相关等级要求的技术和措施。在本版本中，1级和2级的技
9、术要求相间，3级和4级的要求相同。本标准没有给出某一风险应适用于哪个软件安全完整性等级的具体指导意见。这一结论需要考虑诸多因素，包括应用的特性、其他系统承担的安全功能范围以及社会和经济因素。软件安全功能的分配由GB/T21562 (IEC 62278)和GB/T28809-2012 (IEC 62425: 2007 , IDT)规定。本标准规定了满足这些需求的必要措施。该过程见图1。GB/T 21562 (lEC 62278)和GB/T28809-2012 (lEC 62425: 2007 ，IDT)需采用系统性的方法，以ta) 确定危害、风险和风险准则;b) 为满足风险准则，确定必要的风险降
10、低(措施); c) 为实现所需的风险降低，为必要的安全防护措施定义一个全面的系统安全需求规范;d) 选择一个合适的系统结构;e) 规划、监督和控制那些把系统安全需求规范变成安全性能(或安全完整性)己确认的安全相关系统。在将该规范分解到由安全相关系统和组件组成的设计当中时，对安全完整性等级的进一步分配就完成了，并最终形成所需的软件安全完整性等级。目前，无论是质量保证法(即避错措施)还是软件容错法的应用，都无法保证系统的绝对安全。尚未发现可证明一个较复杂的安全相关软件中不存在错误的方法，特别是规范和设计的错误。在开发高度完整性软件时采取但不仅限于以下原则:a) 自顶向下的设计方法;b) 模块化;c
11、) 开发生命周期每个阶段的验证;d) 经验证的模块和模块库;e) 清晰的文档;f) 可审核的文档;g) 确认测试。这些原则以及相关的其他原则应正确应用。本标准规定了在每个软件安全完整性等级下证明其(保证能处于该安全完整性等级)所需的保证等级。N GB/T 28808一2012/IEC 62279: 2002 在得到或形成了系统安全需求规范后，分配给软件的安全功能和系统安全完整性等级就确定了，图2给出了应用本标准的功能步骤，并如下所示:a) 定义软件需求规范，同时考虑软件结构。软件结构是为软件和软件安全完整性等级开发基本安全策略的架构(第5章、第8章和第9章)。b) 根据软件质量保证计划、软件安
12、全完整性等级和软件生命周期来设计、开发和测试软件(第10章)。c) 在目标硬件上集成软件(第12章)。d) 确认软件(第13章)。e) 如果在运行过程中需要软件维护，那么可再适当运用本标准进行处理(第16章)。许多活动都是在软件开发过程中交叉进行的，这其中包括验证(第11章)、评估(第14章)和质量保证(第15章)。给出了由应用数据所配置的系统的需求(第17章)。给出了从事软件开发人员能力的需求(第6章)。本标准没有强制要求使用特定的软件开发生命周期，但是给出了推荐的生命周期和文档集(第7章，图3和图的。针对5个软件安全完整性等级明确制定了各种技术和措施表格。表格见附录A。对表格交叉引用的是对
13、每个技术或措施做了简要描述的、同时附带更多信息源做参考的文献目录。附录B列出了文献目录。V GB/T 28808-20 12/IEC 62279: 2002 轨道交通通信、信号和处理系统控制和防护系统软件1 范围1. 1 本标准规定了轨道交通控制和防护设备应用中可编程电子系统开发所需的规程和技术要求，适用于任何有隐含安全性的领域。这些应用系统的范围涵盖了从安全苛求系统(如安全信号系统)到非安全苛求系统(如管理信息系统)。这些系统可能通过采用专用微处理器，可编程逻辑控制器，分布式多处理器系统，大规模集中处理器系统或者其他结构来实现。1. 2 本标准只适用于软制if，及软件和系统之间的交互作用。二
14、1. 3 0级以上的软件安圣完整J等级用于失效可导致人员死亡后果的系统主然而，从经济或环境因素;r一方面考虑也能采用高级另l卜全完整性等级。二1. 4 本标准适用于凯道给亘控制和防护系统开发和实现中的所有软件，刨卧一应用程序设立0/;一一操作系统:一一支持工具F一一固件。应用程序设计包括高级程序设计，低级程序设计和专用程序设计(如可编程逻辑控制器梯形逻辑)。1. 5 本标准还涉及了标准、商用软件和工具的使用。1. 6 本标准还对由应用数据配置的系统提出了要求。1. 7 本标准并不涉及商务问题，这些问题宜作为合同的基本部分提出。但本标准中的所有条款在任何商务活动中都需被仔细考虑。1. 8 本标准
15、不是追溯性的，主要应用于新的开发;对于既有系统，仅当进行大的修改时才进行全面应用，对于小的修改，仅氧16章适用。、2 规范性引用文件亏、卢/下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件寸文注日期的版本适用于本文件。凡是不注日期的引用文件￥其最新版本(包括所有的修改单)适用于本文件。GB/T 28809-2012 轨道交通通信J言号和处理系统信号用安全相关电子系统(lEC62425: 2007 ,IDT) IEC 60050-191 国际电工词汇第191章:可靠性和服务质量口nternationalelectrotechnical vo cabulary (lEV)-Chapter
16、 191: Dependability and quality of serviceJ IEC 62278 轨道交通可靠性、可用性、可维修性和安全性(RAMS)规范及示例Railwayapplica tions-Specification and demonstration of reliability , availability , maintainability and safety (RAMS) IEC 62280-1 铁路设施通信、信号和处理系统第1部分:在封闭的传输系统中有关通信安全(Railway applications-Communication, signalling an
17、d processing systems-Part 1: Safety-related communication in closed transmission systems) IEC 62280-2 铁路设施通信、信号和处理系统第2部分:在开放的传输系统中有关通信安全(Railway applications-Communication, signalling and processing systems-Part 2: Safety-related GB/T 28808一2012/IEC62279:2002 communication in open transmission syste
18、ms) ISO/IEC 2382(所有部分)信息技术词汇(Informationtechnology-Vocabulary) ISO/IEC 9126(所有部分)软件工程产品质量(Softwareengineering-Product quality) ISO 9000: 2000) 质量管理体系基础和术语(Qualitymanagement systems-Fundamentals and vocabulary) ISO 9000 3: 19971) 质量管理和质量保证标准第3部分:ISO9001:1994应用于计算机软件开发、供应、安装和维护的指南(Qualitymanagement an
19、d quality assurance standards-Part 3: Guidelines for the application of ISO 9001: 1994 to the development, supply, installation and maintenance of computer software) ISO 9001: 19941) 质量系统设计、开发、生产、安装和维修中的质量保证模型(Quality systems-Model for quality assurance in design , development , production, installa
20、tion and servicing) IEEE 610. 12 软件工程术语集CIEEEstandard glossary of software engineering terminology) 3 术语和定义ISO 9000: 2000、IEC60050-191、ISO/IEC2382、ISO/IEC9126、IEEE610. 12界定的以及下列术语和定义适用于本文件。3.1 评估assessment 用于确定设计机构和确认员所完成的产品是否符合规定的要求和判定产品是否达到预期目的的分析过程。3.2 评估员assessor 受委托执行评估的人员或者机构。3. 3 可用性availabil
21、ity 在要求的外部资源得到保证的前提下，产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。3.4 商业通用软件commercial off-the-shelf (COTS) software 市场需求所定义、市场已存在且其目标满足性已得到广大商业用户证实的软件。3.5 设计机构design authority 负责提出实现特定需求的设计方案，并监控后期的开发和系统在特定环境下工作的实体。3.6 设计者designer 一个或多个由设计机构指派的人员，他们承担需求分析并将特定需求转化成可接受且有相应安全完整性的设计方案。3. 7 2 元素element 被确认为基本单元或
22、基本组件的某产品的一部分。一个元素可是简单的，也可是复杂的。1) ISO 9000、ISO9000-3、ISO9001已有新版文件，其中ISO9000-3文件由ISO/IEC90003代替，相关文件对应的国家标准信息见参考文献。GB/T 28808一2012/IEC62279: 2002 3.8 错误error 可能导致非预期的系统行为或失效的与期望设计之间的偏差。3.9 失效failure 与规定的系统行为产生偏差。失效是系统错误或故障的结果。3. 10 故障fault 一种能导致系统错误或失效的不正常状态，故障可是系统性的或随机性的。3. 11 避错fault avoidance 在系统设
23、计和构造的过程中为避免引人故障而采用的设计技术。3. 12 窑错fault tolerance 在出现有限数量的软硬件故障的情况下，系统能继续提供正确的规定服务的内嵌能力。3. 13 固件firmware 以功能独立于主存储器方式存储的指令和相关数据的有序集合(通常在ROM中)。3.14 通用软件generic software 只要提供应用相关的数据就可应用于多种系统装置的软件。3. 15 实现者implementer 由设计机构委派、具体实现特定设计的一个或多个人员。3. 16 产品product 为满足特定需求，收集元素并进行互连以形成一个系统，子系统或者设备。产品可被视为完全由软件或者
24、文档元素构成。3. 17 3. 18 3. 19 3.20 3.21 可编程逻辑控制器programmable logic controller; PLC 具备用户可编程存储器、能实现规定功能的固态控制系统。可靠性reliability 产品在规定的条件下和规定的时间区间仙，马)内完成规定功能的能力。需求可追溯性目标requirement traceability 确保所有的需求能被证明己得到满足。风险risk 某特定危害事件的频度或概率和后果的组合。安全性safety 免除不可接受等级的风险。3 GB/T 28808一2012/IEC 62279 : 2002 3.22 3.23 3.24
25、安全主管部门safety authority 负责证实安全相关系统适于工作井符合法令、规章规定的安全需求的实体。安全相关软件safety-related software 负有安全责任的软件。软件software 由程序、流程、规则和系统运行相关的文档组成的智力产物。注:软件独立于传输介质。3.25 软件生命周期software life cycle 从软件构思开始到软件停用为止的时期内发生的活动。典型的软件生命周期包括需求阶段、开发阶段、测试阶段、集成阶箴、安装阶段和维护阶段。3.26 3.27 3.28 3.29 3. 30 软件可维护性software maintainability 系
26、统能被修改以纠正故障、改进性能或其他特性，或适应不同环境的能力。软件维护software maintenance 在软件被最终用户接收后所进行的活动或活动集合，它的目的在于改善，增加或纠正软件的功能。软件安全完整性等级software safety integrity level 一组分级数字，它确定了为将残余软件故障降低到一个适当水平所应采用的技术和措施。系统安全窍整性等级system safety integrity level 表示系统能满足规定安全特性的置信度的数字。可追溯性traCfabilifY:, 能在开发过程中说军两个或者多个产品之间关系的程度，尤其是那些与其他产品构成前/后代
27、或主/ 次隶属关系的。/3.31 确认validation 通过测试和分析，表明产品在各个方面符合规定需求的证明行为。3.32 确认员validator 被委派来做确认工作的人或者代理。3.33 验证verification 通过测试和分析，表明系统生命周期各阶段的输出符合前一阶段需求的一种判定行为。3.34 验证员verifier 被委派来做验证工作的人或代理。4 GB/T 28808一2012/IEC 62279: 2002 4 目标和一致性4.1 在以下每项条款中，将详细地描述其目标和要求。4.2 为与本标准一致，应证明软件满足安全完整性等级规定的每项要求，从而表明实现了条款目标。4.3
28、 如果一个需求含有达到软件安全完整性等级的要求的语句，则表示可用一系列的技术和措施来满足该需求。4.4 在4.3的前提下，宜使用本标准给出的详细表格来帮助选择合适的技术和措施，达到软件安全完整性等级要求。4.5 如果在表格中列为极力推荐(HR)的某一技术或措施不被采用，那么软件质量保证计划或软件质量保证计划参考的其他文件宜详细说明不使用该技术的理由井有相应记录。如果使用了表格认可的技术组合，可不说明或记录理由。J4.6 如果一项表格未提及的技术或措施被建议使用，那么应论证相应技术或措施是否能有效地实现特定要求和整体目标，并在软件质量保证计划中或其引用的其他文件中作相应的记录。4. 7 应通过检
29、查本东准所要求的文档、其他客观证据、审核和见证测试来评估是否符合特殊条款的要!, ,/. /，、， 求和表格中详细列出的技术和措施要求。， 4.8 本标准需要使府一组技术并正确应用它们。这些技术是表格中所要求的，并在参考材料中详细列出。5 软件安盒完整性等级5.1 目标定义软件的安全完整性等级的设置。5.2 要求其中包括:、三、安全功能;一一系统配置或体系结构;一一硬件可靠性需求;一一安全完整性需求。软件安全完整性等级应达到IEC62278规定的安全完整性等级的一般流程确定。5.2.2 应在系统中软件应用的风险等级和系统安全完整性等级的基础上，决定需要的软件安全完整性等级。5.2.3 如没有进
30、一步防范措施，软件安全完整性等级不应低于系统安全完整性等级。然而，如果有在软件模块失效时能避免系统进入不安全状态的防护机制，则可降低模块的软件安全完整性等级。5.2.4 应考虑可能导致以下危害后果的风险:一一人员死亡;一一-人员的受伤或致病;5 GB/T 28808-20 12/IEC 62279: 2002 一一环境的污染;一一财产损失或损坏。5.2.5 风险可被定量化，但元法以同样方式规定软件安全完整性。因此，软件安全完整性等级应选用以下五个等级之一:软件安全完整性等级4.对应等级描述为非常高;一一软件安全完整性等级3.对应等级描述为高;一一软件安全完整性等级2.对应等级描述为中等;一一软
31、件安全完整性等级1，对应等级描述为低气软件安全完整性等级O.对应等级描述为非安全相关。5.2.6 在软件需求规范中应规定软件安全完整性等级(见第8章)。如果不同的软件组件有不同的软件安全完整性等级，应在软件结构规范中加以规定(见第9章)。6 人员和职责6. 1 目标确保所有对软件负有责任的人员都有能力履行其职责。6.2 要求6.2.1 作为最低要求，供应商和/或开发商以及客户执行ISO9000-3: 1997中有关ISO9001:1994实施的指南要求。6.2.2 除软件安全完整性等级0以外，安全过程应在一个适当的安全组织的控制下完成。该组织遵从GB/T 28809-2012安全管理证据条款中
32、安全组织子条款要求。6.2.3 软件生命周期各阶段(包括管理活动)涉及的所有人员应经过适当的培训，具有适当的经验和资质。6.2.4 除软件安全完整性等级0以外，对于特定的应用，极力推荐对软件生命周期各阶段(包括管理活动)涉及的所有人员的培训11、经验和资质进行证实。6.2.5 应在软件质量保证计划中记录上述子条款(6.2.4)所指的证实，适当包括能胜任以下领域能力的证据:a) 适合应用领域的工程;b) 软件工程;c) 计算机系统工程;d) 安全工程;e) 法规框架。6.2.6 应为软件指定独立评估员。同时执行6.2.10和14.4.1。6.2.7 应赋予评估人员足够的权威来实现对软件的评估。6
33、.2.8 贯穿整个软件生命周期，根据软件安全完整性等级所要求的程度，所涉及的各方应是独立的，与图5所示一致，解释如下:6 一一在各个软件安全完整性等级，评估员应由安全主管部门认可，除6.2.10规定的情况外，都应独立于供应商。一设计人员/实现者、验证员和确认员可同属一个公司，但至少要满足以下独立性规定: 软件安全完整性等级0:没有限制，设计人员/实现者、验证员和确认员可是同一人。 软件安全完整性等级1和2:验证员和确认员可是同一人，但他们不应又是设计者/实现者。设计人员/实现者、验证员和确认员都能向项目经理报告。GB/T 28808-2012/IEC 62279: 2002 软件安全完整性等级
34、3和4:有两种允许的安排。 验证员和确认员是同一人，但他们不应又是设计人员/实现者。而且他们不应像设计者/实现者一样向项目经理报告，他们有权力阻止产品的发布。 设计者/实现者、验证员和确认员是各不相同的人。设计者/实现者和验证员可向项目经理报告，而确认员则不向项目经理报告。确认员有权力阻止产品的发布。6.2.9 各类工作的负责人员如下:软件需求规范(见第8章)负责者应为设计者;一一一软件需求测试规范(见第8章)负责者应为确认员;一一软件结构(见第9章)负责者应为设计者;一一软件设计和开发(见第10章)负责者应为设计者;软件验证和测试(见第11章)负责者应为验证员;软件/硬件集成(见第12章)负
35、责者应为设计者;一一软件确认(见第13章)负责者应为确认员;一一软件评估(见第14章)负责者应为评估员。6.2.10 根据安全主管部门的意见，评估员可是供应商组织或客户组织的一员，在这种情况下，评估员应:由安全主管部门授权;一一完全独立于项目团队;一一直接向安全主管部门报告。7 生命周期和文档7. 1 目标7. 1. 1 规划软件开发的阶段和活动。7. 1. 2 记录贯穿整个软件生命周期的所有与软件相关的信息。7.2 要求7.2. 1 应为软件开发选择生命周期模型，根据第15章，将在软件质量保证计划中对该模型加以详细说明。图3和图4给出了两种生命周期模型的例子。7.2.2 质量保证规程应与生命
36、周期活动一起运行，并且使用相同的术语。7.2.3 各阶段所有要进行的活动应在该阶段开始之前先行定义。软件生命周期的每阶段都应划分成良好定义的有输入、输出及其活动的基本任务。7.2.4 软件质量保证计划应当描述需要哪些验证步骤和报告。7.2.5 所有文档应结构化，以便能随着设计过程不断扩展。7.2.6 各个文档应有唯一的索引编号，与其他文档应有确定的、记录在案的文档关系，以便进行文档追溯。每个文档对术语、缩略语和简写词应有相同的解释。如果由于历史的原因，做不到这一点，就应给出不同的释义和参考资料。此外，除商业通用软件或早期开发的软件的文档外，各文档应按以下规则书写:a) 应包括或执行所有与之具有
37、层次关系的之前的文挡的适用条件和要求;b) 不应与前期文档有抵触;c) 在各个文档中，每个术语、首字母缩略词或缩写应具有相同的意义;d) 在各个文档中，每个条目或概念应用相同的名称或描述来指称。追溯流程的输出应成为正式的配置管理的一个科目。7 GB/T 28808-20 12/IEC 62279: 2002 7.2.7 所有文档内容应以适合于操作、处理和存储的形式来记录。7.2.8 根据软件安全完整性等级的要求，应完成文档交叉索引表(见表1)中所列文档。7.2.9 根据开发软件的规模、复杂性和生命周期，需要完成的各类文件数目有所不同。对于规模较小的项目，一些文件可合并在一起(在这过程中不应丢失
38、需要的细节)，而对于大规模项目，必要时宜将所列文档(以层次方式)再分成一些更便于管理的子文档。由独立团队或实体完成的文挡不应合并成单一文档。7.2.10 第7章确定的各种参考文档之间的关系可用文档交叉索引表来定义。对于表1中文挡栏所列的每个文档，从标有符号旷的单元格对应的行和列中可找到与创建文档有关的阶段和条款。从标有符号、的单元格对应的列中可找到应用文档的阶段。文挡的条款或对其定义的其他引用可在定义出处栏中找到。在给出条款的地方，宜核对后续条款，因为后续条款可能包含进一步信息。值得注意脯，软件配置管理计划需要的参考文献列在括号内，这是因为该条款仅纣Tm9000:2000 章条编号8 系统输入
39、 软件计划a 软件需求E 8 / / 9 、 10 11 12 阶段 、, 、表1文档交叉索引表13 14 15 16 档飞 文对应要求 系统需求规范GB/T 28809-2012 中B.2. 3 系统安全需求规范GB/T 28809-2012 中B.2.4系统结构描述GB!T 28809一2012中B.2. 1 系统安全计划/G/ H/T288092012、IEC 62278 / / + 软件质量最幸在计划吧与交15.4.3 软件配置管理作/划/ (15.4.2) 软件验证计划11. 4. 1 - 软件集成测试计划11. 4. 5 软件/硬件集成测试计划12.4.1 软件确认计划13.4.3
40、 软件维护计划16.4.3 数据准备计划17. 4. 2. 1 数据测试计划17.4.2.4 软件需求规m:8.4.1 应用需求规范17. 4. 1. 1 软件需求测试规范8.4.13 软件需求验证报告11. 4.11 章条编号8 9 10 11 阶段a 软件设计 E 软件模块设计 /少/ 编码 模块测试 软件集成衍1 软件/硬件集成确认(养)评估仆)叭I巧岱飞忑维护J.协句E叫字纣a和其他阶段平行。8 软件需求规范、丁、子.8. 1 目标 12 13 (侬户泪、.11昆院的户旧如二GB/T 28808-20 12/IEC 62279: 2002 表1(续)14 15 16 文档对应要求 软件
41、结构规范9.4. 1 软件设计规范10.4.3 散件结构和设计验证报告11. 4.12 二. 软件模块设计规范10.4.3 软件模块测试规植10.4. 14 软件模块验证报告11. 4.13 + 软件源ft码 软件源代码验证报告11. 4. 14 软件模块测试报告10.4. 14 事坠软件集成测试报告11. 4.15 ?比撤辑糖葫报告 7.4.2.4 飞气软件伊藤持集成道路试报告予: 12.4.8 带一禁软苦仲毒挣势确伊t拮k?截报一告声3如p.4.1。矗满4.9 p飞、点主辑赞棒球记录罚欲运、二囊法卡?二:教件维护记录16.4.8 A 俯 4 8. 1. 1 描述-个文档。为满足所有系统需求
42、，该文档根据软件安全完整性等级规定了一整套的软件需求。它是对每个软件工程师均适用的综合性文档，因此软件工程师不必再从其他文档中了解需求。8.1.2 用于描述软件需求测试规范。8.2 输入文档输入文档有:a) 系统需求规范;b) 系统安全需求规范;c) 系统结构描述;d) 软件质量保证计划。8.3 输出文档输出文档有:9 G/T 28808一2012/IEC 62279: 2002 a) 软件需求规范;b) 软件需求测试规范。8.4 要求8.4. 1 软件需求规范应描述待开发软件的需求特性，而不是开发软件的规程。这些特性(除安全性外均在ISO/IEC9126中定义)应包括:一一功能(包括能力和响应时间性能); 一一-可靠性和可维护性;一一-安全性(包括安全功能及其相关的软件安全完整性等级); 一一效率;一一一易用性;一一可移植性。软件安全完整性等级源自于第5章，并记录在软件需求规范中。8.4.2 根据软件安全完整性等级的要求，软件需求规范应按以下原则来描述和构造:a) 完整、清楚准确、元歧义性、可验证、可测试、可维护和可实现;b) 可追溯到8.2涉及的所有文档。8.4.3 软件需求规范应使用让系统整个生命周期所涉及、负有责任的人员都能理解的表达形式和描述方法。8
