<项目名称>

系统需求规范

 

 

 

版本 <1.0>

 

 

[注意:以下模板供与 Rational Unified Process 一起使用。包含在方括号中以蓝色斜体(style=InfoBlue)显示的文本是用于向作者提供指导,在发布文档之前必须删除这些文本。在此样式之后输入的段落将自动设置为正常(style=Body Text)。]


修订历史记录

日期

版本

描述

作者

<dd/mmm/yy>

<x.x>

<详细信息>

<名称>

 

 

 

 

 

 

 

 

 

 

 

 

 


目录

1.       简介         

1.1     目的     

1.2     范围     

1.3 定义、首字母缩写词和缩写     

1.4     参考资料     

1.5     概述     

2.       总体描述    

3.       特定需求

3.1     系统能力

3.1.1         <系统能力一>        

3.2     非功能需求

3.2.1 可用性 

3.2.2 可靠性 

3.2.3 性能 

3.2.4 可支持性 

3.2.5 设计约束 

3.2.6 其他系统工程注意事项 

3.2.6.1 物理需求 

3.2.6.2 环境需求 

3.2.6.3 其他产品保证需求 

3.2.6.4 人事需求 

3.2.6.5 物流需求 

3.2.7联机用户文档和帮助系统需求 

3.2.8 购买的组件 

3.2.9 接口 

3.2.9.1 用户界面 

3.2.9.2 硬件接口 

3.2.9.3 软件接口 

3.2.9.4 通信接口 

3.2.10 许可需求 

3.2.11 法律、版权和其他声明 

3.2.12 适用标准

4.      支持信息    


系统需求规范

1.                  简介

[系统需求规范(SysRS)的简介提供了整个 SysRS 的概述。它包括 SysRS 的目的、范围、定义、首字母缩写、缩写、参考资料和概述。]

[注意:SysRS 捕获系统或系统某一部分的完整系统需求。以下是一个项目的典型 SysRS 大纲,该项目在没有用例模型的情况下仅使用传统自然语言风格的需求。它使用综合补充规范,或是插入的相等材料,在单个文档中捕获所有的需求。]

1.1     目的

[指定本 SysRS 的目的。SysRS 全面地描述了所标识系统的功能和行为能力。它还描述了给系统需求提供一个完整且全面的描述所必需的非功能需求、设计约束和其他因素。]

1.2     范围

[简要地描述 SysRS 所应用于的系统和该文档影响的其他事物。]

1.3     定义、首字母缩写词和缩写

[本子节提供正确解释 SysRS 所必需的所有术语、首字母缩写和缩写的定义。 可以通过引用项目词汇表来提供此信息。]

1.4     参考资料

[本子节提供了会在 SysRS 中的其他地方引用的所有文档的完整列表。通过标题、报告号(如果适用)、日期和出版机构来标识每个文档。指定参考资料的出处。可以通过引用附录或其他文档来提供此信息。]

1.5     概述

[本子节描述 SysRS 的剩余部分包含哪些内容,并说明文档是如何组织的。]

2.                 总体描述

[SysRS 的这一节描述影响系统及其需求的一般因素。本节不陈述特定的需求。相反,它提供的是那些需求的背景,使第 3 节中详细定义的那些需求更易于理解。包括以下项:

可以在本节至远景工件之间进行引用,而不是从本文档中复制资料。]

3.                 特定需求

[SysRS 的这一节中包含达到一定详细程度的所有系统需求,这些需求足以支持设计员设计满足那些需求的系统,并足以支持测试员测试系统是否满足那些需求。]

3.1              系统能力

[本节描述了以自然语言表示的系统所需能力。对于许多系统,这可能构成 SysRS 包的大部分内容,因此应当仔细考虑本节的组织。本节通常按照特性、功能或者功能组(来自远景工件)进行组织,但其他组织方法也可能是适用的;例如,按照用户或角色进行组织。

本节描述了在构成需求中优化特性或者功能,具体化因此而产生的需求。 同时也描述了为了支持这些产生的需求,系统需要表示的行为和相关性能需求(响应时间、速度、吞吐量、速率、频率、精确度、精密度、容量等)。该行为描述也包括在错误或者故障状态下所需的行为(处理错误输入、意外情况、回退等)。并不是在所有情况下都有必要去指定如何处理错误和意外事件。在许多情况下,这可以留给系统架构设计师去决定。]

