表格式、数据命名、财务处理、审计追踪等等。
2） 硬件的限制：本项包括在各种硬件约束下运行的软件要求，例如，应该包
括：硬件配置的特点（接口数，指令系统等）、内存储器和辅助存储器的容量。 6.3.1.3 属性
在软件的需求之中有若干个属性，下面指出其中的几个（注意：对这些决不应理解为是一个完整的清单）。
1） 可用性：可以指定一些因素，如检查点、恢复和再启动等，以保证整个系
统有一个确定的可用性级别。
2） 安全性：这里指的是保护软件的要素，以防止各种非法的访问、使用，修
改、破坏或者泄密。这个领域的具体需求必须包括： ? 利用可靠的密码技术；
? 掌握特定的记录或历史数据集； ? 给不同的模块分配不同的功能； ? 限定一个程序中某些区域的通信； ? 计算临界值的检查和。
3） 可维护性：这里规定若干需求以确保软件是可维护的。例如：
? 软件模块所需要的特殊的耦合矩阵；
? 对微型装置指定特殊的数据/程序分割要求。
4） 可转移/转换性：这里规定把软件从一种环境移植到另一种环境所要求的
用户程序，用户接口兼容方面的约束等等。
5） 警告：指定所需属性十分重要，它使得人们能用规定的方法去进行客观的
验证。
6.3.1.4 外部接口要求
1） 用户接口：提供用户使用软件产品是地的接口需求。例如，如果系统的用
户通过显示终端进行操作，就必须指定如下要求： ? 对屏幕格式的要求；
? 报表或菜单的页面打印格式和内容； ? 输入输出的相对时间； ? 程序功能键的或用性。
2） 硬件接口：要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还
可能包括如下事宜：支撑什么样的设备，如何支撑这些设备，有何约定。 3） 软件接口：在这里应指定需使用的其他软件产品（例如，数据管理系统，
操作系统，或者数学软件包），以及同其他应用系统之间的接口。 对每一个所需的软件产品，要提供名字、助记符、规格说明号、版本号、来源等内容。 对于每一个接口，这部分应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，这里不必详细描述任何已有完整文件的接口，只要引用定义该接口的文件即可。
4） 通信接口：这里指定各种通信接口，例如，局部网络的协议等等。 6.3.1.5 其他需求
根据软件和用户组织的特性等，某些需求放在下面各项中描述。
1） 数据库：本项对作为产品的一部分进行开发的数据库规定一些需求，它们
可能包括：
? 在6.3.1.1条中标识的信息类别；
? 用的频率； ? 存取能力；
? 数据元素和文卷描述符；
? 数据元素、记录和文卷的关系； ? 静态和动态的组织； ? 数据保存要求。
注：如果使用一个现有的数据库包，这个包应在“软件接口”中命名，并在那里详细说明其用法。
2） 操作：这里说明用户要求的常规的和特殊的操作。
? 在用户组织之中各种方式的操作。例如，用户初始化操作； ? 交互作用操作的同期和无人操作的周期； ? 数据处理支持功能； ? 后援和恢复操作。
注：这里的内容有时是用户接口的一部分。 3） 场合适应性需求：这里包括：
? 对给定场合、任务或操作方式的任何数据或初始化顺序的需求进行定
义。例如，栅值，安全界限等等。
? 指出场合或相关任务的特点，这里可以被修改以使软件适合特殊配制
的要求。
6.3.2 具体要求的组织
本条通常是SRS所有部分中最大并且最复杂的部分。
1） 可以根据软件实现功能的基本类型，将本条分成若干段。例如：考虑一个
大的交互记帐系统，在里层可以分为操作软件（它支持近乎实时的事务处理）、支撑软件（联机功能、磁盘备份、装入磁带等等）以及诊断软件（诊断硬件、通信等），外一层是应收款帐以及应付款帐等等； 2） 结构细分的目的是提高SRS的可读性，而不是进行概要设计。
对于SRS中的第3章的具体需求部分的最好的组织方案取决于所说明的软件产品的应用范围和性质。 文中最后部分提供了四种可能的组织方案。
1） 大纲1中首先说明全部功能需求，然后说明四种类型的接口要求，最后是
其他需求；
2） 大纲2中，把对应每个特定功能的四种接口需求和该功能需求放在一起描
述，然后说明其他需求；
3） 大纲3中，与功能需求有关的全部内容放在一起首先说明，然后是其他需
求的描述。对每一种外部接口的需求重复上述过程； 4） 大纲4中，接口需求和其余的需求作为每一个功能需求的附属部分来说明。 SRS的具体需求的组织形式必须选择可读性最好的方法来描述。
6.4 支持信息
支持信息是指目录表，附录和索引。以便使SRS易于使用。
1）目录表和索引很重要，而且应按照可以接受的好的文件规则来编写。
2）对一个实际的需求规格说明来说，若有必要应该编写附录。附录中可能包括：
? 输入输出格式样本，成本分析研究的描述或用户调查结果； ? 有助于理解SRS的背景信息； ? 软件所解决问题的描述；
? 用户历史、背景、经历和操作特点；
? 交叉访问表。按先后次序进行编排，使一些不完全的软件需求得以完善（参
见4.3.2条和4.3.3条）；
? 特殊的装配指令用于编码和媒体，以满足安全、输出、初始装入或其他要
求。
3）6.4.3 当包括附录时，SRS必须明确地说明附录是不是需求要考虑的部分。 SRS大纲1 3 具体需求 3.1 功能需求 3.1.1 功能需求1 3.1.1.1 引言 3.1.1.2 输入 3.1.1.3 加工 3.1.1.4 输出 3.1.2 功能需求2 ?? 3.1.n 功能需求n 3.2 外部接口需求 3.2.1 用户接口 3.2.2 硬件接口 3.2.3 软件接口 3.2.4 通信接口 3.3 性能需求 3.4 设计约束 3.4.1 其他标准的约束 3.4.2 硬件的限制???? 3.5 属性 3.5.1 安全性 3.5.2 可维护性???? 3.6 其他需求 3.6.1 数据库 3.6.2 操作 3.6.3 场合适应性???? SRS大纲2 3 具体需求 3.1 功能需求 3.1.1 功能需求1 3.1.1.1 规格说明 3.1.1.1.1 引言 3.1.1.1.2 输入 3.1.1.1.3 加工 3.1.1.1.4 输出 3.1.1.2 外部接口 3.1.1.2.1 用户接口 3.1.1.2.2 硬件接口 3.1.1.2.3 软件接口 3.1.1.2.4 通信接口 3.1.2 功能需求2 ???? 3.1.n 功能需求n 3.2 性能需求 3.3 设计约束 3.4 属性 3.4.1 安全性 3.4.2 可维护性???? 3.5 其他需求 3.5.1 数据库3.5.2 操作3.5.3 场合适应性????
SRS大纲3 3 具体需求 3.1 功能需求 3.1.1 功能需求1 3.1.1.1 引言3.1.1.2 输入3.1.1.3 加工3.1.1.4 输出 3.1.1.5 性能需求 3.1.1.6 设计约束 3.1.1.6.1 其他标准的约束3.1.1.6.2 硬件的限制???? 3.1.1.7 属性 3.1.1.7.1 安全性3.1.1.7.2 可维护性???? 3.1.1.8 其他需求 3.1.1.8.1 数据库3.1.1.8.2 操作3.1.1.8.3 场合适应性 ???? 3.1.2 功能需求2 ???? 3.1.n 功能需求n 3.2 外部接口需求 3.2.1 用户接口 3.2.1.1 性能需求 3.2.1.2 设计约束 3.2.1.2.1 其他标准的约束3.2.1.2.2 硬件的限制???? 3.2.1.3 属性 3.2.1.3.1 安全性3.2.1.3.2 可维护性???? 3.2.1.4 其他需求 3.2.1.4.1 数据库3.2.1.4.2 操作3.2.1.4.3 场合适应性 ???? 3.2.2 硬件接口3.2.3 软件接口3.2.4 通信接口 SRS大纲4 3 具体需求 3.1 功能需求1 3.1.1 引言3.1.2 输入3.1.3 加工3.1.4 输出 3.1.5 外部接口 3.1.5.1 用户接口3.1.5.2 硬件接口 3.1.5.3 软件接口3.1.5.4 通信接口 3.1.6 性能需求 3.1.7 设计约束 3.1.8 属性 3.1.8.1 安全性3.1.8.2 可维护性???? 3.1.9 其他需求 3.1.9.1 数据库3.1.9.2 操作3.1.9.3 场合适应性???? 3.2 功能需求2 ???? 3.n 功能需求n 用例说明模板1(经典模板)
编者说明：
随着UML的日益普及，用例（Use case）分析技术也在需求实践中广泛被采用。但是也有许多团队在使用该技术时，只画出了用例图，而缺少了用例说明，其实这是一个严重的误区。而本模板就将指导你编写该说明。 1.用例名称
1.1 简要说明
[简要说明用例的作用和目的。该小节的篇幅不要太长。]
2.上下文图
[在此小节中，有一个只包括本用例和所有与该用例相关的Actor和其它用例组成的，一个用例图的局部。] 3. 事件流
3.1 基本流
[当Actor采取行动时，用例也就随即开始。用例总是由Actor启动的，用例应说明Actor的行为及系统的响应，可按照Actor与系统进行对话的形式来逐步引入用例。]
[要注意的是，用例描述应该说明系统内发生的事情，而不是事件发生的方式与原因。如果进行了信息交换，则需指出来回传递的具体信息。例如，只表述主角输入了客户信息就不够明确。最好明确地说主角输入了客户姓名和地址。当然你也可以通过项目词汇表来定义这些信息，使得用例中的内容被简化，从而不致于让用例描述陷入过多的细节内容。]
[如果存在一些相对比较简单的备选流，只需少数几句话就可以说明清楚，那么也可以直接在这一部分中描述。但是如果比较复杂，还是应该单独放在备选流小节中描述。]
[一幅图胜过千言万语，因此建议在这一小节中，除了叙述性文字之外，你还可以引用UML中的活动图、顺序图、协作图、状态图等手段，对其进行补充说明。]
3.2 备选流
3.2.1 第一备选流
[正如前面所述，对于较复杂的备选流应单独地说明。] 3.2.1.1 备选支流
[如果能使表达更明确，备选流又可再分为多个支流。] 3.2.2 第二备选流
[在一个用例中很可能会有多个备选流。为了使表达更清晰，应将各个备选流分开说明。使用备选流可以提高用例的可读性，并防止将用例分解为过多的层次。应切记，用例只是文本说明，其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。]
4. 非功能需求
[在这个小节中，主要对该用例所涉及的非功能性需求进行描述。由于其通常很难以在事件流中进行表述，因此单列为一小节进行阐述。这些需求通过包括法律法规、应用程序标准、质量属性（可用性、可靠性、性能、支持性等）、兼容性、可移植性，以及设计约束等方面的需求。在这些需求的描述方面，一定要注意使其可度量、可验证，否则就容易流于形式，形同摆设。] 5. 前置条件
[用例的前置条件是执行用例之前必须存在的系统状态。] 6. 后置条件
[用例的后置条件是用例一执行完毕系统可能处于的一组状态。] 7. 扩展点
[此用例的扩展点，通常是用例图中的extent关系。]
