<项目名称>
系统需求规范
版本 <1.0>
[注意:以下模板供与 Rational Unified Process 一起使用。包含在方括号中以蓝色斜体(style=InfoBlue)显示的文本是用于向作者提供指导,在发布文档之前必须删除这些文本。在此样式之后输入的段落将自动设置为正常(style=Body Text)。]
修订历史记录
日期 |
版本 |
描述 |
作者 |
<dd/mmm/yy> |
<x.x> |
<详细信息> |
<名称> |
|
|
|
|
|
|
|
|
|
|
|
|
目录
系统需求规范
[系统需求规范(SysRS)的简介提供了整个 SysRS 的概述。它包括 SysRS 的目的、范围、定义、首字母缩写、缩写、参考资料和概述。]
[注意:SysRS 捕获系统或系统某一部分的完整系统需求。后面是项目的典型 SysRS 概述,它仅使用传统的自然语言形式需求(不使用用例建模)。它使用综合补充规范,或是插入的相等材料,在单个文档中捕获所有的需求。]
[指定本 SysRS 的目的。SysRS 全面地描述了所标识系统的功能和行为能力。它还描述提供系统需求完整而全面的描述所必需的非功能需求、设计约束和其他因素。]
[简要地描述了 SysRS 所应用于的系统和该文档影响的其他事物。]
[本子节提供正确解释 SysRS 所需的所有术语、首字母缩写和缩写的定义。该信息可通过引用项目词汇表提供。]
[本子节提供了会在 SysRS 中的其他地方引用的所有文档的完整列表。通过标题、报告号(如果适用)、日期和出版组织来标识每个文档。指定参考资料的出处。可以通过引用附录或其他文档来提供此信息。]
[本子节描述 SysRS 的剩余部分包含哪些内容,并说明文档是如何组织的。]
[SysRS 的这一节描述影响系统及其需求的常规因素。本节不说明具体的需求。它提供的是那些需求的背景,使第 3 节中详细定义的那些需求更易于理解。 包含诸如以下项:
可以在本节至远景工件之间进行引用,而不是从该文档中复制资料。]
[如果您正在使用用例模型,那么本节包含了用例模型的概述。这包括所有用例和参与者的名称和简要描述的列表,以及适用的图和关系。请参考用例模型调查报告,此时它可以用作附件。
[本节描述所有关键的技术可行性、子系统或组件可用性,或者 SysRS 描述的系统的可行性可能基于的与其他项目相关的假定。]
[SysRS 的这一节中包含达到一定详细程度的所有系统需求,这些需求足以支持设计员设计满足那些需求的系统,并足以支持测试员测试系统是否满足那些需求。
在使用用例建模时,或是作为工件本身,或是按照本文档中『3.2 非功能性需求』章节,将这些需求捕获到用例和适用的补充规范中。]
[本节描述了以用例表示的系统所需能力。对于许多系统,这可能构成 SysRS 包的大部分内容,因此应当仔细考虑本节的组织。本节通常按照特性、功能或者功能组(这些广泛说明了“能力”的特点,且来自远景工件)进行组织 - 但其他组织方法也可能是适用的;例如,按照用户或角色进行组织。]
[在用例建模中,用例定义了系统大部分的功能需求,以及一些非功能(性能相关)需求。对于上面的用例模型中的每个用例,请引用或包含本节中的用例报告。确保明确地标注每个需求。在合适的时候,按照能力组合用例(如有必要可在功能上进行优化),这样就能正确描述功能和行为。]
[本节描述了以自然语言形式表示的系统其他一些功能需求(未被捕获为用例)。]
[需求描述。]
[需求描述。]
[本节概括了系统的性能特征。包含特定的响应时间。按名称引用相关的用例(如果适用)。总之,使用一些性能语句(描述系统应该如何良好地提供能力或功能)来关联全部所需的能力,无论是以用例形式还是只用文本进行描述。对于那些受影响的能力(例如,在用例描述的“特殊需求”部分)来说,最好将那些性能语句保存在一起。此处,您可以保存那些需要测试的性能语句,但是它们没有特定能力。性能特征包括:
[需求描述。]
[本节指明将会增强要构建的系统的可支持性或可维护性的所有需求,包括编码标准、命名约定、类库、维护访问权和维护实用程序。]
[需求描述。]
[本节指示关于要构建的系统的所有设计约束。设计约束表示必须服从的强制性设计决策。举例来说,它包括软件语言、软件流程需求、开发工具的指定使用、体系结构和设计约束、购买的组件以及类库等。]
[需求描述。]
[系统工程潜在地需要满足其他类型的需求:]
[例如,重量、大小、电源等。]
[例如,湿度、污染、热量、电、机械等。]
[例如,安全性和其他质量因素(如生存力)。]
[描述对系统的需求,以支持使用和支持系统的用户。包括培训能力(培训包含的设备和材料)、维护能力以及接口描述和标准没有涉及到的环境注意事项。
[出于对物流的考虑(包括维护、支持、运输、供应和安装现有系统),描述对系统的需求。]
[描述联机用户文档、帮助系统、声明相关帮助等方面的需求(如果有的话)。]
[本节描述所有购买的要在系统中使用的组件、所有适用的许可或使用限制以及所有关联的兼容性/互操作性或接口标准。]
[本节定义系统必须支持的接口。本节必须包含足够的特性、协议、端口和逻辑地址等,这样才能按照接口需求开发和验证系统。还必须描述对系统内部接口的需求。例如,当系统设计仅限于内部使用现有的硬件和软件时,会出现这些需求。]
[描述系统要实施的用户界面。]
[本节定义系统要支持的所有硬件接口,包括逻辑结构、物理地址、期望的行为等。]
[本节根据所支持的操作和信号(和需要 何种支持)、协议何数据特征来描述系统要支持的软件接口。]
[描述到其他系统或设备(例如局域网等)的所有通信接口。]
[定义所有许可实施需求或系统要展示的其他使用限制需求。]
[本节描述系统的所有必要法律免责条款、担保、版权声明、专利声明、字标记、商标或徽标符合性问题。]
[本节通过引用方式描述所有适用的标准以及这些标准中适用于所述系统的具体部分。例如,本节可能包含法律、品质和规章标准以及有关可用性、互操作性、国际化和操作系统符合性等的行业标准。]
[支持信息使 SysRS 更易于使用。它包括:
其中可能包含有关体系结构和用户界面原型的信息。在包含附录时,SysRS 中应当明确地规定是否将附录视为需求的组成部分。]