<项目名称>

补充规范

 

版本 <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.       功能     

2.1     <功能需求一>     

3.       可用性

3.1     <可用性需求一>     

4.       可靠性

4.1     <可靠性需求一>     

5.       性能       

5.1     <性能需求一>     

6.       可支持性    

6.1     <可支持性需求一>     

7.       设计约束   

7.1     <设计约束一>     

8.        系统工程师其他注意事项               

8.1     物理需求     

8.2     环境需求     

8.3     其他产品保证需求     

8..3.x   <类别> 

8.4     人事需求 

8.5     物流需求  

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

10.       已购买组件 

11.            接口               

11.1     用户界面     

11.2     硬件接口     

11.3     软件接口     

11.4     通信接口     

12.            许可需求               

13.            法律、版权和其他声明               

14.            可应用标准               


补充规范

1.                  简介

[补充规范的简介应该提供整个文档的概述。它应该包括这些迭代规范的目的、范围、定义、首字母缩写、缩写、参考资料和概述。]

补充规范找出在用例模型的用例中未发现的系统需求。这样的需求包括:

·         法律和法规需求,包括应用程序标准。

·         待构建系统的质量属性,包括可用性、可靠性、性能和可支持性需求。

·         其他需求,例如操作系统和环境需求、兼容性需求和设计约束。]

1.1               目的

[指定这些补充规范的目的。]

1.2               范围

[这些补充规范所涉及范围的简短描述;它关联的项目和本文档影响的任何其他方面。]

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

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

1.4               参考资料

[本子节应该提供一份在补充规范中的其他地方引用的所有文档的完整列表。应当用标题、报告号(如果有)、日期和出版机构来标识每份文档。指定参考资料的出处。 本处信息可以通过引用附录或另一个文档的形式提供。]

1.5               概述

[此子节应该描述补充规范的剩余部分包含哪些内容,并说明文档是如何组织的。]

2.                  功能

[本节描述了以自然语言形式表示的系统其他一些功能需求。]

2.1               <功能需求一>

[需求描述。]

3.                  可用性

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

·         指定普通用户和高级用户在特定运营中具备实际生产能力所需的培训时间

·         指定典型任务的可计算的任务时间,或

·         指定符合一般可用性标准(例如 IBM 的 CUA 标准或 Microsoft 的 GUI 标准)的需求。]

3.1               <可用性需求一>

需求描述。

4.                  可靠性

[应当在此处指定系统可靠性方面的需求。建议如下:

·         可用性 指定使用、维护访问权、降级方式操作等的可用时间百分比(xx.xx%)。

·         平均故障间隔时间(MTBF) 通常以小时为单位指定,但是也可以按天、月或年为单位指定。

·         平均修复时间(MTTR)在系统发生故障后允许系统中断多长时间?

·          准确性 指定系统输出中所需的精确度(分辨率)和准确性(根据一些已知标准)。

·         最大错误或缺陷率 通常表示为“错误数/KLOC(千行代码)”或“错误数/功能点”。

·         错误或缺陷率 按次要、重要和关键错误进行分类:需求必须定义“关键”错误的含义:例如,数据完全丢失或完全无法使用系统功能的特定部分)。]

4.1               <可靠性需求一>

[需求描述。]

5.                  性能

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

·         交易响应时间(平均时间,最长时间)

·         吞吐量(例如,每秒事务数)

·         容量 (例如,系统能承受的最大客户或交易数)。

·         降级模式(当系统以某种方式降级时,可接受的操作模式是什么)。

·         资源使用情况:内存,磁盘,通信等。]

5.1               <性能需求一>

[需求描述。]

6.                  可支持性

[本节指出所有可提高待构建系统的可支持性或可维护性的需求,包括编码标准、命名约定、类库、维护访问和维护实用程序。]

6.1               <可支持性需求一>

[需求描述。]

7.                  设计约束

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

7.1               <设计约束一>

[需求描述。]

8.        系统工程师其他注意事项

[系统工程可能需要满足其他类型的需求:]

8.1      物理需求

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

8.2      环境需求

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

8.3      其他产品保证需求

8.3.x     <类别>

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

8.4      人事需求

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

8.5      物流需求

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

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

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

10.              已购买组件

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

11.             接口

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

11.1            用户界面

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

11.2            硬件接口

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

11.3            软件接口

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

11.4            通信接口

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

12.             许可需求

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

13.             法律、版权和其他声明

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

14.             可应用标准

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