系统/子系统需求规格说明(SSS)
说明：
1.《系统/子系统需求规格说明》(SSS)为一个系统或子系统指定需求和指定保证每个需求得到满足所使用的方法。与系统或子系统外部接口相关的需求可在SSS中或在该SSS引用到的一个或多个《接口需求规格说明》(IRS)中给出。
2.这个SSS，可能还要用《接口需求规格说明》(IRS)加以补充，是构成系统或子系统设计与合格性测试的基础。贯穿本文的术语“系统”，如果适用的话，也可解释为“子系统”。所形成的文档应冠名为“系统需求规格说明”或“子系统需求规格说明”。
目录
系统/子系统需求规格说明(SSS) (1)
1引言 (4)
1.1标识 (4)
1.2系统概述 (4)
1.3文档概述 (4)
2引用文件 (4)
3需求 (4)
3.1要求的状态和方式 (4)
3.2需求概述 (5)
3.2.1系统总体功能和业务结构 (5)
3.2.2硬件系统的需求 (5)
3.2.3软件系统的需求 (5)
3.2.4接口需求 (5)
3.3系统能力需求 (5)
3.4系统外部接口需求 (6)
3.4.1接口标识和接口图 (6)
3.5系统内部接口需求 (7)
3.6系统内部数据需求 (7)
3.7适应性需求 (7)
3.8安全性需求 (8)
3.9保密性和私密性需求 (8)
3.10操作需求 (8)
3.11可使用性、可维护性、可移植性、可靠性和安全性需求 (8)
3.12故障处理需求 (8)
3.12.1软件系统出错处理 (8)
3.12.2硬件系统冗余措施的说明 (8)
3.13系统环境需求 (9)
3.14计算机资源需求 (9)
3.14.1计算机硬件需求 (9)
3.14.2计算机硬件资源利用需求 (9)
3.14.3计算机软件需求 (9)
3.14.4计算机通信需求 (9)
3.15系统质量因素 (10)
3.16设计和构造的约束 (10)
3.17相关人员需求 (10)
3.18相关培训需求 (10)
3.19相关后勤需求 (10)
3.20其他需求 (11)
3.21包装需求 (11)
3.22需求的优先次序和关键程度 (11)
4合格性规定 (11)
5需求可追踪性 (11)
6非技术性需求 (12)
7尚未解决的问题 (12)
8注解 (12)
附录 (12)
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.1
4.1计算机硬件需求
本条应描述系统使用的或引人到系统中的计算机硬件需求，(若适用)包括：各类设备的数量、处理器、存储器、输入/输出设备、辅助存储器、通信/网络设备、其他所需的设备的类型、大小、能力(容量)及其他所要求的特征。
3.1
4.2计算机硬件资源利用需求
本条应描述系统的计算机硬件资源利用方面的需求，如：最大许可使用的处理器能力、存储器容量、输入/输出设备能力、辅助存储器容量和通信/网络设备能力。这些要求(如每个计算机硬件资源能力的百分比)还包括测量资源时所要求具备的条件。
3.1
4.3计算机软件需求
本条应描述系统必须使用或引人系统的计算机软件的需求，例如包括：操作系统、数据库管理系统、通信/网络软件、实用软件、输入和设备模拟器、测试软件和生产用软件。必须提供每个软件项的正确名称、版本和引用文件。
3.1
4.4计算机通信需求
本条应描述系统必须使用的或引人系统的计算机通信方面的需求，例如包括：连接的地理位置、配置和网络拓扑结构、传输技术、数据传输速率、网关、要求的系统使用时间、传送/接收数据的类型和容量、传送/接收/响应的时间限制、数据的峰值和诊断功能。
3.15系统质量因素
(若有)本条应描述系统质量因素方面的需求，例如包括：系统的功能性(实现全部所需功能的能力)、可靠性(产生正确、一致结果的能力……如设备故障的平均间隔时间)、可维护性(易于服务、修改、更正的能力)、可用性(需要时进行访问和操作的能力)、灵活性(易于适应需求变化的能力)、软件可移植性(易于适应新环境变化的能力)、可重用性(在多个应用中使用的能力)、可测试性(易于充分测试的能力)、易用性(易于学习和使用的能力)和其他属性等的定量需求。
3.16设计和构造的约束
(若有)本条应描述约束系统设计和构造的那些需求。对硬软件系统而言，本条应包括强加于系统的物理需求，这些需求可通过引用适当的商用标准和规范来指定。需求包括：
a.特殊系统体系结构的使用或对体系结构方面的需求，例如：需要的子系统；标准部件、现有部件的使用；政府/需方提供的资源(设备、信息、软件)的使用；
b.特殊设计或构造标准的使用；特殊数据标准的使用；特殊编程语言的使用；工艺需求和生产技术；
c.系统的物理特性(如：重量限制、尺寸限制、颜色、保护罩)；部件的可交换性；从一地运输到另一地的能力；由单人或一组人携带或架设的能力；
d.能够使用和不能使用的物品；处理有毒物品的需求以及系统产生电磁辐射的允许范围；
e.铭牌、部件标记、系列号和批次号的标记、其他标识标记的使用；
f.为支持在技术、威胁和任务等方面预期的增长和变化而必须提供的灵活性和可扩展性。
3.17相关人员需求
(若有)本条应描述与使用或支持系统的人员有关的需求，包括人员的数量、技术等级、责任期、培训需求、其他的信息，如：所提供的工作站数量、内在帮助和培训能力的需求八若有)还应包括强加于系统的人力行为工程需求。这些需求包括对人员在能力与局限性方面的考虑；在正常和极端条件
下可预测的人为错误；人为错误造成严重影响的特定区域，例如对高度可调的工作站、错误消息的颜色和持续时间、关键指示器或键的物理位置以及听觉信号的使用需求。
3.18相关培训需求
(若有)本条应描述有关培训方面的系统需求。包括：系统中应包括的培训设备和培训材料。
3.19相关后勤需求
(若有)本条应描述有关后勤方面的系统需求，包括：系统维护、软件支持、系统运输方式、补给系统要求、对现有设施的影响、对现有设备的影响。
3.20其他需求
(若有)本条应描述在以上各条中没有涉及到的其他系统需求，包括在其他合同文件中没有涉及的系统文档的需求，如：规格说明、图表、技术手册、测试计划和测试过程以及安装指导材料。
3.21包装需求
(若有)本条应描述需交付的系统及其部件在包装、加标签和处理方面的需求。(如适用)可引用适当的规范和标准。
3.22需求的优先次序和关键程度
(若适用)本条应给出本规格说明中需求的、表明其相对重要程度的优先顺序、关键程度或赋予的权值，如：标识出那些认为对安全性、保密性或私密性起关键作用的需求，以便进行特殊的处理。如果所有需求具有相同的权值，本条应如实陈述。
4合格性规定
本章定义一组合格性方法，对于第3章中每个需求，指定为了确保需求得到满足所应使用的方法。可以用表格形式表述该信息，也可以在第3章的每个需求中注明要使用的方法。合格性方法包括：
a.演示：依赖于可见的功能操作，直接运行系统或系统的一部分而不需要使用仪器、专用测试设备或进行事后分析。
b.测试：使用仪器或其他专用测试设备运行系统或系统的尸部分，以便采集数据供事后分析使用。
c分析：对从其他合格性方法中获得的积累数据进行处理，例如测试结果的归约、解释或推断。
d.审查：对系统部件、文档等进行可视化检查。
e.特殊的合格性方法。系统的任何特殊合格性方法，如：专用工具、技术、过程、设施、验收限制、标准样例的使用和生成等。
5需求可追踪性
对系统级的规格说明，本章不适用；对子系统级的规格说明，本章应包括：
a.从本规格说明中每个子系统需求到其涉及的系统需求的可追踪性。(该可追踪性也可以通过对第3章中的每个需求进行注释的方法加以描述。)
注：每一层次的系统改进可能导致对更高层次的需求不能直接进行追踪。例如：建立两个子系统的系统体系结构设计可能会产生有关子系统接口的需求，而这些接口需求在系统需求中
并没有被覆盖，这样的需求可以被追踪到诸如“系统实现”这样的一般需求，或被追踪到导致它们产生的系统设计决策上。
b.从分配给被本规格说明所覆盖的子系统的每个系统需求到所涉及的子系统需求的可追踪性。分配给子系统的所有系统需求都应加以说明。追踪到接口需求规格说明(IRS)中所包含的子系统需求时，可引用IRS.
6非技术性需求
本章应包括：
a.交付日期；
b.里程碑点。
7尚未解决的问题
如需要，可说明系统需求中的尚未解决的遗留问题。
8注解
本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档所需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。
附录
附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编排。
软件需求规格说明书 文件编号：QMS—PROC－RD02 版本：1.0 受控签章
修改历史
目录 1引言 (4) 1.1目的 (4) 1.2背景 (4) 1.3术语 (4) 1.4预期读者与阅读建议 (4) 1.5参考资料 (4) 1.6需求描述约定 (5) 2.项目概述 (6) 2.1系统功能 (6) 2.2业务描述 (6) 2.3数据流程描述(可选) (6) 2.4用户的特点 (6) 2.5运行环境要求 (6) 2.6设计和实现上的限制 (6) 3.功能需求的描述 (6) 4.非功能需求 (7) 4.1系统性能要求 (7) 4.2系统安全及保密要求 (7) 4.3系统备份与恢复要求 (7) 4.4系统日志 (7) 5.外部接口说明 (7) 6.其他需求 (8) 7 需求变更识别 (8) 8.功能列表 (8) 9.附件 (8)
1引言 1.1 目的 说明编写这份软件需求规格说明书的目的，如：通过本文档定义ＸＸＸ产品的需求，以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景，包括： a．需开发的软件系统的名称，和英文缩写（可选），项目编号（可选）； b．列出此项目的任务提出者、开发者 c．软件系统应用范围、用户。 d．产生该系统需求的原因或起源，如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者，以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料，如： a．本项目经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d．行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
XX项目 产品需求规格说明书 机构公开信息
版本历史
1.引言 该文档主要包含功能性需求分系以及功能用例图，也包括了一些对用户界面的要求，该系统运行所需环境和产品质量需求。 1.1. 文档目的 该文档重点描述的办公自动化系统的功能需求以及功能用例图，能够供读者更好的了解该系统；其中，非功能需求方面，用户界面要求主要是为了是系统的界面更加统一规范，软硬件环境需求以及产品质量需求是为了保证提供给用户尽量完美的办公自动化系统。 1.2. 文档范围 本文档包含一下几部分： 1. 产品介绍 2. 角色功能划分 3. 产品范围 4. 产品的功能性需求 5. 产品的非功能性需求 1.3. 文档读者对象 该文档适合开发人员、项目经理、用户、文档的编写人员阅读。 1.4. 参考文档 列举了编写软件需求规格说明时所参考的资料或其它资源。 1.5. 术语与缩写解释 2.综合介绍 这一部分概述了正在定义的软件，主要是功能的概要介绍。
1.6. 产品介绍（功能介绍） 该系统包含8各模块：超级管理模块，该模块包括组织管理、权限管理、考试管理、资源共享通讯录和系统管理；我的办公桌模块，主要是对各重点模块的简要显示；行政管理该模块包括公共通知、公共计划、记事本、员工考勤和组织机构；个人助理模块，该模块包括通讯录、短消息、日程安排和个人信息管理；个人邮箱，该模块包括配置邮箱和收发邮件；公共信息模块，该模块包括资源下载、在线考试和公共通讯录；人事管理模块，该模块包括档案管理、档案查询和数据维护；销售管理模块，该模块主要包括客户管理、销售管理和供应商管理。 1.7. 产品范围 OA办公自动化系统集人力资源管理以及进销存等管理于一体的商业企业管理软件系统。本产品是为了帮助企业更好的进行管理，实现办公自动化。该产品适用于所有企业的办公需求。 1.8. 用户介绍 确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关。 1.9. 角色功能划分 XXXXX拥有XXXX功能的权限。 XXXXX拥有XXXX功能的权限。 1.10. 设计和实现上的限制 确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。 1.11. 假设和依赖 列举出在对软件需求规格说明中影响需求陈述的假设因素（与已知因素相对立）。这可能包括你打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定，但是另一个S R S 读者却可能不这样认为。如果这些假设不正确、不一致或被更改，就会使项目受到影响。
数据交换需求规格 说明书
1引言 1.1编写目的 为了能更好的描述清楚《国科政信数据交换平台》（以下简称“数据交换”或“本项目”）业务需求，更好地让相关人员了解本项目的各个模块及功能点，特编写此需求规格说明书。 本文档主要从业务需求、功能描述、环境要求、操作要求、设计约束及质量要求等方面阐述，同时说明了系统的合格性需求及交付需求等综合要求，是作为本项目软件的设计及测试工作的重要依据。 本文档的预期读者为业务用户、设计人员、开发人员、测试人员、项目管理人员等相关人员 1.2背景 当前，国内各地政府部门和机构或多或少均建立起自己的信息化系统，包括门户网站内容管理系统、OA办公系统、办事审批系统、其它业务系统等。但由于诸多因素的影响，即使同一地区的政府机构间也无法进行合理、有效的沟通，能够说是一座座的“信息孤岛”。电子政务实施的任务之一就是要将这些“孤岛”有机地串连在一起，充分发挥其效能，同时也保护了各部门在该方面的经济投入和精力投入。另外，电子政务建设过程中，即使是统一规划，但具体的实施单位和解决方案会有很多，建设完成后的系统常常是自治的，异构的，数据可能存放于数
据库、文本文件、XML文件，甚至普通文件中。因此也需要一种机制使不同时期建设的应用系统能有机地结合为一个整体。上述两种情况，均要求解决应用系统间数据和信息的互通、互用问题。 1.3定义 1.4参考文献 ?司法部关于报送《全国监狱信息化建设规划》（司法函[ ]111号） ?司法部关于印发《全国监狱信息化建设规划》的通知（司法通[ ]124号） ?《全国监狱信息化工程（一期）项目建设建议书》 ?关于印发《全国监狱信息化应用软件开发建设任务分工意见》的通知（[ ]司狱字277号） ?《国家发展改革委关于全国监狱信息化一期工程项目建议书的批复》（发改高技[ ]1389号） ?GB 8566 计算机软件开发规范 ?GB 8567 计算机软件产品开发文件编制指南 ?GB/T 12505 计算机软件配置管理计划规范 ?国家计算机软件工程规范
保密级别：S 资料编号：SRS-[产品代号] -[序列号] 版本：V[*].[*] [产品型号名称（二号字体）] [部件型号名称（可选、小二号字体）] 软件需求分析说明书 共11页 编制： 审核： 审定： 会签： 批准： XXXXXXXXXX公司 [****]年[**]月[**]日
文档修改记录
目录 1引言 (2) 1.1编写目的 (2) 1.2范围 (2) 1.3定义、首字母缩写词和缩略语 (2) 1.4参考资料 (2) 2项目概述 (3) 2.1产品描述 (3) 2.2产品需求 (3) 2.2.1功能需求 (3) 2.2.2性能需求 (4) 2.2.3可服务性需求 (4) 2.3用户及用户特点 (4) 2.4一般约束 (5) 2.5假设和依据 (5) 3用例描述 (5) 3.1用例1 (5) 3.2用例2 (6) 3.3用例n (6) 4外部接口需求 (7) 4.1用户接口 (7) 4.2硬件接口 (7) 4.3软件接口 (7) 4.4通信接口 (8) 5设计约束 (8) 5.1其他标准的约束 (8) 5.2硬件的限制 (8) 6属性 (8) 6.1可用性 (8) 6.2安全性 (9) 6.3可维护性 (9) 6.4可转移＼转换性 (9) 6.5警告 (9) 7其他需求 (9) 7.1数据库 (9) 7.2操作 (10) 7.3场合适应性需求 (10) 8附录 (10)
[说明：本模板中的蓝色字体与橙色字体为说明性文字，在最终提交的文档中请删除这些说明性的文字。] 1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者范围。 1.2 范围 说明： a．待开发的软件系统的名称； b．说明软件将干什么，如果需要的话，还要说明软件产品不干什么； c．描述所说明的软件的应用。应当： 1）尽可能精确地描述所有相关的利益、目的、以及最终目标。 2）如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。 1.3 定义、首字母缩写词和缩略语 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
软件需求规格说明书 文件编号： QMS—PROC－RD02 版本：1.0 受控签章
修改历史
目录 1引言 (2) 1.1目的 (2) 1.2背景 (2) 1.3术语 (2) 1.4预期读者与阅读建议 (2) 1.5参考资料 (2) 1.6需求描述约定 (2) 2.项目概述 (2) 2.1系统功能 (2) 2.2业务描述 (2) 2.3数据流程描述(可选) (2) 2.4用户的特点 (2) 2.5运行环境要求 (2) 2.6设计和实现上的限制 (2) 3.功能需求的描述 (2) 4.非功能需求 (2) 4.1系统性能要求 (2) 4.2系统安全及保密要求 (2) 4.3系统备份与恢复要求 (2) 4.4系统日志 (2) 5.外部接口说明 (2) 6.其他需求 (2) 7 需求变更识别 (2) 8.功能列表 (2) 9.附件 (2)
1引言 1.1 目的 说明编写这份软件需求规格说明书的目的，如：通过本文档定义ＸＸＸ产品的需求，以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景，包括： a．需开发的软件系统的名称，和英文缩写（可选），项目编号（可选）； b．列出此项目的任务提出者、开发者 c．软件系统应用范围、用户。 d．产生该系统需求的原因或起源，如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者，以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料，如： a．本项目经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d．行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
环境与灾害监测预报小卫星星座环境应用系统 XX系统需求规格说明书 单位： 作者： 完成日期： 签收人： 签收日期： 修改情况记录：
目录 1.引言 (1) 1.1.编写目的 (1) 1.2.背景 (1) 1.3.定义 (1) 1.4.参考资料 (1) 2.需求概述 (1) 2.1.目标 (1) 2.2.运行环境 (2) 2.3.关键点 (2) 2.4.约束条件 (2) 3.需求规格 (2) 3.1.软件系统总体功能／对象结构 (2) 3.2.软件子系统功能／对象结构 (2) 3.3.描述约定 (2) 3.4.功能或对象的描述 (3) 3.4.1.功能或对象1 (3) 3.4.2.功能或对象n (3) 3.5.性能 (4) 3.6.外部接口 (4) 3.7.数据 (4) 3.7.1.空间数据 (5) 3.7.2.非空间数据 (5) 3.8.操作 (5) 3.9.可使用性、可维护性、可移植性、可靠性和安全性 (5) 3.10.故障处理 (5) 3.11.算法说明 (6) 4.尚未解决的问题 (6) 5.支持信息 (6)
1.引言 1.1.编写目的 说明编写本软件需求规格说明书的目的，指出预期的读者。 1.2.背景 a.说明待开发产品或项目（以下简称产品）的名称。 b.列出此开发任务的提出者、开发者、用户等。 c.说明本产品与其他产品的关系。 1.3.定义 列出本文件中用到的专门术语的定义和缩写词原文。 1.4.参考资料 a.本文件中引用的属于本开发产品的其他文件。 b.本文件中引用的其他文献、资料以及软件开发标准。 2.需求概述 2.1.目标 a.本产品的开发意图、应用目标及作用范围（现有产品存在的问题和建议 产品所要解决的问题）。 b.本产品的主要功能、处理流程、数据流程及简要说明。 c.表示外部接口和数据流的系统高层次图。说明本产品与其他相关产品的 关系，是独立产品还是一个较大产品的组成部分（可用方框图说明）。
［在此处键入］****系统 软件需求规格说明书Versio n 1.0
精品资料
修订历史记录
目录 1 引言 (5) 1.1 目的与范围 (5) 1.2 预期的读者 (5) 1.3 系统的范围 (5) 1.4 参考资料 (5) 1.5 术语、缩写词 (6) 2 当前系统 (6) 2.1 当前系统概述 (6) 2.2 当前系统存在的问题................................... 错误！未定义书签。 3 建议的系统 .............................................................. 错误！未定义书签。 3.1 建议系统概述......................................... 错误！未定义书签。 3.2 功能性需求概述....................................... 错误！未定义书签。 3.3 非功能性需求......................................... 错误！未定义书签。 3.3.1 用户界面与人员因素............................ 错误！未定义书签。 3.3.2 硬件考虑..................................... 错误！未定义书签。 3.3.3 性能特征..................................... 错误！未定义书签。 3.3.4 错误处理与极端情况............................ 错误！未定义书签。 3.3.5 系统接口..................................... 错误！未定义书签。 3.3.6 质量要求..................................... 错误！未定义书签。 3.3.7 物理环境..................................... 错误！未定义书签。 3.3.8 安全问题..................................... 错误！未定义书签。 3.3.9 资源问题..................................... 错误！未定义书签。 3.4 系统变更............................................. 错误！未定义书签。 3.5 约束( Constraints ) ................................................................................. 错误！未定义书签。 3.6 系统模型............................................. 错误！未定义书签。 3.6.1 用例模型 (6) 3.6.2 对象模型..................................... 错误！未定义书签。 4 附录 .................................................................... 错误！未定义书签。 4.1 NEMA 0183 格式简介 ................................... 错误！未定义书签。
<教师报课系统> 需求规格说明书 作者：Mod4 完成日期：2015.10.16
修订历史记录
目录 1. 引言 (4) 1.1 目的 (4) 1.2 背景 (4) 1.3 定义 (4) 1.4参考文献 (4) 2. 项目概述 (5) 2.1 产品描述 (5) 2.2 产品功能 (5) 2.3 用户特点 (7) 2.4 一般约束 (7) 2.5 假设与依据 (7) 3. 具体需求 (7) 3.1 功能需求 (8) 3.1.1系统角色及登陆 (8) 3.1.2 学院负责人 (9) 3.1.3 系负责人 (17) 3.1.4 教师 (20) 3.2 外部接口需求 (23) 3.2.1 用户接口 (23) 3.2.2 硬件接口 (23) 3.2.3 软件接口 (23) 3.2.4 通信接口 (23) 3.3 性能需求 (23) 3.4 属性 (23) 3.4.1 可用性 (23) 3.4.2 安全性 (24) 3.4.3 可维护性 (24) 4. 验收验证标准 (24)
1. 引言 1.1 目的 该文档首先给出项目的整体结构和功能结构概貌，试图从总体架构上给出整个系统的轮廓。同时对功能需求、性能需求进行了详细的描述。便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开发工作的基础和依据以及确认测试和验收的依据。 本文档面向多种读者对象： （1）项目经理：项目经理可以根据该文档了解预期产品的功能，并据此进行系统设计、项目管理。 （2）设计员：对需求进行分析，并设计出系统，包括数据库的设计。 （3）程序员：了解系统功能，编写《用户手册》。 （4）测试员：根据本文档编写测试用例，并对软件产品进行功能性测试和非功能性测试。（5）用户：了解预期产品的功能和性能，并与分析人员一起对整个需求进行讨论和协商。 在阅读本文档时，首先要了解产品的功能概貌，然后可以根据自身的需要对每一功能进行适当的了解。 1.2 背景 本次待开发的软件为教师报课系统。 用户通过使用该软件在移动终端完成报课相关操作。学院负责人通过导入报课信息，设定截止时间来开启报课。系负责人查看报课信息，进行审核修改。教师填写报课信息，预览报课信息等最终提交报课。 1.3 定义 1.4参考文献 [1] GB-T8567-2006，《计算机软件文档编制规范》[S] [2].（美）Roger S.Pressman著，郑人杰等译.软件工程[M].第七版.北京：机械工业出版社,2011.
软件需求规格说明书 1范围 标识 SRS适用范围：城市教育资源管理系统 标识号：GDGL004 标题：城市教育资源管理系统 版本号： 发行号：Alpha001（内测版） 系统概述 随着我国政治体制改革、经济体制和教育体制改革的不断深入，城市教育在构建和谐社会中发挥着重要作用。教育资源的优劣，直接关系着教育效益的产出。教育资源管理的好坏将直接影响着学校的建设和发展。目前中国城市人均教育经费差异很大，城市间高等教育阶段生师比的差距比较大,而基础教育的差距相对较小;城市经济发展水平是影响这些差异的主要因素,其次是城市人口规模;促进不发达地区城市和小城市的经济发展、建立合理的人口流动机制是消除城市间教育资源差异的有利措施。 城市教育资源管理系统是指综合运用地理信息系统（GIS）、多媒体及虚拟现实等现代信息技术实现面向高校教学管理部门提供教学资源管理的服务平台，对学校校舍、课桌、教学用具等硬件设施和师资力量等软件设施的信息的采集、集成和管理，根据地区各等级基础教育学校个数、学校规模和周边做涵盖教育分配地区，确定各个学校教育资源的优劣、所需教育人员以及所能容纳学生人数，也可以进行教育资源的调动管理，教职工人事变动管理，教学资源合理分配与再分配，地区教育质量评价等等。 它的建设将为教育部门对教育资源的管理起到很重要的监督和管理作用。并能够作为一项新兴的部门管理方法。 文档概述 在信息化高速发展的今天，时间效率这样的名词正主导着人们的生活和发展,有必要设计开发一个城市教育资源管理系统。通过系统功能有效的解决城市间教育经费、教育阶段生师比等等间的差异，从而提高管理效率。 本文档具体对城市教育资源管理系统的软件需求等进行基本分析，确定该系统基本功能及需求，故在此针对本系统编写此文档，本文档的最终解释权在本小组手中，请勿随意更改。 基线 本文档的设计基线是《GBT8567-2006计算机软件文档编制规范》。 2引用文件 [1]GBT8567-2006计算机软件文档编制规范. 2006 [2] Liang著李娜译,JAVA语言程序设计．北京：机械工业出版社2012 [3]刘先锋,数据库系统原理与应用. 武汉：华中科技大学出版社2012 [4]谢希仁,计算机网络（第五版）．北京：电子工业出版社2012
XXX系统或XXX项目 产品需求规格说明书 版本信息 注：状态可以为N-新建、A-增加、M-更改、 对方的所得税说明：版本信息必须更新，审核人和审核时间也必须审核后填写，审核人要求部门经理级别以上。否则开发测试可拒绝评审。审核业务功能是否有遗漏、业务流程是否符合规划、关键业务逻辑是否有合理 目录
1.关于本文档 1.1.内容说明 说明：此处描述的是文档说明，产品需求文档更新需要走修订模式，下次更新前先接受修订，并且每次更新必须更新版本号和版本记录。 例子： 本文档用于描述苏宁开放平台物流状态服务系统的需求定义。包括各个需求的功能描述，处理逻辑规则，界面定义，与其它功能的关系，与其它系统的接口等各个方面的定义。是苏宁物流状态服务系统唯一的全面需求定义文档。 本文档将根据需求管理流程和要求，随系统功能变化进行及时的修订和更新，以确保本文档的全面性，准确性和实效性。因此在阅读使用此文档时，请注意从项目的文档管理系统中获取最新版本。 1.2.名词解释
1.3.参考文档 《系统需求定义规范使用说明》 2.系统概述 2.1.业务背景 说明：此处描述业务背景，不可裁剪，清晰的业务背景描述能更好的帮助研发和测试理解产品需求，明确业务测试场景，此部分是产品需求定位的核心导向。 例子一：电子面单的业务描述 随着电子商务服务和物流服务信息化飞速发展，包裹运单号成为快递公司串联快递单、订单、商家、商品等各种信息的枢纽。相比之下，传统纸质面单价格高、信息录入效率低、信息安全隐患等方面的劣势已愈发凸显。我司在两年前就开始了电子面单在自营物流上的应用，经过长期的的磨合和积累，目前将我司的应用经验推广到社会物流上，让社会上愿意与我司物流合作的伙伴，也同样享受到我司电子面单服务。 例子二：LSQ的业务描述 物流作业状态服务存在不足 1）服务无标准不统一 需物流作业的各渠道订单，作业状态转化为文案描述处理的逻辑系统多，且处理规不统一， －B2C自营订单，逻辑在B2C，数据源在OMS －菜鸟平台/4PS平台订单状态展示，逻辑在LAPI，数据源在LAPI
密级： （软件项目名称） 软件需求规格说明 标识： 版本： 页数： 拟制： SQA审核： 审核： 批准： 拟制部门： 年月日
修改文档历史记录： 日期版本说明修改人
目录 1 范围 (1) 1.1 标识 (1) 1.2 系统概述 (1) 1.3 文档概述 (1) 2 引用文档 (1) 3 需求 (1) 3.1 要求的状态和方式 (1) 3.2 CSCI能力需求 (4) 3.2.X（CSCI能力） (4) 3.3 CSCI外部接口需求 (5) 3.3.1 接口标识和接口图 (5) 3.3.X（接口的项目唯一的标识符） (5) 3.4 CSCI内部接口需求 (8) 3.5 CSCI内部数据需求 (9) 3.6 适应性需求 (9) 3.7 安全性需求 (9) 3.8 保密性需求 (10) 3.9 CSCI环境需求 (10) 3.10 计算机资源需求 (10) 3.10.1 计算机硬件需求 (10) 3.10.2 计算机硬件资源使用需求 (11) 3.10.3 计算机软件需求 (11) 3.11 软件质量因素 (11) 3.12 设计和实现约束 (12) 3.13 人员需求 (12) 3.14 培训需求 (12) 3.15 后勤保障需求 (12) 3.16 其它需求 (12) 3.17 验收、交付和包装需求（修改有关内容） (12) 3.18 需求的优先顺序和关键程度 (13) 4 合格性规定 (13) 5 需求可追踪性 (13) 6 注释 (14)
1 范围 1.1 标识 【本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号及发布号。】 示例： 系统标识如下： a)已批准的标识号： b)产品名称：XXXXXX c)产品代号：XXXXXX d)版本号：XXXXX e)缩略名： 1.2 系统概述 【本条应概述本文档所适用的系统和软件的用途。它还应描述系统与软件的一般特性；概述系统开发、运行和维护的历史；标识项目的需方、用户、开发方和保障机构；标识当前和计划的运行现场；列出其它有关文档。】 示例： a) 软件用途： b) 系统概述： c) 需方：XXXXX d) 开发方：软件开发组 e) 运行环境：XXXXX f) 相关文档： 以下描述相关技术数据内容: 1) 软件开发计划 2) 软件研制任务书 3) 。。。 1.3 文档概述 【本条应概述文档的用途和内容，并描述与它的使用有关的保密性方面的要求。】 2 引用文档 【本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识所有不能通过正常采购活动得到的文档的来源。】 3 需求 3.1 要求的状态和方式 【如果要求CSCI在多种状态或多种方式下运行，并且不同的状态或方式具有不同的需求，则应标识和定义每一种状态和方式。状态和方式的例子包括：空闲、就绪、活动、事后分析、训练、降级、紧急情况、备份、战时和平时等。可以仅用状态描述CSCI，也可仅用方式、用方式中的状态、状态中的方式、或其他有效的方式描述CSCI。如果不需要多种状
项目名称 软件需求规格说明
文档签署记录
文档修改记录
目录 1 引言 (1) 1.1 目的 (1) 1.2 项目背景 (1) 1.3 范围 (1) 1.4 参考资料 (1) 1.5 综述 (1) 2 总体概述 (2) 2.1 产品描述 (2) 2.2 产品功能 (2) 2.3 用户特点 (2) 2.4 设计约束 (2) 2.4.1 标准规范 (2) 2.4.2 软件开发语言 (2) 2.4.3 软件开发工具和环境 (2) 2.4.4 软件测试环境 (3) 3 具体需求 (4) 3.1 软件流程功能 (5) 3.1.1 流程1 (5) 3.2 功能需求 (7) 3.2.1 试验资源管理 (7) 3.2.2 试验过程管理 (9) 3.3 软件模块划分 (11) 3.4 系统集成接口 (12) 3.4.1 与管理系统的接口 (12) 3.5 性能需求 (12) 3.5.1 精度 (12) 3.5.2 时间特性要求 (12) 3.6 数据处理要求 (12) 3.7 软件质量要求 (13) 3.7.1 易用性 (13) 3.7.2 可靠性 (13) 3.7.3 安全性 (13) 3.7.4 可维护性 (13) 3.8 可靠性、安全性和维护性要求 (13) 3.8.1 软件安全性等级、可靠性指标 (13) 3.8.2 软件运行寿命 (13) 3.8.3 软件安全性要求 (13) 3.8.4 软件健壮性要求 (13) 3.8.5 软件不期望事件要求 (14) 3.8.6 软件维护性要求 (14) 4 运行环境规定 (14) 4.1 部署方案 (14) 4.2 系统运行的硬件环境要求 (14)
软件需求规格说明书 湖南长沙阳环科技实业有限公司文件更改摘要：
目录 1引言....................................................... 错误!未定义书签。 目的 .................................................... 错误!未定义书签。 背景 .................................................... 错误!未定义书签。 术语 .................................................... 错误!未定义书签。 预期读者与阅读建议 ...................................... 错误!未定义书签。 参考资料 ................................................ 错误!未定义书签。 需求描述约定 ............................................ 错误!未定义书签。 需求层次划分........................................ 错误!未定义书签。 需求跟踪粒度........................................ 错误!未定义书签。 需求级别定义........................................ 错误!未定义书签。 功能描述方法........................................ 错误!未定义书签。 界面描述规则........................................ 错误!未定义书签。2项目概述................................................... 错误!未定义书签。 系统功能 ................................................ 错误!未定义书签。 业务描述 ................................................ 错误!未定义书签。 用户的特点 .............................................. 错误!未定义书签。 运行环境要求 ............................................ 错误!未定义书签。 设计和实现上的限制 ...................................... 错误!未定义书签。3系统功能需求 ............................................... 错误!未定义书签。 总体功能需求 ............................................ 错误!未定义书签。 自测系统需求 ............................................ 错误!未定义书签。 获取试卷............................................ 错误!未定义书签。 自测作答............................................ 错误!未定义书签。 提交试卷............................................ 错误!未定义书签。
XXX公司 XXXX系统 需求规格说明书 XXX公司 2013年8月
修订记录
目录 1.引言 (1) 1.1.编写目的 (1) 1.2.项目背景 (1) 1.3.术语定义 (1) 1.4.参考资料 (2) 2.任务概述 (3) 2.1.建设目标 (3) 2.2.建设内容 (3) 2.3.用户要求 (3) 2.4.假定和约束 (4) 3.系统需求 (5) 3.1.功能架构图 (5) 3.2.通用需求 (5) 3.2.1.系统通用工具栏 (5) 3.2.2.其它通用需求 (6) 3.3.XXX管理子系统 (7) 3.3.1.系统管理 (7) 3.4.集成需求 (12) 3.4.1.基础数据对接 (12) 3.4.2.单点登录（SSO） (12) 3.4.3.文书跨系统审批 (12) 3.4.4.短信提醒 (13) 3.5.性能需求 (13) 3.6.网络需求 (13) 3.7.存储需求 (13) 3.8.安全需求 (14) 3.8.1.技术平台设计安全需求 (14) 3.8.2.系统运行安全需求 (15) 4.运行环境规定 (15) 4.1.设备 (15) 4.2.软件 (16) 4.2.1.服务器操作系统版本 (16) 4.2.2.客户机 (17) 4.2.3.数据库版本 (17) 4.2.4.中间件服务器版本 (17) 4.3.接口 (17) 4.3.1.外部接口 (17) 4.3.2.内部接口 (18)
名词缩写： 1.XXX集团，即“XXX省XXX集团有限责任公司”；[引号里面为全称] 2.XXX系统，即“XXX集团XXX系统”；[引号里面为全称] 3.XXX公司，即“XXX有限公司”，系统承建单位。[引号里面为全称]
数据交换需求规格说明书
1引言 1.1编写目的 为了能更好的描述清楚《国科政信数据交换平台》（以下简称“数据交换”或“本项目”）业务需求，更好地让相关人员了解本项目的各个模块及功能点，特编写此需求规格说明书。 本文档主要从业务需求、功能描述、环境要求、操作要求、设计约束及质量要求等方面阐述，同时说明了系统的合格性需求及交付需求等综合要求，是作为本项目软件的设计及测试工作的重要依据。 本文档的预期读者为业务用户、设计人员、开发人员、测试人员、项目管理人员等相关人员 1.2背景 目前，国内各地政府部门和机构或多或少均建立起自己的信息化系统，包括门户网站内容管理系统、OA办公系统、办事审批系统、其它业务系统等。但由于诸多因素的影响，即使同一地区的政府机构间也无法进行合理、有效的沟通，可以说是一座座的“信息孤岛”。电子政务实施的任务之一就是要将这些“孤岛”有机地串连在一起，充分发挥其效能，同时也保护了各部门在该方面的经济投入和精力投入。此外，电子政务建设过程中，即使是统一规划，但具体的实施单位和解决方案会有很多，建设完成后的系统常常是自治的，异构的，数据
可能存放于数据库、文本文件、XML文件，甚至普通文件中。因此也需要一种机制使不同时期建设的应用系统能有机地结合为一个整体。上述两种情况，均要求解决应用系统间数据和信息的互通、互用问题。 1.3定义 1.4参考文献 ?司法部关于报送《全国监狱信息化建设规划》（司法函[2007]111号） ?司法部关于印发《全国监狱信息化建设规划》的通知（司法通[2008]124号） ?《全国监狱信息化工程（一期）项目建设建议书》 ?关于印发《全国监狱信息化应用软件开发建设任务分工意见》的通知（[2010]司狱字277号） ?《国家发展改革委关于全国监狱信息化一期工程项目建议书的批复》（发改高技[2010]1389号） ?GB 8566 计算机软件开发规范 ?GB 8567 计算机软件产品开发文件编制指南 ?GB/T 12505 计算机软件配置管理计划规范 ?国家计算机软件工程规范
需求规格说明书(ISO标准版) 编者说明： 当需求调查、分析工作告一段落时，你就需要将这些需求进行规格化描述，整理成文，即软件需求规格说明书，也就是SRS。这是在软件项目过程中最有价值的一个文档。ISO所提供的标准虽然已经时间久远，但还是颇具参考价值的。 1．引言 1.1编写的目的 [说明编写这份需求说明书的目的,指出预期的读者。] 1.2背景 a. 待开发的系统的名称; b. 本项目的任务提出者、开发者、用户； c. 该系统同其他系统或其他机构的基本的相互来往关系。 1.3定义 [列出本文件中用到的专门术语的定义和外文首字母组词的原词组。] 1.4参考资料 [列出用得着的参考资料。] 2．任务概述 2.1目标 [叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景材料。解释被开发系统与其他有关系统之间的关系。] 2.2用户的特点 [列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本系统的预期使用频度。] 2.3假定和约束 [列出进行本系统开发工作的假定和约束。] 3．需求规定 3.1对功能的规定 [用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出，说明系统的容量,包括系统应支持的终端数和应支持的并行操作的用户数等指标。] 3.2 对性能的规定 3.2.1精度 [说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。] 3.2.2时间特性要求 [说明对于该系统的时间特性要求。] 3.2.3灵活性 [说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。] 3.3输入输出要求 [解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对系统
【系统名称】功能需求规格说明书 【——子系统名称】
文档创建信息 文档修订记录 修改类型分为A– ADDED（增加）M– MODIFIED（修改）D– DELETED（删除）
目录 1.引言 (4) 1.1 目的 (4) 1.2 读者范围 (4) 1.3 术语或缩略语 (4) 2.系统定位 (5) 2.1 目标用户 (5) 2.2 针对的用户需求 (5) 2.3 卖点功能 (5) 2.4 系统性质 (6) 3.需求综述 (6) 3.1 概念界定 (6) 3.1.1角色界定................................................................ 错误！未定义书签。 3.1.1.1 用户 (6) 3.1.1.2 外部系统 (6) 3.1.1.3 内部子系统 ..................................................... 错误！未定义书签。 3.1.2信息实体界定......................................................... 错误！未定义书签。 3.2 系统外延 (7) 3.2.1系统应用环境总览 (7) 3.2.2系统与用户交互关系 (7) 3.2.3系统与外部系统交互关系 (7) 3.3 系统内涵 (7) 3.3.1系统总体结构 (7) 3.3.2系统功能概述 (8) 3.3.3系统内部协作关系 (8) 4.功能使用流程 (8) 4.1 功能使用流程总览 (8) 4.2 功能使用流程描述 (9) 4.2.1【功能使用流程名称】 (9) 4.2.2【功能使用流程名称】 (10) 5.用户界面 (10) 5.1 总则 (10) 5.2 界面总览 (10) 5.3 界面详解 (11) 5.3.1【界面名称】 (11) 5.3.1.1 界面功能概述 (11) 5.3.1.2 界面元素总览 (11) 5.3.1.3 界面元素详解 (12) 5.3.1.4 界面默认规则 (13) 5.3.2【界面名称】 (13)
软件需求规格说明(SRS) 1范围 1.1标识 本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。 1.2系统概述 本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。 1.3文档概述 本条应概述本文档的用途和内容，并描述与其使用有关的保密性或私密性要求。 1.4基线 说明编写本系统设计说明书所依据的设计基线。 2引用文件 本章应列出本文档引用的所有文档的编号、标题、修订版本和发行日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。 3需求 本章应分以下几条描述CSCI需求，也就是，构成CSCI验收条件的CSCI的特性。CSCI需求是为了满足分配给该CSCI的系统需求所形成的软件需求。给每个需求指定项目唯一标识符以支持测试和可追踪性。并以一种可以定义客观测试的方式来陈述需求。如果每个需求有关的合格性方法(见第4章)和对系统(若适用，子系统)需求的可追踪性(见5.a条)在相应的章中没有提供，则在此进行注解。描述的详细程度遵循以下规则：应包含构成CSCI验收条件的那些CSCI特性，
需方愿意推迟到设计时留给开发方说明的那些特性。如果在给定条中没有需求的话，本条应如实陈述。如果某个需求在多条中出现，可以只陈述一次而在其他条直接引用。 3.1所需的状态和方式 如果需要CSCI在多种状态和方式下运行，且不同状态和方式具有不同的需求的话，则要标识和定义每一状态和方式，状态和方式的例子包括：空闲、准备就绪、活动、事后分析、培训、降级、紧急情况和后备等。状态和方式的区别是任意的，可以仅用状态描述CSCI,也可以仅用方式、方式中的状态、状态中的方式或其他有效方式描述。如果不需要多个状态和方式，不需人为加以区分，应如实陈述；如果需要多个状态或方式，还应使本规格说明中的每个需求或每组需求与这些状态和方式相关联，关联可在本条或本条引用的附录中用表格或其他的方法表示，也可在需求出现的地方加以注解。 3.2需求概述 3.2.1目标 a.本系统的开发意图、应用目标及作用范围(现有产品存在的问题和建议产品所要解决的问题)。 b.本系统的主要功能、处理流程、数据流程及简要说明。 c.表示外部接口和数据流的系统高层次图。说明本系统与其他相关产品的关系，是独立产品还是一个较大产品的组成部分(可用方框图说明)。 3.2.2运行环境 简要说明本系统的运行环境(包括硬件环境和支持环境)的规定。 3.2.3用户的特点 说明是哪一种类型的用户，从使用系统来说，有些什么特点。 3.2.4关键点 说明本软件需求规格说明书中的关键点(例如：关键功能、关键算法和所涉及的关键技术等)。