3.1.1          <系统能力一>

[能力描述和优化。]

3.2                 非功能需求

[注意:如果已经生产了补充规范工件,此处可能会包括它。它涵盖了相同的主题。]

3.2.1         可用性

[本节包含所有影响可用性的需求。示例如下:

3.2.1.1    <可用性需求一>

[需求描述。]

3.2.2          可靠性

[指定此处系统的可靠性需求。建议如下:

3.2.2.1     <可靠性需求一>

[需求描述。]

3.2.3          性能

[本节概括了系统的性能特征。包含特定的响应时间。如果适用,可按名称引用相关用例。总之,使用一些性能语句(描述系统如何良好地提供能力或功能)来关联全部所需的能力,无论是以用例形式还是只用文本进行描述。对于那些受影响的能力(例如,在用例描述的“特殊需求”部分)来说,最好将那些性能语句保存在一起。此处,您可以保留那些需要测试的性能语句,但是它们与特定能力无关。一些性能特征是:

3.2.3.1      <性能需求一>

[需求描述。]

3.2.4          可支持性

[本节指明将会增强要构建的系统的可支持性或可维护性的所有需求,包括编码标准、命名约定、类库、维护访问权和维护实用程序。]

3.2.4.1    <可支持性需求一>

[需求描述。]

3.2.5          设计约束

[本节指明对于要构建的系统的所有设计约束。设计约束表示必须服从的强制性设计决策。举例来说,它包括软件语言、软件流程需求、开发工具的指定使用、体系结构和设计约束、购买的组件以及类库等。]

3.2.5.1     <设计约束一>

[需求描述。]

3.2.6     其他系统工程注意事项。

[系统工程潜在地需要满足其他类型的需求:]

3.2.6.1  物理需求

[例如,重量、大小、电源等。]

3.2.6.2  环境需求

[例如,湿度、污染、热量、电、机械等。]

3.2.6.3  其他产品保证需求

[例如,安全性和其他质量因素(如生存力)。]

3.2.6.4   人事需求

[描述对系统的需求,以支持使用和支持系统的用户。包括培训能力(培训包含的设备和材料)、维护能力以及接口描述和标准没有涉及到的环境注意事项。

3.2.6.5   物流需求

[出于对物流的考虑(包括维护、支持、运输、供应、安装现有系统),描述对系统的需求。]

3.2.7          联机用户文档和帮助系统需求

[描述联机用户文档、帮助系统、关于声明的帮助等的需求(如有)。]

3.2.8         购买的组件

[本节描述要与系统一起使用的所有购买组件、所有适用的许可或使用限制以及所有关联的兼容性/互操作性或接口标准。]

3.2.9          接口

[本节定义系统必须支持的接口。本节包含足够的特性、协议、端口和逻辑地址等,这样才能按照接口需求开发和验证系统。]还请描述对系统内部接口的需求。例如,当系统设计仅限于内部使用现有的硬件和软件时,会出现这些需求。]

3.2.9.1     用户界面

[描述系统要实施的用户界面。]

3.2.9.2      硬件接口

[本节定义系统要支持的所有硬件接口,包括逻辑结构、物理地址、期望的行为等。]

3.2.9.3       软件接口

[本节根据所支持的操作和信号(和需要何种支持)、协议和数据特征来描述系统支持的软件接口。]

3.2.9.4       通信接口

[描述到其他系统或设备(例如局域网等)的所有通信接口。]

3.2.10        许可需求

[定义所有许可实施需求或系统要展示的其他使用限制需求。]

3.2.11        法律、版权和其他声明

[本节描述系统所有必要的法律免责条款、担保、版权声明、专利声明、字标记、商标或徽标符合性问题。]

3.2.12        适用标准

[本节通过引用描述所有适用的标准以及这些标准中适用于所述系统的具体部分。例如,其中可以包括法律、质量和规章标准,以及可用性、互操作性、国际化、操作系统兼容性等行业标准。]

4.                  支持信息

[支持信息使 SysRS 更易于使用。它包括:

其中可能包含有关体系结构和用户界面原型的信息。在包含附录时,SysRS 中应当明确地规定是否将附录视为需求的组成部分。]