GJB 系统规格说明文档模板及详解
1 范围
1.1 标识
1.2 系统概述
1.3 文档概述
2 引用文档
GJB XXX
XXX XXX；
XXX XXX。
前2章通用不再赘述
3 需求
需求是系统规格说明文档的主要内容。需求包括三类:功能需求、质量因素、设计约束。
在GJB438模板中的对应关系如下。
(1)模板的3.2系统能力需求是指功能需求。
(2)模板的3.6适应性需求、3.7安全性需求、3.8保密性需求和3.11系统质量因素3.13人员需求是质量因素。
(3)模板的3.12设计和构造的约束是指设计约束。
(4)模板的3.1要求的状态和方式是与系统使用要求(用途)密切相关的要求。
(5)模板的3.3系统外部接口需求、3.4系统内部接口需求和3.5系统内部数据需求是支撑功能需求的接口需求和数据需求。
(6)模板的3.9系统环境需求和3.10计算机资源需求是指系统运行所依赖的计算机软件和硬件资源需求。
(7)模板的3.14培训需求、3.15保障需求、3.16其他需求、3.17包装需求等主要是指支持系统交付的需求。
3.1 要求的状态和方式
GJB438要求“如果要求系统在多种状态或方式下运行,并且不同的状态或方式具有不同的需求,则应标识和定义每一种状态和方式”。注意,此要求的重点是两个条件同时成立,即不仅有多种运行状态,而且每种状态下的系统需求不同,此时,这条必须说明以下内容。
(1)系统有多种运行方式和状态时,可先用表3-11说明方式和状态的关系
(2)用状态图或文字说明这些状态/方式之间如何转换。
(3)系统有多种运行方式或状态时,需按表3-12说明系统的能力需求在哪个状态/方式下有效。
3.2 系统能力需求
系统能力需求的主要表述内容包括:一个系统用例图,以及每个系统用例的规约表。
(1) 如果本系统规模较大,且各部分之间有明确的职责区域,则这些部分可以直接划分为子系统,在此处用UML构件图说明这些子系统之间的关系,如图3-16所示。切记,此处不能够直接给出系统内部的详细部件组成,部件及其组成关系是系统设计范畴内的内容。
(2) 用如表3-13所示的表格说明子系统用途(职责)。之后,后续章节按照子系统组织,也可以对各个子系统出具单独的子系统规格说明文档。
(3) 如果本系统无须划分为多个子系统,或暂时无法明确子系统边界,需要在系统设计阶段确定的,直接画出系统的UML用例图,并用列表概述系统用例,如图3-17和表3-14所示
(4) 按照模板要求,以每个系统用例为小章节分条说明系统能力需求。每个系统用例使用如表 3-15 所示进行描述。
3.3 系统外部接口需求
(1) 画出系统或子系统与系统外部的其他硬件和软件之间的接口,如图3-18所示。
(2) 用表格说明每个接口的标识、类型、用途等,如表3-16所示。注意:如果与外部系统存在多个物理接口,如网络、CAN接口,需要在图和表中按不同接口分别说明。
(3) 对识别出来的每个接口分别按条描述,如表3-17所示。
注意:此时尚处于系统需求分析阶段，接口重点关注数据内容、数据取值的物理意义范围,不关心在计算机编程层面定义的数据格式,如数据类型(浮点、整型、字符串等)、字节组织形式等;这些内容属于对接口需求的具体解决方案,留待系统设计时确定。
3.4 系统内部接口需求
系统内部接口需求,主要是指已经明确的子系统之间的接口。注意,不应该识别出系统的部件(软件和硬件)之间的接口,因为在系统需求分析阶段,系统设计还未出结果,系统的部件还不明确。
如果本系统无多个子系统,或暂时无法明确子系统边界,需要在系统设计阶段确定的此处可留待设计时描述。
如果本系统已经明确划分为多个子系统,则参照系统外部接口的分析方法,标识子系统之间的接口。
（1）画出子系统之间的接口,如图3-19 所示。
(2)用表格说明每个接口的标识、类型、用途等。注意:如果两个子系统之间存在多个物理接口,如网络、CAN口,需要在图和表中按不同接口分别说明。
(3)分条目分别使用表3-18描述每个内部接口的需求。注意,内部接口的接口实体应该是子系统。
3.5 系统内部数据需求
识别系统内部需求的目的为数据库表/文件的设计提供需求来源。识别方法是从各个系统用例中找出系统需要处理的业务实体。建模方法是使用UML类图对实体类建模。注意,内部数据需求不是输入、输出数据。
(1)建立系统的实体类图。
(2)使用表3-19说明识别出的所有实体类
(3)对每个实体类分条使用表3-20进行说明。注意:此处关注类的属性,不关注类的操作,类的操作是系统设计阶段的内容。
3.6 适应性需求
适应性需求是指系统在不同用户现场安装时需要修改的安装数据,如地理数据配置文件、菜单配置文件、通信端口参数等。可以用表3-21 表示。
3.7 安全性需求
安全性需求是指系统可能涉及的两类安全风险:一类是可能导致系统毁坏或人员伤亡的安全风险;另一类是指可能被恶意入侵的风险。
注意以下三点常犯错误:一是不要抛开安全性需求的基本原则,为了写安全性需求而硬写,随意扩大安全性需求内涵,分析出一些并不适用的安全性需求:二是没有针对软件进行安全性分析,复制一些放之四海而皆准的要求;三是混淆了需求和解决方案,直接写出解决方案,而忽视了真正的需求。
3.8 保密性需求
GJB438原文要求“若有保密性需求,本条应指明维持保密性的系统需求,包括:系统运行的保密性环境、所提供的保密性的类型和级别、系统必须经受的保密性风险、减少此类风险所需的安全措施、必须遵循的保密性政策、系统必须具备的保密性责任、保密性认证/认可必须满足的准则等。”
此条是指系统交付后,系统在使用环境中的保密性要求。如与外部系统交互时,数据需加密交互,确保数据完整性、不可抵赖性等;系统保存的关键数据是否需要加密存储;对关键数据的销毁的要求等。注意,不要描述开发单位的保密管理要求,以及开发环境的保密性要求等。
3.9 系统运行环境需求
GJB438原文要求“若有系统环境需求,本条应指明与系统运行必需的环境有关的需求。对软件系统而言,运行环境包括支持系统运行的计算机硬件和操作系统。对硬软件系统而言,运行环境包括系统在运输、存储和操作过程中必须经受的环境条件,如自然环境条件(风、雨、温度、地理位置)、诱发环境(运动、撞击、噪声、电磁辐射)和对抗环境(爆炸、辐射)。”对纯软件系统而言,此时应按要求说明支持系统运行的计算机硬件和操作系统。对软件和硬件结合的系统而言,此时,应按要求说明对使用环境的需求;由于此时还没有确定软件能力需求,所以对软件的运行环境可以留待系统设计时明确。系统运行环境需求表示例如表3-22所示。
3.10 计算机资源需求
1)计算机硬件需求
GJB438原文要求“本条应描述系统使用的或引入到系统中的计算机硬件的需求,包括:各类设备的数量;处理机、存储器、输入/输出设备、辅助存储器、通信/网络设备及所需其他设备的类型、大小、容量和其他所需的特征。”
此条对纯软件系统直接有效,应该按要求对系统环境需求中的计算机硬件需求进行详细说明,如表3-23所示。
2)计算机硬件资源使用需求
GJB438原文要求“本条应描述本系统的计算机硬件资源使用需求(若有),例如,最大允许利用的处理机能力、内存容量、输入/输出设备的能力、辅助存储设备容量和通信/网络设备的能力。这些需求(例如陈述为每一个计算机硬件资源能力的百分比)应包括测量资源使用时所处的条件(若有)。”
此条对纯软件系统直接有效,应该按要求对计算机硬件需求中的各个硬件资源使用的需求进行详细说明,如表3-24所示。
3)计算机软件需求
GIB438原文要求“本条应描述本系统必须使用或引入系统的计算机软件的需求(若有)。例子包括:操作系统、数据库管理系统、通信/网络软件、实用软件、输入和设备仿真软76件、测试软件和制造软件。要列出每一个这样的软件项的正确名称、版本和参考文档。”
此条对纯软件系统直接有效,应该按要求对系统环境需求中的各个软件需求进行详细说明,如表3-25所示。对软件和硬件结合系统,如果此时还不能够确定系统对其他软件的需求,可以留待系统设计时明确。
4)计算机通信需求
GJB438原文要求“本条应描述本系统必须使用的计算机通信方面的需求(若有)。例子包括:要连接的地理位置;配置和网络拓扑;传输技术;数据传送速率;网关;要求的系统使用时间;被传送/接收的数据的类型和容量;传送/接收/响应的时间限制;数据量的峰值;以及诊断特性。”
这条要求应该是指系统在使用环境中,与外部系统进行通信的需求,而不是系统内部的通信需求。例如,系统通过什么配置的网络交换机与外部系统通信,分配给系统使用的带宽和使用时间是否有要求;系统通过什么通信能力的电台与外部系统通信,最大话音传输能力等。
3.11 系统质量因素
GJB438原文要求“若提出质量因素方面的需求,本条应描述系统的这些需求。包括功能性、可靠性、易用性、效率、维护性、可移植性和其他属性的定量要求。”
提示:系统质量属性是指用户级需求层面的质量属性。用户级层面的质量属性包括6类 21项质量特性，,这些质量属性可以通过分析业务级需求中的功能需求、质量需求、约束，以及用户级需求中的约束得到，
示例如表 3-26所示。
3.12 设计和构造约束
提示:设计约束包括四类:业务环境约束十使用环境约束十构建环境约束十技术环境约束;这四类约束分布在不同层面的需求。
业务环境约束。属于业务级需求,来自出资方的约束,例如上线时间、预算、集成、业务规则、行业法律法规(禁止使用解释性编程语言)等;由出资方指定技术选型(某平台、必须使用某数据库系统、必须遵循某数据标准、应与原某系统集成、应与某系统互连互通等)。
使用环境约束。属于用户级需求,来自使用方的约束,如使用者的专业能力、何种人群分布式使用、使用环境有电磁干扰、车船移动等因素。
构建环境约束。属于开发级需求,来自开发和维护人员的约束,如开发人员的技术水平、业务知识、管理水平等。
技术环境约束。来自业界当前技术环境约束,如成熟算法、技术平台、中间件、编程语言成熟度等。
这四类约束可以分为以下三种情况。
(1)直接制约设计决策的约束。如系统运行于UNIX平台上。
(2)转换为功能需求的约束。如应严格执行总部统一规定的商品折扣率。分析后可转换为功能需求:调整商品折扣率。
(3)转换为质量属性的约束。如操作人员计算机水平普遍不高。分析后转换为系统应具有高易用性(如完成一个业务操作平均输人数据次数最多N次)和容错性(如系统对输入数据在人机交互界面进行有效限制,避免操作人员输入非法数据。)
3.13 人员需求
GJB438原文要求“若有人员相关要求,则本条应描述与使用或支持系统的人员有关的需求”
注意:本条不应该描述与开发人员相关的需求,也不是单纯描述系统使用人员的数量、技能需求。
本条的目的是通过对系统使用或支持人员的数量、技能等信息进行分析,得到对系统质量因素方面的需求。参考人素工程的定义,“人素工程是一门多学科的交叉学科,研究的核心问题是不同的作业中人、机器及环境三者之间的协调……研究的目的则是通过各学科知识的应用,来指导工作器具、工作方式和工作环境的设计和改造,使得作业在效率、安全、健康、舒适等几个方面的特性得以提高。”
3.14 培训需求
对系统而言,对系统使用人员进行培训是有必要的。所以,本条应该描述与培训相关的需求。例如,需要培训的系统操作人员(角色)、数量、培训使用的教材(包括使用手册、用户手册、电子交互手册,以及其他教材)等。
注意:本条不是对系统使用方提出需求,而是站在需方的角度,对系统研制方提出培训需求,要求研制方对系统使用方进行培训,要求研制方提供合适有效的培训资料。
3.15 保障需求
GJB438 原文要求“若有综合保障相关需求,则本条应描述有关综合保障方面的系统需求,其中包括系统维护、软件保障、系统运输方式、对现有设施的影响和对现有设备的影响”
本条的目的是通过对系统交付后,如何使得保障机构能够保障系统正常运转进行分析得到与保障工作相关的系统质量因素方面的需求。
注意:本条不是对系统保障机构提要求,而是站在需方的角度,对系统研制方提出需求,要求研制方基于系统的维护保障工作的利实施，分析系统需要承担的职责。
3.16 其他需求
GJB438 原文要求"若有其他需求,则本条应描述在以上各条中没有涉及的其他系统需求…”
这条的目的是如果需方还有在合同中,以及上述需求中未覆盖到的其他系统需求,包括研制方应提供的系统文档需求,可以在本条进行说明。
3.17 包装需求
GJB438 原文要求“若有包装需求,则本条应描述需交付的系统及其部件在包装、加标签和处理方面的需求,适当时可引用适用的军用规范和标准”。
这条的目的很明确,站在需方的角度,对系统交付时的包装提出要求。一是系统及其部件的包装要求:二是系统及其部件的外加标签要求。
3.18 需求的优先顺序和关键程度
GIB438 原文要求“本条应描述本规格说明中各需求的优先次序、关键性或所赋予的指示其相对重要性的权重”
这条包含两方面的要求,一是需求的优先次序,优先次序是研制方优先实现系统需求的依据: 二是需求的关键性,关键性是研制方需要特别关注是否需要特殊处理(如需要高端专业人员参与研制、系统设计时需要给出专门的设计决策等)的依据。
例如,优先顺序定义为1和2。1是需要优先实现的基本需求;2是增强需求
关键性通常是从系统安全性和保密性角度考虑的,建议由高至低分为三个等级(A、B、C).
A是关键程度最高的需求,是指如果该类需求失效,直接影响系统所属组织无法完成核心业务或危害到系统和人员的安全。
B是关键程度第二等级的需求,是指如果该类需求失效,影响系统的主要性能实现
C是关键程度最低等级的需求,是指除了A和B等级外的需求，需求优先顺序和关键程度列表示例如表3-27所示。
4 合格性规定
GIB 438 原文要求“本条应定义一组合格性方法,并为第3章中的每个需求指定为确保需求得到满足所应使用的方法”。
合格性规定是系统合格性测试的依据。按照GJB2786A的要求,系统合格性测试应具有独立性(即必须由独立于系统研制团队的人员承担系统合格性测试)。本条的目的是站在需方的角度,为每条系统需求提出验证其合格性的方法
GJB438 提出的合格性方法如下。
(1)演示:依靠可见的功能操作,直接运行系统或系统的一部分,而不需要使用仪器专用测试设备或进行事后分析。
(2)测试:使用仪器或其他专用测试设备运行系统或系统的一部分,以便采集数据供事后分析使用。
(3)分析:处理从其他合格性方法获得的累积数据，
(4)审查:对系统部件、文档等进行目视检查。
(5)特殊的合格性方法:任何针对系统的特殊合格性方法,如专用工具、技术、规程、设施、验收限制、飞行模型或飞行航迹等。合格性规定示例如表3-28所示。
5 需求可追踪性
使用正向追踪表,说明研制要求的每项要求被分解给了哪些系统需求(系统规格说明中的三类需求)。
使用逆向追踪表,说明每个系统需求(系统规格说明中的三类需求)来自哪些研制要求
