前言：
当前同学们对“c语言的概要设计”可能比较重视，各位老铁们都想要学习一些“c语言的概要设计”的相关内容。那么小编在网络上收集了一些关于“c语言的概要设计””的相关资讯，希望姐妹们能喜欢，小伙伴们快快来学习一下吧！软件研制任务书、详细设计模板、概要设计说明书、软件需求规格说明文档编制方案。需要源文件的评论即可。
软件研制任务书
1 范围1.1 标识
应包含本文档适用系统的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。
1.2 系统概述
本条应概述本文档所适用的系统和软件的用途，描述系统与软件的一般特性。概述系统开发、运行和维护历史；标识项目的需方、用户、开发方和保障机构等，标识当前和计划的运行现场，列出其他有关文档。然后，按以下逐项说明XXXX系统的基本情况。
描述本文档所适用的系统和软件用途，软件的一般特性。
a) 需方：指签定XXXX项目研制合同的甲方单位名称；
b) 用户：指XXXX项目和软件的直接使用单位名称；
c) 开发方：XXXXXXXXX有限公司
d) 项目开发简历：
1) 项目立项时间：
2) 系统方案正式通过评审的时间；
1.3 文档概述
本条应概述本文档的用途和内容，并描述与它的使用有关的保密性方面的要求。
本文档用于说明XXXX软件开发的目的、目标、主要任务、功能及性能指标等要求，是该软件开发的基础和依据，同时也是该软件验收的依据。
在本文档中，第2章列出了本文档中引用的其它文档的信息，第3章详细描述了XXXX软件的运行环境要求，第4章说明了XXXX软件的功能、性能、输入输出、接口、可靠性、安全保密性等技术要求，第5章描述了XXXX软件的设计约束，第6章描述了XXXX软件的关键性等级、执行标准、文档编制、配置管理、软件测试、分承制方管理等方面的质量控制要求，第7章说明了XXXX软件的验收和交付要求，第8章描述了XXXX软件的保障性要求，第9章说明了XXXX软件的研制进度计划和里程碑及评审要求。
2 引用文档
本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识不能通过正常采购活动得到的文档的来源。
本文档中的引用文档参见表1。
表1 引用文档表
文档编号
标题
版本
修订日期
编写单位
填表说明：
文档编号：指引用文档的文件标识号；
标题：指引用文档的文件名称；
版本：指引用文档的文件版本号；
修订日期：指引用文档的定稿日期；
编写单位：指编写该引用文档的单位名称。
3 运行环境要求3.1 硬件环境
本条应描述CSCI运行必需的硬件环境的要求，包括：
a) 宿主机和目标机的型号、主要性能指标及资源配置和分配；
b) 通用外设的种类、数量、型号、规格及主要性能指标；
c) 专用外设的种类、数量、性能及接口情况。
3.2 软件环境
描述XXXX软件运行必需的软件环境的要求。若适用，本节可照抄如下内容：“XXXX软件运行所需的软件环境由操作系统、数据库管理软件、通信/计算机网络软件、应用支撑软件、软件工具和编程语言要求组成，该软件运行所需的软件环境要求见表2”。
表2 XXXX软件运行所需的软件环境要求表
软件种类
软件名称
软件版本
操作系统
数据库管理软件
通信/计算机网络软件
应用支撑软件
软件工具
编程语言
编程要求
填表说明：
软件种类：指XXXX软件运行所需的系统软件和支撑软件等软件类型；
软件名称：指XXXX软件运行所需的各种软件的具体名称；
软件版本：指XXXX软件运行所需的各种软件的版本；
编程语言：指在编写XXXX软件代码时要求使用的程序设计语言名称；
编程要求：说明编写XXXX软件代码时的编程规范要求，可直接引用有关的软件编码规范。
4 技术要求4.1 功能
本条可分条描述需要由软件产品完成的所有功能、工作模式、容错要求、特殊要求（如对某些意外的适应能力）及应急措施和可扩展要求。
如果该软件存在多个工作模式，而且在不同的工作模式下该软件的功能或性能或接口等要求不同，本节应以独立小节完整地列出该软件的不同工作模式及其分配的功能或性能或接口要求。否则，无需描述该内容。
名称、标识符
功能描述
优先级
补充说明
4.2 性能
本条应描述对软件的精度、实时性、时间、占用存储空间的开销及余量等性能指标要求。
4.3 输入/输出
本条应描述本软件所有输入/输出信息的来源、格式、数量、频度、顺序、值域、精度、接收方法及信号发生的最短时间间隔，发送方法及发送对象，中断信号数量、优先级，需要时给出与其他软件的接口，以及对于嵌入式软件程序的固化地址。
若适用，填写XXXX软件输入输出信息表（见表3）。
表 3 XXXX软件输入输出信息表
信息名称
信息格式
值域范围
来源/目的地
输入/输出方法
输入
输出
填表说明：
信息名称：指输入/输出信息的名称；
信息格式：指输入/输出信息的数据类型或格式；
值域范围：指输入/输出信息的数据值大小或范围；
来源/目的地：对于输入信息说明其发送方名称（如：用户、XXXX软件、XXXX外部系统或XXXX外部设备等）；对于输出信息说明其接收方名称,如：数据库、人机界面、XXXX软件、XXXX外部系统或XXXX外部设备等；
输入/输出方法：对于输入信息说明其数据输入方法（如：人机界面输入、进程通信、网络通信等）；对于输出信息说明其数据输出方法（如：显示、打印、进程通信、网络通信等）。
4.4 数据处理要求
本条应列出所有处理需要的条件，说明数据参数的处理精度、处理速度、传递关系、并行关系和最大信息量情况（最大数据容量、最大数据流通率、允许最长中断排队长度及处理时间等），规定对冗余信息的处理准则。用表格的形式列出所有参数，并说明每个参数的名称、量纲、数据精度及
对软件的使用要求等。
若适用，填写XXXX软件数据处理要求表（见表4）。
表 4 XXXX软件数据处理要求表
数据参数名称
数据类型
值域范围
数据处理方法要求
备注
填表说明：
数据参数名称：指该数据参数的军用标准名称；
数据类型：指该数据参数的数据类型；
值域范围：指该数据参数的数据大小或范围；
数据处理方法：说明XXXX软件对该数据参数的处理方法或算法，如：入库、显示、计算、打印等。
4.5 接口
本节应分项列出XXXX软件与其它软件配置项、外部系统或设备的接口，各接口的用途，接口形式，接口信息或数据。若适用，填写XXXX软件接口列表（见表5）：
表 5 XXXX软件接口列表
序号
接口名称
接口用途
接口形式
接口信息或数据
备注
填表说明：
接口名称：说明XXXX软件与XXXX软件或设备或外部系统的接口的名称；
接口用途：说明接口的主要用途；
接口形式：说明该接口采用的通信协议等；
接口信息或数据：说明该接口涉及哪些信息或数据；
备注：说明其它需要说明的内容。
4.6 固件
对于嵌入式软件,若适用，本节应描述程序的固化地址、安装和操作要求。否则，本节可照抄如下内容：“XXXX软件无固件安装和操作要求”。
4.7 关键性要求4.7.1 可靠性
本条按需要可分成若干条描述软件可靠性指标及可靠性要求；描述软件的容错、冗条要求及建议，并提出与操作员有关的容错要求；描述软件的健壮性要求，如对系统瞬时掉电、受外界干扰、接口故障（非法输入、常0／l故障）等的适应能力，提出局部软、硬件失效时的降级设计要求。否则，本节可照抄如下内容：“XXXX软件无特殊的软件可靠性要求”。
4.7.2 安全性
本节应列出防止用户误操作给XXXX软件的运行和内部数据造成破坏的防护措施要求。本条按需要可分成若干条描述软件安全性要求；如关键功能至少要由两个独立的程序模块共同完成，“监视时钟”（看门狗）的设置要求，软件（程序）多余物的处理，程序块的隔离，内存未用空间和未采用中断的处理，对关键数据、变量的保护和校核等；描述安全性关键功能软件的标识、控制、检测和故障识别；描述软件失控、加电检测控制顺序出现异常造成的可接受的最低安全性水平；
描述关于系统的某些故障模式和软件的故障对策要求。若适用，描述不允许出现的故障模式。
若适用，可从以下内容中选择：
a) 身份验证；
b) 输入信息的合法性检查；
c) 误操作防护；
d) 信息删除警示；
e) 数据库访问权限控制。
4.7.3 保密性
本节应描述为保障XXXX软件的运行和内部数据的保密性，需要XXXX软件所采取的保密措施要求，如口令、密码、访问控制、数据加密等。若适用，可从以下内容中选择：
a) 数据传输加密；
b) 数据存储加密；
c) 口令；
d) 访问控制。
5 设计约束
本节应说明XXXX软件的编程语言和编程规则、开发工具和环境、测试工具和环境以及重用性和可移植性要求等设计约束。
a) 软件的数学模型、规则、计算公式、参数名称、符号和重用要求；
b) 编程语言：如：C语言/JAVA等程序设计语言；
c) 编程规则：可直接引用相关的软件编码规范；
d) 开发工具和环境：包括软件需求分析与设计建模工具（如：Rational Rose/BPwin/ERwin等）和软件编程工具（如：VC/.NET/JBuild等）；
e) 测试工具和环境：如：Rational PurifyPlus/TestManager等；
f) 重用性要求：如果有，应明确说明本软件产品是否“开发为可重用软件产品”或“采用可重用软件产品”，否则，为“无”；
g) 可移植性要求：如果有，应明确说明要求移植的目标操作系统的名称及其版本，否则，为“无”。
6 质量控制要求6.1 软件关键性等级
本节应说明本软件的关键等级、规模等级和相关的要求。
6.2 标准
本条应描述软件开发等应遵循的标准
编号
标准
1
GJB 438B-2009军用软件开发文档通用要求
2
GJB 2786A 军用软件开发通用要求
3
军用软件产品开发实施管理手册
4
软件设计开发流程
5
软件需求管理流程
6
软件项目策划和监控管理流程
7
软件生命周期模型选择和裁剪指南
8
项目估算指南
9
测量与分析管理规范
10
配置管理规范
11
项目风险管理规范
12
软件过程和产品质量保证程序
13
评审管理规范
14
问题管理规范
15
C语言/Java编码规范
6.3 文档
本条应描述应有的开发文档清单以及对它们的评审要求：
编号
文档
1
XXXX软件用户手册（操作手册、维护手册）
2
XXXX软件需求规格说明
3
XXXX软件设计说明
4
XXXX软件版本说明
5
……
6.4 配置管理
本节应描述XXXX软件的配置管理要求，若适用，本节可照抄如下内容：“XXXX软件应按照《配置管理规范》的要求，制定配置管理计划，实施软件配置管理”。
6.5 测试要求
本条应描述软件测试的要求；必要时规定软件测试的特殊要求，如软件必须由第三方独立测试等。
按照GJB 438和GJB 2786的要求，制定软件测试计划，实施分级、分阶段软件测试，监督软件测试过程，进行软件代码审查，建立和完善软件测试环境，若适用，本节可在以下内容中选择：
a) 软件测试级别：如：专业部测试/出所检验/第三方测试；
b) 软件测试的环境：如：开发平台上/使用平台上/现场/外场等；
c) 软件测试类型：如：功能/性能/边界/余量/接口/可靠性/压力/安全性/保密性；
d) 软件测试的覆盖率要求：如：正常输入/异常输入/异常接口测试要求。
6.6 对分承制方的要求
当存在软件分承制方时，本节应描述对分承制方的要求，若适用，本节可照抄如下内容：“XXXX软件应按照《设计外包管理规范》的要求进行分承制方软件开发过程管理”，否则，写“无软件分承制方”。
7 验收和交付
本节应说明软件验收和交付的要求，若适用，本节可照抄如下内容：
a) 验收级别：系统项目组验收；
b) 验收测试要求：见第6.5节中的测试要求；
c) 对程序的验收要求：目标码介质要求/包装要求等；
d) 审查第6.3节文档清单中的全套软件文档资料；
e) 验收测试和软件文档资料审查均通过后方可验收合格并交付系统项目组,XXXX软件交付的软件产品包括：
1) XXXX软件安装包（或可执行程序）；
2) XXXX软件源代码；
3) XXXX软件技术文件：见第6.3节中的文档清单。
8 软件保障要求
本节应描述在XXXX软件移交系统工程组后的有关软件维护、培训等技术保障要求，若适用，本节可照抄如下内容：“XXXX软件交付系统项目组后应参加XXXX系统/分系统集成联试试验/出所检验/第三方测试、软件开发人员应完成XXXX软件的用户现场安装调试和用户培训等”。
9 进度和里程碑
本节应描述XXXX软件开发的进度要求、里程碑和需要需方参加的评审等，若适用，填写XXXX软件进度要求表（见表6）。
表 6 XXXX软件进度要求
阶段名称
进度要求
是否为里程碑
是否需要需方评审
软件需求分析
XXXX年X月X日～X月XX日
里程碑
软件设计
XXXX年X月X日～X月XX日
软件编码与单元测试
XXXX年X月X日～X月XX日
软件系统测试
XXXX年X月X日～X月XX日
里程碑
软件验收发布
XXXX年X月X日～X月XX日
填表说明：
阶段名称：指该软件开发过程所需经过的阶段名称；
进度要求：指各阶段的开始日期和完成日期；
是否为里程碑：指该阶段工作完成时是否建立项目软件开发里程碑；
是否需要需方评审：说明是否需要需方参加该里程碑评审。
10 注释
本章包括有助于了解文档的所有信息(例如:背景、术语、缩略语或公式)。
概要设计说明书
1 简介1.1 目的
这部分要描述文档的目的。应该指明读者。
1.2 范围1.2.1 软件名称
对软件命名
1.2.2 软件功能
解释软件产品将完成或不完成的功能（可以直接描述也可以参考相关文档）
1.2.3 软件应用
描述软件的应用领域（可直接描述也可以参考其他软件文档）
2 第0层设计描述2.1 软件系统上下文定义
本节描述待开发软件系统与外部实体的关系，可以使用系统结构图来描述系统结构和交互关系。
外部实体属性描述只限于软件设计和描述相关的属性。考虑到描述的完整性，可参考相关软件实体文档，如OS程序员手册。
2.2 设计思路(可选)2.2.1 设计可选方案
对本软件系统的几种设计方案进行分析、比较，并确定所采用的方案。
2.2.2 设计约束
1. 遵循标准
描述本软件所遵循的标准、规范
2. 硬件限制
描述本软件系统实现的硬件限制
3. 技术限制
描述本软件的技术限制
2.2.3 其他
描述其他有关的设计考虑
3 第一层设计描述3.1 系统结构
如果本文档是针对增强开发/小特性的设计，继承了原有的系统结构，那么应拷贝原有的系统结构说明，如系统结构图和相应的文字说明，然后在一层设计中明显标识出新增功能在原有系统结构中的位置（属于原来哪一个模块的新增功能，与原有各模块之间有什么交互）。在后续的业务流程说明、模块分解描述、依赖性描述和接口描述中，如果与本次增强开发/小特性无关的，可以不再重复描述，如果有关联的，应该拷贝原有的设计说明，在此基础上再说明更改的内容。
3.1.1 系统结构描述
这里要描述软件系统的总体结构，可以使用结构图、层次分解图或包图来描述，并应说明系统结构划分的原则（例如，基于标准、协议所规定的体系结构，来自于分析模型的结果，或者基于原有体系结构的结果）。对于使用分析模型的体系结构，应说明分析类的职责及相互关系。
3.1.2 业务流程说明
描述系统架构模块/分析类之间的动态交互，来说明用例模型中的典型用例场景，以体现系统功能是如何实现的。建议采用Sequence图、Collaboration图等来描述。
3.2 分解描述
本节描述系统中的子系统和模块。
3.2.1 模块/子系统1描述
不要直接写“模块/子系统1”，用简短的词语命名模块/子系统。
按照以下格式描述：
1. 简介
2. 功能列表
3.2.2 数据设计
本节描述系统中的数据结构。
外部数据实体不必描述。
1. 数据实体1描述
按照以下格式描述：
标识：
类型：
目的：
3.3 依赖性描述
本节描述系统中的子系统，数据结构，模块，进程等设计实体间的关系。
依赖关系描述可以使用文字，结构图，（交互）事务图。
3.4 接口描述
本节描述软件系统中设计实体(如子系统，模块，进程）的接口.
I接口描述可以使用接口文件，参数表。
对于外部实体只有同被描述软件相关的接口才需描述。
接口可以是函数调用、事件、消息、信号等。
3.4.1 模块/子系统1的接口描述
对每个接口按照以下格式描述：
名称：（接口名称）
说明：（对接口的简短说明）
定义:（接口原型定义，说明接口类型及相关参数）
4 第二层设计描述
L1中定义的每个模块的进一步设计在下面的章节进行描述。对层次比较多的模块，可以增加设计层次，最终要说明对应于最小分解模块的具体设计类（包括其public属性和public方法）。
对每个模块重复使用下述的格式。
4.1 模块1名称
不要直接写 “模块1名称”，用简短的词语命名模块。
如果本文档是针对增强开发/小特性的设计，继承了原有的二层模块结构，那么应拷贝原有的模块结构说明，如包图/类图和相应的文字说明，然后在二层设计中明显标识出新增功能在原有模块结构中的位置（属于原来哪一个子模块/设计类的新增功能，与原有各子模块/设计类之间有什么交互）。在后续的功能实现说明和设计类定义中，如果与本次增强开发/小特性无关的，可以不描述，如果有关联的，应该拷贝原有的设计说明，在此基础上再说明更改的内容。 对更改的设计类应该给出类的完整定义，再标识出更改的属性和方法。
4.1.1 模块设计描述
描述模块分解，例如每个子模块的功能定义。定义出具体的设计类，用类图来描述其相互关系，并说明所采用的设计模式。
对每个类重复使用下述的格式进行描述。
1.类名
按下面的格式对每个设计类进行说明。
1）CI标识
说明该类的配置项标识(用于需求跟踪，配置项的命名方式在CMP中已定义。一般为：产品名_模块名_类名，如果在类的命名中未包括前面两部分)。
2）简介
简单介绍该类的功能。
3）类定义（Optional）
如果该类在前面没有定义，使用类图、伪代码描述该类的类定义，需说明该类的所有public属性和public方法。
4.1.2 功能实现说明
使用Sequence图、Collaboration图等来说明这些设计类之间如何交互，实现本模块的典型功能。
5 数据库设计（可选）
本节列出所有的数据存储类的实体(表、存储过程、触发器等)，详细描述实体的内容和并列出全部属性。对每个属性，详细描述其数据库、数据大小、特定约束。实体的所有约束及实体间的关系也要注明。
5.1 实体定义5.1.1 分解描述
阐述设计思路及约束规则。
详细定义每个关键数据表、视图中的各个字段属性、存储要求、完整性约束、功能、注意事项，静态数据表可考虑定义初始配置记录。
5.1.2 内部依赖性描述
使用E-R图描述实体间的关联依赖关系，分析对存取空间、性能、完整性的要求。
5.2 行为定义5.2.1 分解描述
根据功能或其他方式对存储过程/触发器进行归类，便于进一步细化和分解，并说明每类存储过程/触发器主要功能。
详细定义每个存储过程(触发器)的功能、输入输出参数、返回值、返回的记录集、依赖的数据表和存储过程，以及一些特殊要求（比如需要启用事务等）。
5.2.2 外部依赖性描述
描述与其它模块之间的依赖关系。
5.2.3 内部依赖性描述
描述存储过程间、存储过程和数据表/视图间依赖关系。
6 组件视图6.1 系统运行组件
使用Component图、deployment图来描述系统的运行组件（EXE文件、DLL等），及其网络部署情况。
6.2 文件组织形式
描述源代码文件的目录结构（文件夹中各个目录下应存放什么文件）。
7 进程视图
本节描述将系统分解为轻量级进程（单个控制线程）和重量级进程（成组的轻量级进程）的过程。本节按照各个通信或交互的进程组来加以组织。说明进程之间的主要通信模式，例如消息传递、中断和会合。
详细设计模板
1 概述1.1 目标
应包含以下几个方面的内容：
1、该文档所描述的模块；
2、该文档所针对的读者；
1.2 范围
概述本文档所包含的内容
2 模块1详细设计2.1 类12.1.1 简介
详细描述CLASS1的职责和功能；必要时，可描述本类与相关类之间的静态/动态关系。
2.1.2 类图
提供类的结构图
2.1.3 状态设计
可用状态图来描述类的状态信息
2.1.4 属性
可先定义相关的数据结构。.
可见性
属性名称
类型
说明（对属性的简短描述）
2.1.5 方法
下面针对每个方法进行说明。
1. 方法1
（1）方法描述
Prototype
方法的声明，包含可见性
函数原型
Description
描述本方法的功能
功能描述
Calls调用函数
被本函数调用的函数清单（非系统函数）
Called By被调用函数
调用本函数的函数清单（非系统函数）, 可选
Input输入参数
描述每个输入参数的含义、内存管理原则
Output输出参数
描述每个输出参数的含义、内存管理原则
Return返回值
描述返回值的含义
Exception抛出异常
描述可能抛出的异常
（2）Implementation Description实现描述
使用伪代码、流程图等来描述本方法的详细实现。这部分是详细设计的重点。
3 模块2详细设计3.1 类13.1.1 简介
详细描述CLASS1的职责和功能；必要时，可描述本类与相关类之间的静态/动态关系。
3.1.2 类图
提供类的结构图
3.1.3 状态设计
可用状态图来描述类的状态信息
3.1.4 属性
可先定义相关的数据结构。.
可见性
属性名称
类型
说明（对属性的简短描述）
3.1.5 方法
下面针对每个方法进行说明。
2. 方法1
（1）方法描述
Prototype
方法的声明，包含可见性
函数原型
Description
描述本方法的功能
功能描述
Calls调用函数
被本函数调用的函数清单（非系统函数）
Called By被调用函数
调用本函数的函数清单（非系统函数）, 可选
Input输入参数
描述每个输入参数的含义、内存管理原则
Output输出参数
描述每个输出参数的含义、内存管理原则
Return返回值
描述返回值的含义
Exception抛出异常
描述可能抛出的异常
（2）Implementation Description实现描述
使用伪代码、流程图等来描述本方法的详细实现。这部分是详细设计的重点。
4 数据库详细设计(可选)
描述存储过程、触发器等的详细实现
4.1 存储过程1/触发器1的名称
（1）Descriptions语法
Prototype
原型描述
原型
Description
描述实现的功能
功能描述
使用的数据库对象
Input输入参数
描述每个输入参数的含义
Output输出参数
描述每个输出参数的含义
Return返回值
描述返回值的含义
5 错误处理5.1 系统错误
描述象内存分配失败，任务创建失败等错误是如何被处理的。
5.2 接口错误
描述将要产生并给外部实体用的错误码
5.3 协议错误
描述在协议中没有描述的情况如何处理。（可选）
软件需求规格说明
1 范围1.1 系统概述
XXXX。
1.2 文档概述
本文档按照《XXXX研制合同》、《XXXX研制方案》的要求，详细分析了XXXX的主要功能、性能及内外部接口需求，为XXXX软件开发设计提供依据和参考。
1.3 术语及缩略语
本文档中使用的术语或缩略语详见表1 1：
表1 1 本文档使用的术语或缩略语一览表
序号
术语或缩略语
解释
备注
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
2 引用文档
表 2 1 引用文档一览表
序号
文档标识
文档名称
版本号
备注
/
《XXXX研制合同》
/
/
《XXXX研制方案》
/
3 需求3.1 要求的状态和方式
XXXX的状态包括：
（1） 部署状态；
（2） 运行状态；
（3） 维护状态；
3.2 系统能力需求
XXXX。
3.3 系统外部接口需求
XXXX与其他系统的接口关系如图3 1所示：
图3 1 XXXX与其他系统间接口关系图
3.3.1 管理接口
与外部管理接口采用IP口和串口，在本系统中与其他系统对应的管理接口如表3 1所示：
表3 1 XXXX外部管理接口对照表
分系统
设备
管理接口
3.3.2 业务接口
XXXXXXX，在本系统中与其他系统对应的业务接口如表3 2所示：
表3 2 系统外部业务接口对照表
分系统
设备
接口类型
3.4 系统内部接口需求
XXXX。
3.5 系统内部数据需求
在系统运行过程中应该注意数据的完整性，具体需求如下：
（1） 满足在数据存储、传输过程中的完整性需求；
（2） 要保证数据存储和传输过程中不被篡改和破坏；
（3） 在特殊需求功能中，比如主备倒换的过程中，应该保证用户数据的完整性；
（4） 系统运行过程中在遇到硬件故障、网络故障、人为因素、意外灾难等情况下尽量保证数据的完整性。
3.6 适应性需求
参见“六性”需求。
3.7 安全性需求
参见“六性”需求。
3.8 保密性需求
软件在投入使用后应该具有比较高的保密级别，具体需求如下：
XXXX。
3.9 环境需求
参见“六性”需求。
3.10 计算机资源需求3.10.1 硬件环境
软件产品运行环境中使用的硬件项如下表：
表 3 3 运行环境中硬件项一览表
序号
硬件项名称
硬件配置
备注
1.
2.
3.
4.
3.10.2 软件环境
软件产品运行环境中使用的软件项如下表：
表 3 4 运行环境中软件项一览表
序号
软件项名称
软件版本
备注
1.
2.
3.
4.
5.
6.
7.
3.11 软件质量因素
参见“六性”需求。
3.12 设计和构造的约束
应符合相关标准的要求：
（1） 设备软件采用模块化设计, 各主要功能模块尽可能封装为一个独立的可执行单元；
（2） 软件设计应该考虑到未来升级和修改的需要，尽量考虑将系统的核心部分设计利于扩展，在扩展新功能的时候，减少核心代码的修改；
（3） 各功能模块对外接口使用行业标准接口规范，遵循的依据及顺序为国军标、国标、行业标准、系统工程标准；
（4） 提高抽象能力，将模块功能细分，合并软件功能，提炼标准组件，规范对外接口，以动/静态库的形式提供使用，降低模块间的耦合度；
（5） 采用多线程技术提高系统的实时性；
（6） 产品的技术文件、文档及图样应符合标准的要求，格式统一；
（7） 产品设计过程中，应根据用户情况提供相关的培训资料。
3.13 人员需求
在系统交付使用后，需要有专门的系统维护人员，该人员的职能需求主要包括：
（1） 职责范围：负责设备日常运行维护，根据通信需求对系统业务进行配置，监控系统日志、告警信息，了解系统运行状况，在系统发生异常的时候，根据告警信息，按照组织处理原则进行处理；
（2） 技能方面需求：熟悉综合交换设备使用、运行维护的知识，需要接受相关的操作和管理培训。
3.14 培训需求
应该在系统交付后，根据人员需求有针对性地提供培训以及培训材料：
（1） 具体的培训时间通过双方协商后确定，可以在交付产品的同时进行，相关人员可以接受现场指导，也可以在交付设备后另行安排；
（2） 培训材料要求提供必要的纸质、电子档的培训资料；
（3） 参与培训的人员包括公司提供的培训讲师以及客户方的技术维护人员；
（4） 由于人员需求主要是系统维护人员，因此培训的内容以系统管理操作为主，包括以下方面：
1） 日常操作管理：系统日常运行的操作培训，讲解系统操作手册，相关功能配置设法，包括如何进行配置，配置完成后了解软件正常运行状态；日志功能培训，主要是日志的查看方法，通过日志了解系统使用情况；
2） 系统异常处理：告警功能培训，包括告警信息的查看方法，告警的相关处理。
3.15 软件保障需求3.15.1 日志
软件在运行及业务执行中能够产生详细的日志信息，并上报给综合网络管理服务器及终端，以供管理维护人员对设备运行、业务执行情况进行监控跟踪。
3.15.2 软件升级
支持通过综合网络管理服务器及终端、本地shell脚本进行软件升级操作。
3.15.3 版本查询
支持通过综合网络管理服务器及终端、本地shell脚本进行软件版本查询操作。
3.16 “六性”需求3.16.1 可靠性
符合GJB 450A-2004《装备可靠性工作通用要求》的规定，其中：XXXX各软件平均故障间隔时间：MTBF≥XXXXh。
可靠性需求主要包括以下几个方面：
（1） 软件开发：在进行XXXX软件设计时采用成熟、高效的开发环境，采用当前流行的编程语言进行开发，并从标准化、软件的主要功能和用途、软件运行环境等方面综合考虑，提高系统软件设计的可靠性。坚持标准化、通用化、模块化的基本原则，对软件的功能结构进行合理划分；
（2） 软件编码：软件功能的实现尽量采用顺序控制结构、条件控制结构、循环控制结构、分情况控制结构和并行控制结构五种基本结构，尽量避免复杂结构、复杂逻辑和复杂函数的使用，以最简单易行的方式实现软件功能；
（3） 软件测试：测试前需制定测试计划、测试规范，编写测试用例，并对测试文档进行评审，测试过程中要建立完整的测试记录库，置于配置控制下，保证任何错误及对错误的动作都能及时归档可追溯；软件各模块的编制设计者在对自身设计的模块进行自查的基础上，开展各软件模块的互查，排除软件设计中的大部分错误；系统软件上机运行时，通过自检、故障告警、显示、控制等方式对系统功能进行验证，发现问题及时进行修改；开展软件测试和验证工作，主要通过软件模块测试、系统集成测试、系统功能联试、室内指标测试、环境试验等多个阶段多种试验的反复验证进行；
（4） 软件复用：最大限度地重用一体化信息传输系统试验网的成熟软件，采用成熟技术、简化、冗余和模块化等设计。缩短开发周期，提高开发效率，提高软件的可维护性和可靠性。将一些共用的模块、代码封装为库，供各个设备软件共同使用。多使用组件、动态库，减少因库文件的升级而引起的应用软件更新；
（5） 加强软件开发过程管理：采用软件工程思想及标准化的过程管理体系，加强软件开发的各个阶段的管理。软件编码严格执行统一的编码规范。软件研发各个阶段严格按照CMMI体系要求进行；
（6） 软件的容错设计：在软件设计过程中，充分考虑使用环境的严酷性，对软件进行容错设计，极大保证系统可靠性。采用避免故障的防错技术，在软件开发过程中，尽可能避免软件中的缺陷，例如软件正确性验证，使用形式符号及数学归纳潜能等证明算法的正确性。采用软件风险分析与故障树分析，从设计或编码的结构出发，追踪软件开发过程中潜入系统缺陷的原因。采用分布接口要求规格说明，在设计的各阶段使用形式的接口需求规格说明，以验证需求的分布接口实现可能性与完备性。此外还采用冗余思想的容错技术，使软件潜在的差错对可靠性的影响减小到最低程度；
（7） 备份设计：综合交换设备需采用1+n的备份设计，当主用设备故障后，能自动切换到备用设备。
3.16.2 维修性
符合GJB 368B-2009《装备维修性工作通用要求》的规定，其中：
（1） 基层级维修平均修复时间(更换故障单元)MTTR(MCT)≤30min；
（2） 标准化模块化：系统在软件设计上采用标准化、模块化设计便于维护人员后期维护，综合交换设备软件采用IMS的相关标准完成各设备的功能划分，具有开放标准的应用接口以及接入无关等特性，这使得在软件开发中如有新业务的添加只需要移植和添加部分代码，而不需要大幅度的更改系统软件，从而大大减少软件开发量。在设计上，将软件划分为各个独立的组件，各模块研发工作均有一定程度的通用性设计，通过维修组件实现对软件的维修。标准化、模块化的设计增强了系统软件的可移植性和可维护性，有利于简化系统工作业务流程，降低系统开发和维护成本；
（3） 其他维修性需求：软件在使用过程中出现BUG或要求新增功能时，支持快速平滑升级，升级应该考虑方便性和多样性；软件考虑数据的维护功能，包括数据备份和恢复功能；软件遭遇破坏时，系统支持快速重新安装。
3.16.3 测试性
舰载综合业务终端提供操作日志，以便于出现异常情况时定位的用户最后操作。
综合交换设备软件的测试性主要表现在设立观察点、控制点。同时在测试性设计过程中保证不会对系统软件的任何功能产生影响，不能产生附加的活动或者附加的测试，采取合适的设计模式对软件进行设计。在软件设计了采取了以下措施保证软件的可测试性：
（1） 功能性需求：软件能够产生不同级别的日志，便于测试查看定位。软件在使用过程中出现故障时，能够产生告警信息并上报给相应设备。综合交换设备软件能够提供测试帮助信息，便于查看运行数据以及在运行过程中进行交互操作；
（2） 坚持测试驱动设计的方法：优先编写测试代码，在代码编写过程中先写验收测试，再写单元测试，再编写一些测试代码，再实现它们，通过循环的方式推进整个系统软件的设计；在实现阶段捕捉错误并在下一组测试中改正它，以这种方式将会大大提高测试的有效性；
（3） 函数小型化：尽量做到每个操作对应一个函数，使用小型函数说明和重载带缺省参数的函数将使在测试中调用这些函数变的简单得多。否则，在测试这些函数时将不得不构造额外参数，如果参数很大，那么将很快导致代码工作量大大增加；
（4） 可控制性设计：全局变量的可控制性设计：通过适当的手段直接或间接控制该变量，包括获取、修改变量值等；将全局类型的变量进行分类并封装到各个接口中操作；接口的可控制性设计：通过使用测试工具和增加额外代码直接调用对接口进行操作；模块的可控制性设计：对于每个相对独立的模块设计好所需要的驱动能单独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试；
（5） 可测试性调试与定位：对于程序中所涉及到的变量尽可能的在调试过程中可以查询及修改；在整个软件系统执行过程中为每个关键业务或相对独立的业务设定一个调试点，便于系统集成和问题范围的定位；在设定好的调试点处对处理的业务输出数据和全局数据进行可视化输出，便于测试结果的分析；
（6） 稳定性设计：测试模块发布合理，不能在后期追加的模块为前期所测模块引入新的不必要的测试活动；
（7） 输出结果：对于任何一项操作都要能产生预期的输出，不管是正确的还是错误的甚至是异常的。测试结果的表现形式可以是数据、现象等，不管是以什么方式表现，都要有依可寻，在设计文档中要有说明。对于测试结果易于判断，具有可分析性、可获得性。在设置的各个控制点或观察点的结果易于查询、修改等。
3.16.4 安全性
安全性应符合GJB 367A-200l《军用通信设备通用规范》中3.l3和GJB 663-1989《军用通信设备及系统安全要求》的规定。
信息安全满足GB 4943-2001《信息技术设备的安全》和GB 17859-1999《计算机信息系统 安全保护等级划分准则》的规定。
安全性需求主要包括以下几个方面：
（1） 软件需求安全性分析：做软件需求安全性分析需要对分配给软件的系统级安全性需求进行分析，规定软件的安全性需求，保证规定必要的软件安全功能和软件安全完整性。评测人员需要根据软件安全性分析准备的结果和系统的初步结构设计文档，包括系统分配的软件需求、接口需求，完成对系统安全性需求的映射，以安全相关性分析和对软件需求的安全性评价。有了这些积累，评测人员才有把握对软件在系统中的安全性需求做出一个综合性的评价，更好地提交对后续的软件设计和测试的建议；
（2） 软件结构安全性设计：从安全角度讲，软件结构设计是制定软件基本安全性策略的阶段，因为这一阶段负责定义主要软件部件，以及它们如何交互，如何获得所要求的属性，特别是安全完整性，是软件安全性需求在结构定义中实现的阶段。对结构设计进行安全性分析要做到将全部软件安全性需求综合到软件的体系结构设计中，确定结构中与安全性相关的部分，并评价结构设计的安全性。软件结构设计是开发人员对系统期望功能和功能实现方式的表示方法，但是沟通的一致性，和设计的合理性，通常会影响到安全完整性，这里可以借助一些技术来验证：用动画/仿真技术证实功能的实现状态；借助接口分析技术分析安全相关部件与其他部件的相互依赖关系和独立性等等；
（3） 软件详细设计安全性设计：软件详细设计进一步细化高层的体系结构设计，将软件结构中的主要部件划分为独立编码、编译和测试的软件单元，并进行软件单元的设计。在这一阶段中，需要依据软件需求、结构设计描述、软件集成测试计划和之前所获得的软件安全性分析的结果，对软件的设计和实现阶段是否符合软件安全性需求进行验证。相关软件单元应进一步细化设计以便于编码；
（4） 软件编码安全性设计：软件编码完成软件详细设计的实现。所以，代码应该体现软件详细设计所提出的设计要求，实现设计过程中开发的安全性设计特征和方法，遵循设计过程中提出的各种约束以及编码标准。一般采用代码走查或采用静态检查工具来检查源代码，依照软件编码安全性分析对代码的要求，应该主要从以下几个方面入手：
1） 分析软件代码是否能追溯到需求；
2） 分析软件代码是否符合支持工具和编程语言分析；
3） 分析软件代码是否满足模块化、可验证、易安全修改的要求；
4） 分析软件编码中所使用技术的安全性和方法的合理性。
（5） 软件测试安全性设计：软件测试作为验证软件功能性和安全性的重要手段，其采用的测试方法和测试技术也完全关系着测试结果的准确性，关系着后续软件的变更和测试的有效性。软件测试安全性分析既包括事前分析，又包括对测试结果的评价，所以一般从不同角度进行按步骤的测试，包括分析测试集中的所有测试用例，测试是否通过测试准则；测试代码是否按照要求分析，并达到相应的测试覆盖率；测试覆盖是指检查代码的每一个状态和路径；对测试结果进行分析，以验证所有的安全性需求是否得到了满足；
（6） 系统级安全：如访问IP段的限制，登录时间段的限制，连接数的限制，特定时间段内登录次数的限制等；
（7） 接入安全：接入安全指在用户或设备接入时进行安全控制，用户接入时需要通过密码进行验证；在登录后为了避免用户长时间不操作而导致的安全问题，系统提供重注册功能，还需要用户重新登录；
（8） 程序资源访问控制安全：对程序资源的访问进行安全控制，在客户端上，为用户提供和其权限相关的用户界面，仅出现与其权限相符的菜单，操作按钮，做到用户不可访问的资源对用户不可见；在服务端则对用户对程序资源的访问进行控制，如用户强行访问，可回复拒绝消息，必要时，可产生告警信息；
（9） 功能性安全：功能性安全会对程序流程产生影响，如用户在操作业务记录时，是否需要审核，上传附件不能超过指定大小，根据用户的签约信息来对用户执行的操做进行控制。这些安全限制已经不是入口级的限制，而是程序流程内的限制，在一定程度上影响程序流程的运行；
（10） 数据域安全：数据域安全包括两个层次，其一是行级数据域安全，即用户可以访问哪些业务记录，一般以用户所在单位为条件进行过滤；其二是字段级数据域安全，即用户可以访问业务记录的哪些字段。
3.16.5 保障性
符合GJB 367A-2001《军用通信设备通用规范》中3.9、GJB 3872-1999《装备综合保障通用要求》的要求。
保障性需求主要包括以下几个方面：
（1） 技术资料保障：系统出厂时随机配备了完备的资料，包括使用与维修中所需的所有技术资料，技术资料充分反映装备的技术状态和使用与维修的具有要求，确保技术资料的准确、清晰；
（2） 人力资源保障：系统运行后，若出现故障，能及时提供技术保障人员进行问题定位解决，若第一时间无法解决，能够及时派遣技术人员进行现场解决。非严重问题，能通过电话方式进行解决；若出现严重问题，能够及时派遣工程客服人员现场解决；工程新建时，能够派遣相关人员到现场实施解决；
（3） 培训资源保障需求：本系统在交付用户使用时，配备有操作培训多媒体教材，并在使用现场对操作维修人员进行上岗前培训，保证使用人员会用，能用好本系统；维修人员会判断故障部位，并能修理较常见的故障。
3.16.6 环境适应性
符合GJB367A-2001《军用通信设备通用规范》和GJB 4239－2001 《装备环境工程通用要求》的规定。
环境适应性需求主要包括以下几个方面：
（1） 对环境因素的监控：软交换综合系统软件设备是整个系统的核心，任何恶劣环境因素对系统的稳定运行来说都是非常严峻的考验，因此在软件设计的阶段，就应该将整个环境的监控方法考虑到软件设计当中，比如监控环境的温度功能；
（2） 对设备功能的控制：在系统运行的设计中除了监测恶劣环境功能需要考虑之外，还可以通过设计一些功能来减小恶劣环境所带来的影响，比如通过控制风扇运转来减小温度过高对系统的影响；
（3） 根据标准进行设计的需求：在系统设计阶段应该根据有关标准、手册和工程经验制定环境适用性设计准则。在设计过程中，根据环境适用性要求，参考相关环境适用性设计手册，采用合适的技术和方法使设备达到规定的环境适用性水平，尽可能采用成熟的环境适用性技术，适当的设计余量。
3.17 系统开发环境3.17.1 硬件环境
软件产品开发环境中使用的硬件项如下表：
表 3 5 硬件环境项一览表
序号
硬件项名称
硬件配置
备注
1.
2.
3.
4.
5.
3.17.2 软件环境
软件产品开发环境中使用的软件项如下表：
表 3 6 软件环境项一览表
序号
软件项名称
软件版本
备注
1.
2.
3.
4.
5.
6.
5.
6.
7.
8.
3.18 标准需求
表 3 7 标准需求
序号
标准需求名称/标识
具体要求
优先级
备注
1.
2.
3.
4.
5.
3.19 软件交付需求
表 3 8 软件交付清单
序号
交付物名称
交付形式
1.
2.
3.
4.
5.
6.
7.
4 合格性判定
表 4 1 系统软件需求合格性判定表
序号
需求名称
标识
本文档
章节号
合格性方法
测试类
合格性级别
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
注：
（1） 合格性方法：A-演示，B-测试，C-分析，D-审查，E-特殊方法（如：专用工具，技术，过程，设施，验收限制）；
（2） 测试类：1-代码审查，2-静态测试，3-功能测试，4-覆盖测试，5-性能测试，6-容错性测试，7-接口测试，8-内存缺陷测试，9-安装测试，10-段测试；
（3） 合格性级别：a-单元，b-配置项，c-集成，d-系统；
（4） 针对每个user case的合格性规定可以是上述三大项中的多个选项的组合。
5 需求可追踪性
上级文档：XXXX研制方案。
表 5 1 系统软件需求跟踪表
序号
上级文档章节
上级被追踪内容
本文档中被追踪内容
本文档中标识
备注
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
6 附件
无
标签： #c语言的概要设计
