[文档] 软件需求规格说明书

「爱情、让人受尽委屈。」 2024-03-30 10:57 72阅读 0赞

## 软件需求规格说明书 ##

### 1 范围 ###

#### 1.1 标识 ####

本条应描述本文档所适用系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号  
和发布号。

#### 1.2 系统概述 ####

本条应概述文档适用的系统和软件的用途：描述系统和软件的一般特性（如规模、安全性、可靠  
性、实时性、技术风险等特性）：概述系统开发、运行和维护的历史；标识项目的需方、用户、开  
发方和保障机构等；标识当前和计划的运行现场；列出其他有关文档。

#### 1.3 文档概述 ####

本条应概述本文档的用途和内容，并描述与它的使用有关的安全保密方面的要求。

### 2 引用文档 ###

本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应给出不能通过正常渠道的得到  
的文档的来源。

### 3 需求 ###

本章应分为如下小条规定CSCI需求，即作为CSCI验收条件的CSCI特征。CSCI需求是为满足分配给该  
CSCI的系统需求而形成的软件需求。每条需求应指定项目唯一的标识符以便测试和追踪，而且应以  
一种能为其定义具体测试对象的方式来描述。每条需求应注明所采用的合格性方法（见第4章），还  
应注明与系统或子系统需求的可追踪性（或在第5章给出）。  
注：需求的详尽程度判定指南主要有：包括了作为CSCI验收条件的所有系统特性；应遵循的设计方  
面的说明。

#### 3.1 要求的状态和方式 ####

如果要求CSCI在多种状态或方式下运行，并且不同的状态或方式具有不同的需求，则应标识和定义  
每一状态和方式。状态和方式的例子包括：空闲、就绪、活动、事后分析、训练、降级、紧急情  
况、后备、战时和平时等。可以仅用状态描述CSCI，也可以仅用方式、用方式中的状态、状态中的  
方式、或其他有效的方案描述CSCI。如果不需要多种状态和方式，应如实陈述，而不需要进行人为  
的区分；如果需要多种状态和/或方式，应使本规格说明中的每个需求或每组需求与这些状态和方式  
相对应，对应关系可以在本条或本条所引用的附录中，通过表格或其他方式加以指明，也可以在该  
需求出现打的章条中加以说明。

#### 3.2 CSCI能力需求 ####

本条应逐一列出与SCSI各个能力相关的需求，可分为若干子条。“CSCI能力需求”中的“能力”为一组相  
关需求，可用“功能”、“主题”、“目标”、或其他适合表示需求的词替代。

##### 3.2.X（CSCI能力） #####

本条应标识出所要求的每一个CSCI能力，并逐一列出与该能力，并逐一列出与该能力有关的需求。  
如果该能力可以更清晰地分解成若干子能力，则应分条对子能力进行说明。需求应详细说明所需  
的CSCI行为，包括适用的参数，如响应时间、吞吐时间、其他时限约束、时序、精度、容量、优先  
级、连续运行需求和在基本运行条件下允许的偏差：适当时，需求还应包括在异常条件、非许可条  
件或超限条件下所需的行为，错误处理需求和任何为保证在紧急时刻运行的连续性而引入到CSCI中  
的规定。在确定与CSCI所接收的输入和CSCI所产生的输出有关的需求时，应考虑在3.3.X给出的要考  
虑的主题列表。

#### 3.3 CSCI外部接口需求 ####

本条可分为若干个小条件来规定关于CSCI的外部接口的需求（若有）。本条可引用一个或多个接口  
需求规格说明（IRS）或包括这些需求的其他文档。

##### 3.3.1 接口标识和接口图 #####

本条应标识所需要的CSCI外部接口（即，与涉及共享、提供或交换数据的其他实体的关系）。每一  
个接口的标识应包括项目唯一的标识符，（若适用）应通过名称、编号、版本、引用文档来指明接  
口实体（系统、配置项、用户等）。该标识应声明哪些实体具有固定的接口特性（要给出这些接口  
实体的接口需求）：说明哪些实体正在开发或修改之中（这些实体已有各自的接口需求）。应该通  
过一张或多张接口图来描述这些接口。

##### 3.3.X（接口的唯一标识符） #####

