P_系统需求规格说明(SSS).docVIP

北京市*****建设项目 系统需求规格说明(SSS) **************公司 2016年6月 文档修订记录 版本 修订人 审核人 更改记录 （标注页码、章节、简要内容） 修订人 日期 审核人 日期 说明： 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 引言 标识 本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。 系统概述 本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、操作和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划中的运行现场；列出其他有关的文档。 文档概述 本条应概括本文档的用途和内容，并描述与其使用有关的保密性和私密性要求。 引用文件 本章应列出本文档所引用所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。 需求 本章分条详述系统需求，是指功能、业务(包括接口、资源、性能、可靠性、安全性、保密性等)和数据需求。也就是，构成系统验收条件的系统特性。给每个需求指定项目唯一标识符以支持测试和可追踪性。并以一种可以定义客观测试的方式来陈述需求。对每个需求都应说明相关合格性方法(见第4章)，如果是子系统，则还要给出从该需求至系统需求的可追踪性(见5.a条)。描述的详细程度遵循以下规则：应包含构成系统验收条件的那些系统特性，需方愿意推迟到设计时留给开发方说明的那些特性。如果在给定条中没有需求可说明的话，应如实陈述。如果某个需求在多条中出现，可以只陈述一次而在其他条中引用之。 要求的状态和方式 如果要求系统在多种状态和方式下运行，且不同状态和方式具有不同的需求的话，则要标识和定义每一状态和方式。状态和方式的例子包括：空闲、就绪、活动、事后分析、训练、降级、紧急情况和后备等。状态和方式的区别是任意的，可以仅用状态描述系统，也可以仅用方式、方式中的状态、状态中的方式或其他有效的方式描述。如果不需要多个状态和方式，不需人为加以区分，应如实陈述；如果需要多个状态和/或方式，还应使本规格说明中的每个需求或每组需求与这些状态和方式相关联，关联可在本条或本条引用的附录中用表格或其他的方法表示，也可在需求出现的地方加以注解。 需求概述 系统总体功能和业务结构 描述系统总体功能和业务的结构。 硬件系统的需求 说明对硬件系统的需求。 软件系统的需求 说明对软件系统的需求。 接口需求 说明硬件系统和软件系统之间的接口。 系统能力需求 本条应分条详细描述与系统每一能力相关联的需求。“能力”被定义为一组相关的需求。可以用“功能”、“性能”、“主题”、“目标”或其他适合用来表