系统子系统需求规格说明(SSS)
16 软件测试说明
《软件测试说明》的正文格式《软件测试说明》(STD)描述执行计算机软件配置项(CSCI)、软件系统或子系统合格性测试所需的测试准备、测试用例及测试过程。
需方根据STD能够评估所执行的合格性测试是否充分。
《软件测试说明》的正文格式1 范围1.1 标识本条应描述本文档所适用系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。
1.2系统概述本条应概述本文档所适用系统和软件的用途。
它还应描述系统与软件的一般特性；概述系统开发、运行和维护的历史；标识项目的需方、用户、开发方和保障机构等；标识当前和计划的运行现场；列出其他有关文档。
1.3文档概述本条应概述本文档的用途和内容，并描述与它的使用有关的保密性方面的要求。
2引用文档本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识不能通过正常采购活动得到的文档的来源。
3测试准备本章应分为以下几条。
适用时应包括用“警告”或“注意”所标志的安全提示，以及保密性考虑。
3．X（测试的项目唯一的标识符）3．X．1 硬件准备本条应描述测试工作所需的硬件准备规程。
有关这些规程，可以引用已发布的操作手册。
（若适用）应提供以下内容：a) 用名称和（若适用）编号标识要使用的特定硬件；b) 任何开关装置和用于连接硬件的电缆：c) 说明硬件、互联控制和数据路径的一个或多个图示；d) 使硬件处于就绪状态的分步的操作说明。
3．X．2软件准备本条应描述准备被测项、相关软件以及测试数据的必要规程。
有关这些规程，可以引用已发布的软件手册。
（若适用）应提供下述信息：a) 测试中要使用的特定软件；b) 测试项的存储介质（如磁带、磁盘）；c) 任何相关软件（如模拟器、测试驱动程序、数据库）的存储介质；d) 加载软件的说明，包括所需的顺序；e) 多个测试用例共同使用的软件初始化说明。
3．X．3其他测试前准备本条应描述进行测试前所需的其他人员活动、准备工作或规程。
634测试说明本章应分为以下几条。
系统子系统需求规格说明（SSS）
系统子系统需求规格说明（SSS）系统/子系统需求规格说明(SSS)说明：1.《系统/子系统需求规格说明》(SSS)为一个系统或子系统指定需求和指定保证每个需求得到满足所使用的方法。
与系统或子系统外部接口相关的需求可在SSS中或在该SSS引用到的一个或多个《接口需求规格说明》(IRS)中给出。
2.这个SSS，可能还要用《接口需求规格说明》(IRS)加以补充，是构成系统或子系统设计与合格性测试的基础。
贯穿本文的术语“系统”，如果适用的话，也可解释为“子系统”。
所形成的文档应冠名为“系统需求规格说明”或“子系统需求规格说明”。
系统/子系统需求规格说明的正文的格式如下：1引言本章分为以下几条。
1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。
1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、操作和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划中的运行现场；列出其他有关的文档。
1.3文档概述本条应概括本文档的用途和内容，并描述与其使用有关的保密性和私密性要求。
2引用文件本章应列出本文档所引用所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。
3需求本章分条详述系统需求，是指功能、业务(包括接口、资源、性能、可靠性、安全性、保密性等)和数据需求。
也就是，构成系统验收条件的系统特性。
给每个需求指定项目唯一标识符以支持测试和可追踪性。
并以一种可以定义客观测试的方式来陈述需求。
对每个需求都应说明相关合格性方法(见第4章)，如果是子系统，则还要给出从该需求至系统需求的可追踪性(见5.a条)。
描述的详细程度遵循以下规则：应包含构成系统验收条件的那些系统特性，需方愿意推迟到设计时留给开发方说明的那些特性。
如果在给定条中没有需求可说明的话，应如实陈述。
8接口需求规格说明(IRS)
身高体重分析接口需求规格说明(IRS)组员：说明：1.《接口需求规格说明》(IRS)描述为实现一个或多个系统、子系统、硬件配置项HWCI,计算机软件配置项CSCI、手工操作、其他系统部件之间的一个或多个接口，而强加在这些实体上的需求。
2.这个IRS,还可以被用来补充《系统/子系统需求规格说明》(SSS)及《软件需求规格说明》(SRS)，作为系统和CSCI设计与合格性测试的基础。
I目录接口需求规格说明(IRS) (1)1引言 (3)1.1标识 (3)1.2系统概述 (3)1.3文档概述 (3)2引用文件 (3)3需求 (4)3.1接口标识和接口图 (4)4合格性规定 (4)5需求可追踪性 (5)6注解 (5)附录 (5)1引言1.1标识标题：身高体重分析软件版本号：1.0用户接口：简述用户操作和反馈结果；外部接口：简述硬件输入输出、网络传输协议；内部接口：简述模块间传值、数据传递。
1.2系统概述一套针对身高体重测试的分析软件，所有人都能使用，它包括了检测体型是否正常，个人身高所对应的标准体重，预测未来身高以及最合适的伴侣体型。
需求方：健身中心，减肥中心等开发者：计算机团队小组用户：所有人均可使用原有系统只能依靠输入身高体重来测试自己体型是否正常。
现有系统可以通过测试身高体型比例来提出合理的饮食建议，此外还实现了许多额外功能来使软件功能更加丰富，更受使用者青睐。
1.3文档概述《接口需求规格说明》(IRS)描述为实现一个或多个系统、子系统、硬件配置项HWCI,计算机软件配置项CSCI、手工操作、其他系统部件之间的一个或多个接口，而强加在这些实体上的需求。
这个IRS,还可以被用来补充《系统/子系统需求规格说明》(SSS)及《软件需求规格说明》(SRS)，作为系统和CSCI设计与合格性测试的基础。
本文档的阅读对象如下：1、开发人员2、测试阶段人员3、对本文档进行评审的人员或机构4、项目组及其他有权需要调用本文档的人员2引用文件《软件工程》第二版——高等教育出版社《软件工程导论》第五版——清华大学出版社《计算机软件文档编制规范》GB-T8567-20063需求3.1接口标识和接口图用户接口：用户可以输入数据并进行体型是否标准测算、根据身高计算标准体重、预测未来身高、预测伴侣身高体重，显示器对结果进行输出。
华为开发文档
软件开发及文档培训(仅供内部使用)深圳市华为技术有限公司版权所有侵权必究1 软件开发过程介绍华为公司的软件开发过程基本上由以下几个开发过程组成: ∙系统需求分析过程∙系统设计过程∙软件需求分析过程∙软件概要设计过程∙软件详细设计过程∙软件编码和单元测试过程∙软件集成与集成测试过程∙系统集成和系统集成测试过程∙系统验收测试过程∙软件维护过程图一. 软件开发相关的过程示意图：各软件开发过程中应该输出的文档如下2. 软件开发过程详细要求2.1系统需求分析开发者应该根据以下要求参与系统需求分析。
注：如果一个系统分成多个版本开发，可能直到最后一个版本需求才能完全定义。
开发者的计划中应该定义在每个版本中确定的需求子集，每个版本中实现的需求子集。
某个版本的需求分析应该理解为定义那个版本的系统需求。
2.1.1 分析用户的输入开发者应该通过分析用户的输入来理解用户的需求。
这个输入的形式可能是需求报告单、调查、问题/修改报告，原型的反馈，访谈或其他用户或反馈。
2.1.2 操作概念开发者应该参与定义和记录系统的操作概念。
结果应该包括在《操作概念描述（OCD）》文档模板中的所有条目。
2.1.3 系统需求开发者应该参与定义和记录系统应该满足的需求以及验证每个需求已经被满足的方法。
结果应在包括《系统/子系统规格说明书（SSS）》中的所有可能的条目。
根据实际情况，有关系统接口的需求可以在SSS中规定或者在《接口需求规格说明书（IRSs）》中规定。
注：如果一个系统由子系统组成，系统需求分析）中的活动应该同系统设计中的活动叠代进行。
定义系统的需求，设计系统并定义它的子系统，定义这些子系统的需求，设计子系统并定义他们的部件，如此下去。
2.2系统的设计开发者应该按照下列要求参与系统的设计。
注：如果系统分成多个版本开发，系统的设计可能要等到最后一个版本才完成。
开发者的计划中应该定义每个版本中所要完成的设计。
一个特定版本的设计应理解为那个版本中应完成的设计内容。
XX项目XX子系统需求规格说明书模板
密级：内控XX项目XX子系统需求规格说明书公司名称2020年01月09日公司名称版本记录深圳航天智慧城市系统技术研究院有限公司目录1前言 (1)1.1编写目的[保持一致，无需改动] (1)1.2项目背景[单一项目保持一致] (1)1.3术语定义[根据各子系统定义确定需要的解释术语] (1)1.4参考资料[子系统设计参考资料，全部列出] (1)2任务概述 (2)2.1目标[该子系统需求规格编写目标] (2)2.2运行环境[系统运行环境，下面内容参考] (2)2.3条件与限制[子系统开发的条件与限制，没有写无] (2)3数据描述 (3)3.1静态数据[子系统开发所需静态数据，没有写无；格式不限，说清楚即可] (3)3.2动态数据[子系统运行产生的动态数据，没有写无；格式不限，说清楚即可] (3)3.3数据库介绍 (3)3.4数据词典[系统开发所需数据字典] (3)3.5数据采集[感知设备采集相关数据] (3)4功能需求 (4)4.1功能1 (4)4.1.1子功能1 (4)5性能需求 (5)5.1数据精确度[子系统数据精度要求] (5)5.2时间特性[如响应时间、更新处理时间、数据转换与传输时间、运行时间等] (5)5.3适应性[在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力]56运行需求 (6)6.1用户界面[如屏幕格式、报表格式、菜单格式、输入输出时间等] (6)6.2硬件接口[与硬件直接通讯接口，一般写无。
] (6)6.3软件接口 (6)6.4故障处理[常发生故障处理机制，没有写无] (6)公司名称7运行需求 (7)深圳航天智慧城市系统技术研究院有限公司1前言1.1编写目的[保持一致，无需改动]该文档的主要目的是为后续的UI设计、系统研发、系统测试提供依据。
1.2项目背景[单一项目保持一致]项目背景介绍。
1.3术语定义[根据各子系统定义确定需要的解释术语]●终端：中控显示屏及主机设备。
A 08 - 接口需求规格说明(IRS)
接口需求规格说明(IRS)说明：1.《接口需求规格说明》(IRS)描述为实现一个或多个系统、子系统、硬件配置项HWCI,计算机软件配置项CSCI、手工操作、其他系统部件之间的一个或多个接口，而强加在这些实体上的需求。
2.这个IRS,还可以被用来补充《系统/子系统需求规格说明》(SSS)及《软件需求规格说明》(SRS)，作为系统和CSCI设计与合格性测试的基础。
目录接口需求规格说明(IRS) (1)1 引言 (3)1.1 标识 (3)1.2 系统概述 (3)1.3 文档概述 (3)2 引用文件 (3)3 需求 (3)3.1 接口标识和接口图 (4)3.x(接口的项目唯一标识符) (4)4 合格性规定 (5)5 需求可追踪性 (6)6 注解 (6)附录 (6)1引言1.1标识本条应包含本文档适用的系统接口实体和接口的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。
1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。
1.3文档概述本条应概述本文档的用途和内容，并描述本文档使用过程中有关保密性或私密性要求。
2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。
3需求本章应分以下几条详细说明为实现一个或多个系统、子系统、配置项、手工操作、其他系统部件之间的一个或多个接口而强加在这些实体上的需求。
应为每个需求指定一个项目唯一标识符以支持测试和可追踪性，并且应以一种可以定义客观测试的方式来陈述需求。
如果每个需求有关的合格性方法(见第4章)和对系统(或子系统)需求的可追踪性(见5.a条)在相应的章中没有提供的话，则应在此进行注解。
描述的详细程度应遵循以下规则：包含作为接口实体的验收条件的那些接口实体特性；需方愿意推迟到设计时留给开发方处理的那些接口实体特性。
GJBA军用软件开发通用要求
开发方应标识和评价为满足合同要求而使用的可重用软件产品； 只要切实可行，就应该采用满足准则的可重用软件产品；
开发可重用软件产品
合同期间，开发方应评估开发可重用软件产品的可行性、成本及可能产生的效益，并向 需方说明费效比且与项目目标相一致的情况
合同中也可以按要求开发专门开发可重用软件产品
• 与软件独立验证和确认机构 联系
• 与相关开发方协调 • 项目过程改进
详细要求
5.1---概述
软件开发过程包括5.2~5.27规定的26项活动，描述顺序并不表示活动执行 的顺序，活动执行顺序依赖于所选择的生存周期模型；
要求开发方参与软件所在系统层面的活动；
项目策划和监管
5.2.1---软件开发策划
在合同期内，开发方应维护软件开发资料库。
软件开发环境建立
5.3.3---软件开发文件
开发方应为每个软件单元和每个CSCI建立、控制并维护软件开发文件；
开发方应将有关软件开发的信息记录在相应的SDF 中，并应在合同期内维 护这些软件开发文件（SDF）。
软件开发环境建立
5.3.4---非交付软件
项目策划和监管
5.2.4---软件安装策划
开发方应制定在合同规定的用户现场进行软件安装和培训的计划。该计划 应包括GJB 438B-2009中软件安装计划规定的全部适用项。
项目策划和监管
5.2.5---软件移交策划
开发方应指明保障机构为完成合同规定的保障工作所需的全部软件开发资 源；
开发方应制定软件移交计划，以标识这些资源并说明向保障机构移交应交 付项目所遵循的方法；
决策理由应包括所考虑的折中情况、分析方法和决策所用的准则； 这些理由应记录在文档、代码注释或其他将移交给保障机构的媒体中； “重要决策” 的含意应在软件开发计划中加以描述，作出这些决策的理由
系统(子系统)设计(结构设计)说明(SSDD)
网上书店系统/子系统设计(结构设计)说明(SSDD)组员：说明：1.《系统/子系统设计(结构设计)说明》(SSDD)描述了系统或子系统的系统级或子系统级设计与体系结构设计。
SSDD可能还要用《接口设计说明》(IDD)和《数据库(顶层)设计说明》(DBDD)加以补充。
2.SSDD连同相关的IDD和DBDD是构成进一步系统实现的基础。
贯穿本文的术语“系统”如果适用的话，也可解释为“子系统”。
所形成的文档应冠名为“系统设计说明”或“子系统设计说明”。
目录系统/子系统设计(结构设计)说明(SSDD) (1)1引言 (4)1.1标识 (4)1.2系统概述 (4)1.3文档概述 (4)1.4基线 (4)2引用文件 (5)3系统级设计决策 (4)4系统体系结构设计 (6)4.1系统总体设计 (6)4.1.1概述 (6)4.1.2设计思想 (7)4.1.3基本处理流程 (8)4.1.4系统体系结构 (6)4.1.5功能需求与系统配置项的关系 (12)4.1.6人工处理过程 (13)4.2系统部件 (7)4.3执行概念 (13)4.4接口设计 (13)4.4.1接口标识和图表................................................................................. 错误!未定义书签。
5运行设计 (7)5.1系统初始化 (7)5.2运行控制 (8)5.3运行结束 (8)6系统出错处理设计 (15)6.1出错信息 (16)6.2补救措施 (16)7系统维护设计 (16)7.1检测点的设计 (16)7.2检测专用模块的设计 (9)8尚待解决的问题 (9)9需求的可追踪性 (9)10注解 (9)附录 (9)1引言1.1标识适用系统：所有可以连接因特网的系统标题：网上书店版本号：1.01.2系统概述本系统应该具有对图书信息的管理以及对用户信息的管理以及存储功能，并能够保存用户账号信息、购买信息等。
接口需求规格说明(IRS)
接口需求规格说明(IRS)说明：1.《接口需求规格说明》(IRS)描述为实现一个或多个系统、子系统、硬件配置项HWCI,计算机软件配置项CSCI、手工操作、其他系统部件之间的一个或多个接口，而强加在这些实体上的需求。
2.这个IRS,还可以被用来补充《系统/子系统需求规格说明》(SSS)及《软件需求规格说明》(SRS)，作为系统和CSCI设计与合格性测试的基础。
接口需求规格说明的正文的格式如下：1引言本章分为以下几条。
标识本条应包含本文档适用的系统接口实体和接口的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。
系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。
文档概述本条应概述本文档的用途和内容，并描述本文档使用过程中有关保密性或私密性要求。
2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。
3需求本章应分以下几条详细说明为实现一个或多个系统、子系统、配置项、手工操作、其他系统部件之间的一个或多个接口而强加在这些实体上的需求。
应为每个需求指定一个项目唯一标识符以支持测试和可追踪性，并且应以一种可以定义客观测试的方式来陈述需求。
如果每个需求有关的合格性方法(见第4章)和对系统(或子系统)需求的可追踪性(见条)在相应的章中没有提供的话，则应在此进行注解。
描述的详细程度应遵循以下规则：包含作为接口实体的验收条件的那些接口实体特性；需方愿意推迟到设计时留给开发方处理的那些接口实体特性。
如果某个需求在多条中出现，可以只陈述一次，而在其他条中加以引用。
如果本说明中的接口实体要在彼此有着不同接口需求的状态和/或方式下运行的话，则该实体的每个需求或每组需求应与那些状态和方式相关联，该关联可以在本条或本条引用的附录中用表格或其他方法给出；也可以在需求出现的地方加以注解。
系统需求规格说明范本
系统需求规格说明范本一、引言系统需求规格说明是对于待开发或待改进的系统所需功能和性能的详细描述。
本文档旨在为系统开发团队提供一个详尽的系统需求指南，以便开发人员能够准确理解和实施系统的功能和性能要求。
二、总体描述2.1 需求背景描述系统的背景信息和目标，确保开发人员对系统的整体需求有一个全面的理解。
2.2 规范范围界定系统需求规格说明的适用范围和限制条件，确保开发人员不会超出规定范围进行开发。
2.3 系统功能详细列出系统所包含的功能模块，并对每个功能模块进行描述，确保开发人员能够清晰理解每个功能模块的具体要求。
2.4 系统性能定义系统的性能要求，包括响应时间、处理能力等指标，以确保最终的系统能够满足用户的需求。
三、功能需求在本节中，将详细描述系统的功能需求，按照模块或者子系统进行组织。
3.1 模块A详细描述模块A的功能需求，包括输入、处理和输出要求，以及与其他模块的交互需求。
3.2 模块B详细描述模块B的功能需求，同样包括输入、处理和输出要求，以及与其他模块的交互需求。
...四、性能需求在本节中，将详细描述系统的性能需求，包括响应时间、处理能力等指标。
4.1 响应时间描述系统各个功能模块的响应时间要求，确保系统能够在指定的时间范围内响应用户的请求。
4.2 处理能力定义系统的处理能力要求，包括每秒事务数、并发用户数等指标，以确保系统能够处理大量用户请求。
...五、其他需求在本节中，将描述系统的其他非功能性需求，如安全性、可靠性、可用性等。
5.1 安全性要求描述系统对于数据的安全性要求，包括用户身份验证、数据加密等措施。
5.2 可靠性要求定义系统的可靠性要求，确保系统能够持续稳定地运行，不出现故障和意外崩溃。
5.3 可用性要求描述系统对于用户的可用性要求，包括界面友好、易于操作等方面的要求。
...六、附录在本节中，可以提供一些进一步的说明和文档支持，以帮助开发人员更好地理解和实施系统需求规格说明。
七、术语表列出本文档中使用的专业术语和缩写词的解释，以便开发人员和用户都能够理解。
软件设计和开发控制程序
软件设计和开发控制程序软件设计和开发控制程序1 ⽬的和范围本程序规定了公司军⽤软件设计开发的要求，包括软件来发的基本活动、⽀持活动和管理活动等⽅⾯。
本程序适⽤于本公司军⽤软件设计开发过程。
公司军⽤软件分两类，⼀类属于硬件-软件系统，软件嵌⼊硬件内⼀并交付顾客。
对于这类情况，本程序只适⽤于其中的软件部分；⼀类是单纯软件作为产品交付顾客，本程序适⽤这类产品设计开发全过程。
2规范性引⽤⽂件下列⽂件对于本程序的应⽤是必不可少的。
凡是注⽇期的引⽤⽂件，仅注⽇期的版本适⽤于本程序。
凡是不注⽇期的引⽤⽂件，其最新版本（包括所有的修改单）适⽤于本程序。
GB/T19001-2016 质量管理体系要求GJB 9001C-2017 质量管理体系要求GJB 2786A-2009 军⽤软件开发通⽤要求GJB438B-2009 军⽤软件开发⽂档通⽤要求GJB5235-2004 军⽤软件配置管理GJB 439A-2013 军⽤软件质量保证通⽤要求GJB5234 -2004 军⽤软件验证和确认GJB1267 -1991 军⽤软件维护GJB1268A -2004 军⽤软件验收要求GJB5716 -2006 军⽤软件开发库、受控库、产品库通⽤要求3 术语和缩略语3.1 术语3.1.1 新产品产品功能指标超出现有技术⽔平，⼯艺设备⽆法保障研制条件，必须采⽤新技术、新⼯艺、新器件（材料）、新设备才能满⾜⽤户要求的产品定义为新产品。
新产品含军队、军⼯单位⽴项委托研制项⽬以及公司⾃筹经费的⾃研项⽬。
3.1.2 软件与计算机系统的操作有关的计算机程序、规程和可能相关的⽂档。
3.1.3 软件开发产⽣软件产品的⼀组活动。
3.1.4 软件开发⽂件与特定软件开发有关的资料库。
其内容⼀般包括（直接或通过引⽤）有关需求分析、设计和实现的考虑、理由和约束条件；开发⽅内部的测试信息；以及进度和状态信息。
3.1.5 软件产品作为定义、维护或实施软件过程的⼀部分⽽⽣成的任何制品，包括过程说明、计划、规程、计算机程序和相关⽂档等，⽆论是否打算将它们交付给顾客或最终⽤户。
计算机软件常见英文缩写及对应全称
1 CASE 计算机辅助软件工程(Computer Assistant Software Engineering)
2 COM 计算机操作手册(Computer Operation Manual)
3 CPM 计算机编程手册(Computer Programming Manual)
4 CSCI 计算机软件配置项(Computer Software Configuration Item)
5 DBDD 数据库(顶层)设计说明(Database Design Description)
6 DID 资料条目说明(Data Item Description)
7 DPMR 开发进度月报(Development Plan Month Report)
26 SQA 软件质量保证(Software Quality Assure)
27 SQAP 软件质量保证计划(Software Quality Assure Plan)
28 SRS 软件需求规格说明(Software Requirement SpeciSystem Subsystem Design Description)
22 SDL 软件开发库(Software Development Library)
23 SDP 软件开发计划(Software Development Plan)
24 SIP 软件安装计划(Software Installation Plan)
25 SPS 软件产品规格说明(Software Product Specification)
18 SCMP 软件配置管理计划(Software Configuration Manager Plan)
软件开发中常见的一些缩写及含意
（一）软件开发中常见的一些缩写及含意AAI Action Item活动项 CCA Comprehensive Audit综合检查CCB Configuration Control Board配置控制部CDR Critical Design Review关键设计评审CD&UT Coding and Unit Testing phase编码与单元测试阶段CMM Capability Maturity Model成熟度模型CRLCMP Computer Resource Life Cycle Management Plan计算机资源生命周期管理计划CSCI Computer Software Configuration Item计算机软件配置项critical software 重要软件DDBDD Data Base Design Description数据库设计描述DCR Document Change Request文档更改请求DD Detailed Design Phase详细设计阶段DDD Detailed Design Document详细设计文档DDR Detailed Design Review详细设计评审DID Data Item Description数据项描述design level 设计层FFCA Functional Configuration Audit功能配置审查FA Functional Audit功能检查FI Formal Inspection正式检查FQR Formal Qualification Review正式鉴定评审HHB HandBook手册HWCI HardWare Configuration Item硬件配置项IIDD Interface Design Description接口设计描述IRS Interface Requirements Specification接口需求规格说明IT&ST Integrating and System Testing phase组装与系统测试阶段IS&AC Installation and Acceptance phase安装与验收阶段IV&V Independent Verification and Validation 独立验证与确认KKPA Key Process Area关键过程域Mmanagement reviews 管理评审NNDS Non-Developmental Software不可开发软件PPA Physical Audit物理检查PCA Physical Configuration Audit物理配置审查PD Preliminary Design Phase概要设计阶段PDD Preliminary Design Document概要设计文档PDR Preliminary Design Review初步设计评审（概要设计评审）PDS 项目开发总结PIP 项目实施计划PRR 阶段评审报表PRR Product Readiness Review产品准备就绪评审PP&O Project Planning and Oversight项目计划与监督PPP 项目进展报表Pass criteria 通过准则project entrust organization 项目委托单位project undertaking organization 项目承办单位Qquality assurance 质量保证QC QUALITY CONTROL 品质控制RRA Requirements Analysis Phase需求分析阶段RMT 评审成员签字表RPL Review Problem评审问题记RSR Review Summary Report评审总结报告SSA&SD System Analysis and software definition phase系统分析与软件定义阶段SCL 源程序清单SCM Software Configuration Management软件配置管理SCMP Software Configuration Management Plan软件配置管理计划SDD Software Design Document软件设计文档（分成概要设计说明书[PDD]和详细设计说明书[DDD]）SDF Software Development File软件开发文件SDL Software Development Library软件开发库SDP Software Development Plan软件开发计划SDR System Design Review系统设计评审SEI Software Engineering Institute软件工程学会SEPO Software Engineering Process Office软件工程过程办公室SOW Statement of Work工作说明SPR Software Problem Report软件问题报告单SQA Software Quality Assurance软件质量保证SQAP Software Quality Assurance Plan软件质量保证计划SRR 软件需求评审SRR System Requirements Review系统需求评审SRS Software Requirment Specification软件需求规格说明SSDD System/Subsystem Design Description系统/子系统设计描述SSR Software Specification Review软件规格说明评审SSS System/Subsystem Specification系统/子系统规格说明STP 软件测试计划STR 软件测试报告STR Software Trouble Report软件故障报告STSC Software Technoligy Support Center软件技术支持中心SUM 用户手册SVD Software Version Description软件版本描述SV&VP Software Verification and Validation Plan软件验证与确认计划SV&VR Software Verification and Validation Review软件验证与确认评审SW-CMM SoftWare Capability Maturity Model软件成熟度模型software 软件software development organization 软件开发单位software feature 软件特性software item 软件项software life cycle 软件生存周期software verification and validation report软件验证与确认报告TTR Technical Report技术报告TRR Test Readiness Review测试准备就绪评审TSSD Total Software System Development phase整个软件系统的开发阶段testing 测试test item 测试项UUDF Unit Development Folder单元开发文件夹user 用户user documentation 用户文档UT Unit Test 单元测试Vvalidation 确认verification 验证WWBS Work Breakdown Structure工作分解结构。
系统分析说明书(需求规格说明书)
附录2系统分析说明书（需求规格说明书）目录1 概述 (2)1.1编写目的 (2)1.2 参考资料 (2)2 需求 (3)2.1 功能需求 (3)2.2 数据需求 (21)2.3 性能需求 (22)2.4 非功能需求 (23)2.5 故障处理 (23)3 环境 (23)3.1 运行环境 (23)3.2 开发环境 (23)1 概述1.1 编写目的本文档的编写目的是为学校管理信息系统项目的开发提供：a.这个系统主要针对的就是对于学校日常事务的信息系统化，运用计算机技术、信息技术对于学校的日常信息（例如：学生信息、成绩、学分等）或日常数据进行一体化的管理，避免大量的数据冗余，提高数据利用率，提高各部门（特别是教务、财务部门）的工作效率。
对于信息的一体化管理，也方便了学校、学院、教师、学生4级对信息掌握的及时性（学校能及时了解各个学院的教学情况，教师能有针对性地对学生进行授课，学生也可以根据评定系统自查自纠）。
从纸张化到计算机化，学校关心的数据也更有了保障，也方便了查询，加强了对于学校教学水平的监督。
b.本系统的功能要求主要分成了3个方面（详见c）。
对于录入、查询、计算的要求都比较高（用户主要关心最终数据：GPA、学分、综合测评、工资信息）。
对于这么多的数据查询和报表的生成，就要求有一个强大的数据处理终端（主要表现在控制类的计算能力和数据库的性能）。
c.本系统主要是针对于学校信息管理的3大块，即学生信息管理、教师信息管理、科研管理(用户要求实现功能如下)1)学生信息管理模块a)对学生、课程、成绩等信息进行管理b)实现综合测评的功能c)对留级、退学的情况进行管理d)产生学生成绩表2)教师信息管理模块a)对教师、部门、教学等信息进行管理b)对教师教学任务进行登记，按照算法计算工作量c)对教师进行年终考核，记录考核成绩d)对教师的教学情况进行测评，记录测评结果e)根据教务处提供的教师工作量计算奖金，产生月工资f)按个人、部门产生月工资报表和查询3)科研管理模块a)对科研项目信息进行维护b)记录项目经费的支出情况c)登记项目的获奖情况d)登记学术论文和著作并完成相应的查询e)对科研按部门项目进行汇总，形成部门的总经费、支出经费、结余经费，并可打印。
系统需求规格说明书
XXX系统或XXX项目产品需求规格说明书版本信息注：状态可以为N-新建、A-增加、M-更改、对方的所得税说明：版本信息必须更新，审核人和审核时间也必须审核后填写，审核人要求部门经理级别以上。
否则开发测试可拒绝评审。
审核业务功能是否有遗漏、业务流程是否符合规划、关键业务逻辑是否有合理目录1.关于本文档 (4)1.1. 内容说明 (4)1.2. 名词解释 (4)1.3. 参考文档 (4)2.系统概述 (5)2.1. 业务背景 (5)2.2. 系统概述 (5)2.3. 流程概览/系统框架 (7)2.4. 系统规划与迭代 (7)2.5. 功能模块 (8)3.系统功能需求 (8)3.1 状态信息接受推送 (8)3.2 最新站点查询服务 (16)4.系统非功能需求 (24)3.3 性能需求 (24)3.4 安全性需求 (25)3.5 扩展性需求 (25)3.6 兼容性需求 (25)3.7 维护性需求 (26)5.附录 (26)1.关于本文档1.1.内容说明说明：此处描述的是文档说明，产品需求文档更新需要走修订模式，下次更新前先接受修订，并且每次更新必须更新版本号和版本记录。
例子：本文档用于描述苏宁开放平台物流状态服务系统的需求定义。
包括各个需求的功能描述，处理逻辑规则，界面定义，与其它功能的关系，与其它系统的接口等各个方面的定义。
是苏宁物流状态服务系统唯一的全面需求定义文档。
本文档将根据需求管理流程和要求，随系统功能变化进行及时的修订和更新，以确保本文档的全面性，准确性和实效性。
因此在阅读使用此文档时，请注意从项目的文档管理系统中获取最新版本。
1.2.名词解释1.3.参考文档《系统需求定义规范使用说明v1.0.doc》2.系统概述2.1.业务背景说明：此处描述业务背景，不可裁剪，清晰的业务背景描述能更好的帮助研发和测试理解产品需求，明确业务测试场景，此部分是产品需求定位的核心导向。
例子一：电子面单的业务描述随着电子商务服务和物流服务信息化飞速发展，包裹运单号成为快递公司串联快递单、订单、商家、商品等各种信息的枢纽。
软件开发文档论文4200字_软件开发文档毕业论文范文模板
软件开发文档论文4200字_软件开发文档毕业论文范文模板软件开发文档论文4200字(一)：基于GJB5000A的雷达系统软件开发文档剪裁方法的研究论文摘要：在军用软件开发中，需要对大量的文档进行剪裁。
为研究满足GJB5000A二级要求，并符合雷达系统软件特点的文档剪裁方法，本文以分类分析的方法将软件开发文档按照用途分成计划、需求、设计、软件测试、手册、清单和总结等7类分别加以分析，提出各类文档的剪裁准则，建立了各类文档的裁剪矩阵。
关键词：GJB5000A；文档剪裁；GJB438B；雷达软件；软件工程化0引言软件开发过程中的文档既是软件设计和开发的重要记录又是软件过程的记录，是软件的重要资料。
编写文档既是软件开发必不可少的过程，也是软件工程化管理的具体体现。
在推行采用GJB5000A模型的软件工程化工作中发现，大量的文档需要编写，往往被软件开发者认为是一件艰难、枯燥的工作，不认可其为软件开发的一部分，而被当成负担。
要让文档对软件开发有所裨益，而不是成为软件开发的累赘或障碍，必须要对软件开发中应编制的文档进行顶层设计。
本文尝试结合雷达系统的特点，将雷达系统软件开发过程中要产生的文档分成了7类分类，对不同类别的文档加以分析。
通过分析，得出适用于雷达系统软件开发的文档剪裁方法，也为其他领域的软件开发文档剪裁提供了参考。
1软件开发文档的分类GJB438B-2009规定了军用软件开发文档的通用要求。
在GJB438B标准中，规定了软件开发中可能产生的28种文档。
这些文档以类似瀑布模型的顺序列出，每种文档都是对软件或软件开发过程某一方面的描述[1]。
雷达系统是一种重要的军用设备，在雷达系统软件的开发过程中产生的文档应按照GJB438B的要求编写。
在推行采用GJB5000A模型的软件工程化工作中，为便于对文档规定的理解和对文档进行剪裁，基于GJB438B-2009标准的要求，将软件开发文档分为7类。
1.1计划类文档正如GJB9001B《质量管理体系要求》所指出的，PDCA(策划-实施-检查-处置)的方法适用于所有过程[2]。
系统子系统需求规格说明(SSS)文档标准模版
系统/子系统需求规格说明(SSS)XXXX公司文件更改记录文件版本变更记录系统/子系统需求规格说明(SSS)说明：1.《系统/子系统需求规格说明》(SSS)为一个系统或子系统指定需求和指定保证每个需求得到满足所使用的方法。
与系统或子系统外部接口相关的需求可在SSS中或在该SSS引用到的一个或多个《接口需求规格说明》(IRS)中给出。
2.这个SSS，可能还要用《接口需求规格说明》(IRS)加以补充，是构成系统或子系统设计与合格性测试的基础。
贯穿本文的术语“系统”，如果适用的话，也可解释为“子系统”。
所形成的文档应冠名为“系统需求规格说明”或“子系统需求规格说明”。
模版说明：1、文档字体设定：标题1：小一标题2：二号标题3：小二标题4：三号标题5：小三标题6：四号正文：四号2、文章编号，请使用格式刷刷，不要手工编号。
目前格式都是对的。
3、内容根据实际情况裁剪，一般可行性研究报告，模版章节不可缺。
4、封面图片请根据实际情况自行替换。
5、关于修订记录，请根据文档需要自行添加。
1.引言本章分为以下几条。
1.1.标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。
1.2.系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、操作和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划中的运行现场；列出其他有关的文档。
1.3.文档概述本条应概括本文档的用途和内容，并描述与其使用有关的保密性和私密性要求。
2.引用文件本章应列出本文档所引用所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。
3.需求本章分条详述系统需求，是指功能、业务(包括接口、资源、性能、可靠性、安全性、保密性等)和数据需求。
也就是，构成系统验收条件的系统特性。
给每个需求指定项目唯一标识符以支持测试和可追踪性。
软件系统分析与设计
1.3.1软件质量模型 和使用质量性、依从性 、安全性 复性 操作性 、稳定性、 可测试性 一致性、可 替换性1.3.2软件质量管理第 1 章 软件工程基础知识1.1 软件工程知识体系软件需求( Software 软件设计( Software 软件构造( Software 软件测试( Software 软件维护( SoftwareRequirements ) Design )Construction ) Testing ) Maintenance )软件配置管理( Software Configuration Management ) 软件工程管理( Software EngineeringManagement ) 软件工程过程( Software Engineering Process )软件工程工具和方法 软件质量( Software( Software Engineering Tools and Methods ) Quality )1.2 软件生存周期与软件开发模型1.2.1 软件生存周期Boehm 定义的软件生存周期模型GB 8566-1988 定义的软件 生存周期 模型GB/T 8566-1995 定义的 软件生存周期过程模型 GB/T 8566-2001 定义的 软件生存周期过程模型 UP 定义的软件生存周期模型1.2.2软件开发模型 瀑布模 型( waterfallmodel )快速原 型模型( rapid prototype model ) 演化模 型( evolutionary model )增量模 型( incremental model )螺旋模 型( spiralmodel )喷泉模 型( water fountain model )1.3 软件质量模型与软件质量管理 软件产 品的内部质量、外部质量 质量特 性、质量子特性和度量 功能性 ：适宜性、准确性、互用 可靠性 ：成熟性、容错性、可恢 可用性 ：可理解性、易学性、可 效率： 时间特性、资源特性 可维护 性：可分析性、可修改性 可移植 性：适应性、易安装性、质量需 求分析质量计 划 质量保 证 质量控 制 质量改 进 软件质 量管理体系1.5.3 软件过程改进 目前状态 ”，找出所有差距 始下一轮改 进1. 6 小 节软件工程学是研究如 软件产品所要经历勺 O至被淘汰这样一个全过 程被称为软件生存周 期。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
系统/子系统需求规格说明(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接口需求说明硬件系统和软件系统之间的接口。
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)项目唯一标识符；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保密性和私密性需求(若有)本条应指明维持保密性和私密性的系统需求，包括：系统运行的保密性/私密性环境、提供的保密性或私密性的类型和程度、系统必须经受的保密性/私密性的风险、减少此类危险所需的安全措施、系统必须遵循的保密性/私密性政策、系统必须提供的保密性/私密性审核以及保密性/私密性必须遵循的确认/认可准则。
3.10操作需求说明本系统在常规操作、特殊操作以及初始化操作和恢复操作等方面的要求。
3.11可使用性、可维护性、可移植性、可靠性和安全性需求说明本系统在可使用性、可维护性、可移植性、可靠性和安全性等方面的要求。
3.12故障处理需求说明本系统在发生可能的软硬件故障时，对故障处理的要求。
3.12.1软件系统出错处理说明属于软件系统的问题；给出发生错误时的错误信息；说明发生错误时可能采取的补救措施。
3.12.2硬件系统冗余措施的说明说明哪些问题可以由硬件设计解决，并提出可采取的冗余措施；对硬件系统采取的冗余措施加以说明。
3.13系统环境需求(若有)本条应指明系统运行必须的与环境有关的需求。
对软件系统而言，运行环境包括支持系统运行的计算机硬件和操作系统(其他有关计算机资源方面的需求在下条描述)。
对硬软件系统而言，运行环境包括系统在运输、存储和操作过程中必须经受的环境条件，如：自然环境条件(风、雨、温度、地理位置)、诱导环境(运动、撞击、噪音、电磁辐射)和对抗环境(爆炸、辐射)。
3.14计算机资源需求本条应分条进行描述。
根据系统性质，在以下各条中所描述的计算机资源应能够组成系统环境(对应软件系统)或系统部件(对应硬软件系统)。
3.14.1计算机硬件需求本条应描述系统使用的或引人到系统中的计算机硬件需求，(若适用)包括：各类设备的数量、处理器、存储器、输入/输出设备、辅助存储器、通信/网络设备、其他所需的设备的类型、大小、能力(容量)及其他所要求的特征。
3.14.2计算机硬件资源利用需求本条应描述系统的计算机硬件资源利用方面的需求，如：最大许可使用的处理器能力、存储器容量、输入/输出设备能力、辅助存储器容量和通信/网络设备能力。