本条（从3.3.2开始）应通过唯一标识符来标识CSCI外部接口，应简要地标识接口实体。视需要可分  
为小条描述为实现该接口提出的该CSCI的需求。该接口所涉及的其他实体的接口特性应作为假定予  
以描述，或以“当\[未涵盖的实体\]这么做时，本CSCI应该······”的形式加以叙述，而不作为针对其他实  
体的需求。本条可引用其他文档(例如数据字典、通信协议标准、用户接口标准)代替在此描述信息。  
（若适用）需求用应包括如下内容，并以任何适合于需求的顺序给出，还应从接口实体的角度说明  
这些特性之间的区别（例如对数据元素的大小、频率或其他特性的不同期望值）：  
\-CSCI分配给该接口的优先级。  
\-所实现的接口类型（如实时数据传送、数据的存储和检索等）的特征。  
\-CSCI所提供、存储、发送、访问和接收的各个数据元素的特征，例如：  
1.名称/标识符：  
\-唯一标识符；  
\-非技术名称（自然语言名称）；  
\-数据元素名（应优先使用标准化的数据元素名称）；  
\-技术名称（如系统中变量名称、数据库字段名称）；  
\-缩略名或同义词名。  
2.数据类型（字母、数字、整数等）。  
3.大小和格式化（如：字符串的长度）。  
4.计量单位（如：m等）。  
5.可能值的范围或枚举（如：0-99）。  
6.准确性（正确程度）和精度（有效数字位数）。  
7.优先级、定时、频率、容量、序列以及其他约束条件（例如数据元素是否可以被更新、业务规  
则是否适用）。  
8.保密性约束。  
9.来源（建立/发送实体）和接收者（使用/接收实体）。  
\-CSCI所提供、存储、发送、访问和接收的数据元素组合体（记录、消息、文件、数据、显示和报  
表等）的特征，例如：  
1.名称/标识符：  
\-唯一标识符；  
\-非技术名称（自然语言名称）；  
\-技术名称（如系统中变量名称、数据库字段名称）；  
\-缩略名或同义名。  
2.数据元素组合体中的数据元素及数据元素的结构（编号、顺序和成组情况）。  
3.介质（例如光盘）以及在介质上数据元素/包的结构  
4.显示和其他输出的视听特性（例如颜色、布局、字体、图标和其他显示元素、蜂鸣音和亮度）  
5.数据元素组合体之间的关系，如排序/存取特性。  
6.优先级、时序、频率、容量、序列及其他约束，例如包是否可以被更新、业务规则是否适用。  
7.保密性约束。  
8.来源（建立/发送实体）和接收者（使用/接收实体）。  
\-CSCI所使用的接口通信方法的特征。如：  
1.唯一标识符；  
2.通信链路/宽带/频率/介质及其特性；  
3.消息格式；  
4.流控制（如：序列编号和缓冲区分配）；  
5.周期/非周期传送的数据传送速率，传输间隔；  
6.路由、寻址、命名约定；  
7.传输服务，包括：优先权和等级；  
8.安全性/保密性考虑，如：加密、用户鉴别、隔离和审核。  
\-CSCI所使用的接口协议的特征，如：  
1.唯一标识符；  
2.协议的优先级/层次；  
3.打包（包括拆包和重新打包）、路由和寻址；  
4.合法性检查、错误控制和恢复过程；  
5.同步，包括建立连接、保持和终止；  
6.状态、标识和其他需要报告的内容。  
\-其他要求的特征，例如接口实体的物理兼容性（尺寸、公差、负责和接插件的兼容性等）、电压  
等。

#### 3.4 CSCI内部接口需求 ####

本条应指明施加于CSCI内部接口的需求（若有）。如果所有内部接口都留待设计时在明确，那么应  
在此如实陈述。如果施加了这样的需求，应按3.3要求描述。

#### 3.5 CSCI内部数据需求 ####

本条应指明施加于CSCI内部接口的需求（若有），包括对CSCI中数据库和数据文件的需求（若  
有）。如果关于内部数据的所有决策都留待计时再考虑，那么应在此如实陈述。如果施加了这样的  
需求，应按3.3.Xc）和3.3.X.d)要求描述。

#### 3.6 适应性需求 ####

（若有）本条应指明与CSCI安装相关的数据需求（如场地的经纬度或位置编码），应描述CSCI使用  
要求的运行参数（如与使用相关的目标设置或数据记录等方面的参数），这些运行参数可能会根据  
运行需要而改变。

#### 3.7 保密性（Security）需求 ####

（若有）本条应指明与维护保密性相关的CSCI需求。（若适用）这些需求应包括：CSCI必须在其中  
运行的保密环境、所提供的保密性类型和级别、CSCI必须经受的保密性风险、减少此类风险所需的  
安全措施、必须遵循的保密性政策、CSCI必须具备的保密性责任、保密性认证认可必须满足的准则  
等。

#### 3.8 安全性（Safety）需求 ####

（若有）本条应指明关于防止或尽可能降低对人员、财产和物理环境产生意外危险的CSCI安全性需  
求。例子包括：CSCI必须提供的安全措施，以便防止意外动作（例如意外地发出一个“自动导航关  
闭”命令）和无动作（例如发出“自动导航关闭”命令失败）。本条还应包括关于系统核部件的CSCI需  
求（若有），若适用应包括预防意外爆炸以及与核安全规则保持一致等方面的需求。

#### 3.9 CSCI环境适应性需求 ####

（若有）本条应指明CSCI的运行环境需求，例如运行CSCI的计算机硬件和操作系统（对计算机资源的其他需求见3.11）

#### 3.10其他质量特性 ####

本条应指明合同规定的或由更高一层规格说明派生出的CSCI其他质量特性方面的需求，其中包括：  
可靠性、测试性、维护性等。

#### 3.11 计算机资源需求 ####

##### 3.11.1 计算机硬件需求 #####

本条应指明CSCI必须使用的计算机硬件的需求（若有）。（若适合）这些需求应包括：各类设备的  
数量：处理机、存储器、输入/输出设备、辅助存储器、通信/网络设备及所需其他设备的类型、大  
小、容量和其他所需的特征。

##### 3.11.2 计算机硬件资源使用需求 #####

本条应指明CSCI计算机硬件资源使需求（若有），例如：最大允许利用的处理能力、内存容量、输  
入/输出设备的能力、辅助存储设备容量和通信/网络设备的能力。这些需求（例如陈述为每一个计算  
机硬件资源能力的百分比）应包括测量资源使用时所处的条件（若有）。

##### 3.11.3 计算机软件需求 #####

本条应指明CSCI必须使用或必须被纳入本CSCI的计算机软件的需求（若有）。例子包括：操作系  
统、数据库管理系统、通信/网络软件、共用软件、输入和设备仿真软件、测试软件和制造软件。要  
列出每一个软件项的正确名称、版本和参考文档。

##### 3.11.4 计算机通信需求 #####

本条应指明CSCI必须适用的计算机通信方面的需求（若有）。例子包括：要连接的地理位置；配置  
和网络拓扑；传输技术；数据传送速率；网关；要求的系统使用时间‘被传送/接收的数据的类型和容  
量；传送/接收/响应的时间限制；数据量的峰值；以及诊断特性。

#### 3.12 设计和实现约束 ####

本条应指明约束CSCI的设计和实现的需求（若有）这些需求可引用相应的商用或军用标准和规范来  
指定。关于这方面需求例子如下：  
\-使用一个特定的CSCI体系结构，或针对体系结构，或针对体系结构的要求，例如所要求的数据库或  
其他软件单元：使用标准的或现有的部件；或使用由政府/需方提供的资源（设备、信息或软件）；  
\-使用特定的设计或实现标准；使用特定的数据标准‘使用特定的编程语言；  
\-为支持在技术、威胁或使命方面预期的增长或变化，必须提供的灵活性或可扩展性。

#### 3.13 人员相关需求 ####

（若有）本条应描述CSCI需求，包括与CSCI使用或保障人员有关的容纳人员的数量、技能等级、工  
作周期、必需的训练以及其他的信息，例如要求允许多少用户同时工作，以及内置的帮助和培训短  
片等方面的需求；也包括施加于CSCI的人机工程需求（若有）。这些需求包括对人员在能力与局限  
性方面的考虑；在正常和极端条件下可预见的人为错误；以及人为错误造成特别重要影响的区域。  
例如包括对错误消息的颜色和持续时间、关键指示器或按钮的物理位置、以及对听觉信号的使用要  
求。

#### 3.14 训练相关需求 ####

（若有）本条应指明与训练相关的CSCI需求，如包括在CSCI中的训练软件。

#### 3.15 软件保障需求 ####

本条应指明与软件保障考虑有关的CSCI需求（若有）。这些考虑可以包括：对系统维护、软件保  
障、系统运输方式、补给系统的要求、对现有设施的影响和对现有神的影响。

#### 3.16 包装需求 ####

本条应指明上述各条未能覆盖的其他CSCI需求（若有）。

#### 3.17其需求 ####

本条应指明上述各条未能覆盖的其他CSCI需求（若有）。

#### 3.18 需求的优先顺序和关键性 ####

（若适用）本条应指明规格书明中各需求的优先次序、关键性或表示其对重要性的权重。例如标识  
出对安全性和保密性关键的需求，以便进行特殊处理。如果所有需求具有相等的权重，本条应如实  
说明。

### 4 合格性规定 ###

本条应定义一组合格性检验方法，针对第3章中的每个需求得到满足所使用的方法。可用表格形式表  
达，或为第3章中每个需求注明所使用的方法。合格性检验方法可以包括：  
\-演示：不需要使用仪器、专用测试设备或进行事后分析，而是依靠可见的功能操作，直接运行本  
CSCI或本CSCI的一部分。  
\-测试：使用仪器或其他专用测试设备，运行本CSCI或本CSCI的一部分，采集数据供事后分析使用。  
\-分析：处理从其他合格性检验方法获得的累积数据。例如，对测试结果进行约简、解释或推断。  
\-审查：对CSCI代码、文档等进行目视检查。  
\-特殊的合格性检验方法：任何针对CSCI的特殊合格性方法，例如专用工具、技术、规程、设施、验  
收限制。

### 需求可追踪性 ###

本章应描述：  
\-从本规格说明中的每一个CSCI需求，到所涉及的系统/子系统需求的可追踪性（也可以通过对第3章  
中的每一个需求进行注释来提供可追踪性）。  
注：每一个层次的系统细化都可能导致需求不能直接追踪到较高层次。例如：一个系统结构需求中  
并没有被涵盖，这样的需求可以被追踪到类似与“系统实现”这样的一般需求，或被追踪到导致它们产  
生的系统设计决策。  
\-从已分配给本CSCI的每一个系统/子系统需求，到所涉及的CSCI需求的可追踪性。分配给本CSCI的  
全部系统/子系统需求都应加以说明。追踪到包含在IRS中的CSCI需求时，可引用那些IRS。

### 6 注释 ###

本章应包括有助于了解文档的所有信息（例如：背景、术语、缩略语或公式）。