任务:制定补充规范
此任务记录不适用于具体用例的需求。
规程:需求
用途
记录那些无法在用例中记录的需求。
关系
主要描述

在需求活动中,根据已收集的项目干系人请求,需在补充规范中记录不适用于具体用例的需求。在补充规范中可以记录功能需求和非功能需求。 

关于分类和记录需求的更多信息,请参阅概念:需求

执行此任务时,确保以所需的详细级别指定了所有需求以便传递给设计人员、测试人员和文档编写人员是十分重要的。如果需求得到跟踪或其他形式的正式管理,请确保每个需求都明确地标识并标注出来。

步骤
记录非特定于用例的功能需求

功能需求描述支持用户目标、任务或活动的系统行为(功能或服务)[MAL2001]

虽然许多功能需求将记录到用例中,但有一些功能需求无法应用到具体的用例。例如,报告、审计、打印、安全性、许可支持/实施、认证需求等。这些功能需求应记录在“补充规范”中。  

如果存在大量系统范围的功能需求,则考虑此部分的组织方法是十分重要的。典型的组织方法是按功能/功能集进行组织,但是还有另外的组织方法。例如,按用户进行组织或按子系统进行组织同样适用。

功能需求代表“FURPS+”中的“F”。关于“FURPS+”的更多信息,请参阅概念:需求

记录系统质量

非功能需求包含质量和约束[MAL2001]。在此步骤中,我们将讨论质量。约束将在独立的步骤中讨论。

[系统] 质量是项目干系人所关心的系统属性和特征,因而将影响他们对系统的满意度。[MAL2001]

质量代表“FURPS+”中的“URPS”。这些需求类别涉及的问题如下:

  • 可用性(U):用户界面的美观与一致性。
  • 可靠性(R):可用性(系统的运行时间量)、系统计算的准确性和系统从故障中恢复的能力。
  • 性能(P):吞吐量、响应时间、恢复时间、启动时间和关闭时间。
  • 可支持性(S):可测性、适应性、可维护性、兼容性、可配置性、可安装性、可伸缩性和可本地化性。

关于“FURPS+”和记录非功能需求的更多信息,请参阅概念:需求

根据要为系统记录的质量类型的数量,可为这些质量类型提供子节。

以下各节提供了可为这些质量类型记录的信息的一些示例: 

可用性

当描述可用性需求时,可指定:

  • 普通用户和高级用户在达到可高效执行特定操作方面所需的培训时间
  • 典型任务的可度量任务时间
  • 符合常用可用性标准的需求,例如,IBM 的 CUA 标准或 Microsoft 的 GUI 标准

可靠性

描述可靠性需求时,可指定:

  • 可用性 - 指定可用时间的百分比(xx.xx%)、使用的小时数、维护访问和降级模式操作等。
  • 平均故障间隔时间(MTBF)- 通常以小时数指定,但是也可以按天数、月数或年数指定。
  • 平均修复时间(MTTR)- 在系统发生故障后,允许系统不运行的时间。
  • 准确性 - 指定系统输出中所需的精确度(分辨率)和准确性(根据一些已知标准)。
  • 最大错误或缺陷率 - 通常表示为“错误数/KLOC(千行代码)”或“错误数/功能点”。
  • 错误或缺陷率 - 按次要、重要和关键错误进行分类:需求必须定义“关键”错误的含义;例如,数据完全丢失和完全无法使用系统功能的特定部分。

性能

描述性能需求时,可指定:

  • 事务的响应时间(平均、最大)
  • 吞吐量(例如,每秒事务数)
  • 容量(例如,系统可容纳的客户或事务数量)
  • 降级模式(当系统以某种方式降级时,可接受的操作模式是什么)
  • 资源使用:内存、磁盘和通信等

当记录性能需求时,请确保其中包含了特定的响应时间。在适用时,按名称引用相关的用例

可支持性

描述可支持性需求时,可指定:

  • 编码标准
  • 命名约定
  • 类库
  • 维护访问
  • 维护实用程序
记录约束

在此步骤中,您记录关于要构建的系统的所有设计约束。概括而言,约束就是在提供解决方案时存在的自由度方面的限制 [LEF2000]。设计约束代表要求执行的设计决策,必须遵守。 

约束代表“FURPS+”中的“+”,它可进一步进行分类,如下:

  • 设计约束:指定或限定系统的设计选项。例如,要求使用关系数据库来保证持久性。
  • 实施约束:指定或限定系统的编码或构造。例如,所要求的标准、流程、工具、实施语言、硬件平台、操作系统、第三方组件、类库和资源限制(内存或磁盘空间使用量)。
  • 接口约束:指定系统必须交互的外部项,或者限定在这种交互中使用的格式或其他因素。例如,通过消息队列与外部系统进行对接。
  • 物理约束:指定施加于容纳系统的硬件的物理约束,例如形状、大小或重量。

根据要为系统记录的约束数量,可为这些约束类型提供子节。 另外:

  • 如果需求中包含购买第三方组件,请确保记录下所有适用的许可或用途限制,以及所有关联的兼容性/互操作性或接口标准。建议对每个购买的组件使用独立的小节。
  • 如果需求中包含特定的接口/界面需求,则建议为不同的接口/界面(例如,用户界面、硬件接口、软件接口)提供独立的小节。对于每种接口/界面,请确保包含足够的特性、协议、端口和逻辑地址等,从而软件可按接口/界面需求进行开发和验证。特别是:
    • 对于用户界面,描述要由软件实施的用户界面。
    • 对于硬件接口,包含逻辑结构、物理地址、期望的行为等。
    • 对于软件接口,包含到软件系统的其他组件的接口的描述。 这些组件可以是购买的组件、从另一个应用程序复用的组件,或者是正在为处于本系统范围之外但此软件应用程序必须与之对接的那些子系统开发的组件。

关于“FURPS+”和记录约束的更多信息,请参阅概念:需求

记录符合性需求

通过符合性,可以包含标准的符合性(包括法规标准、编码标准或用户界面风格指南)、法律免责声明、担保、版权声明、专利权声明、字标、商标和/或徽标的符合性。

符合性需求可通过其他需求(功能性、非功能性和约束)来实现。在这些示例中,这些需求的详细信息应记录在前几个步骤中描述的“补充规范”的适用部分。但是,总结系统必须遵守的标准和策略是十分重要的。必要时,生成的符合性需求可引用适用的详细需求。

根据要为系统记录的符合性需求数量,可为影响系统的不同种类的符合性提供子节。

以下各节提供了可为不同种类的符合性记录的信息的一些示例:

许可需求

定义要由软件展示出的所有许可实施需求或其他使用限制需求。

法律条款、版权和其他声明

描述软件所有必需的法律免责声明、担保、版权声明、专利权声明、字标、商标或徽标符合性声明。

适用的标准

(通过引用)描述任何适用的标准,以及这些标准的特定部分,这些标准适用于所描述的系统。例如,其中可包含法律、质量和法规标准,以及可用性、互操作性、国际化、操作系统符合性等的工业标准。

记录文档需求

在此步骤中,描述关于文档的需求(如果有)。文档需求中可包含关于联机帮助及最终用户文档的需求(例如,安装指南、用户指南、培训材料等)。.  

与符合性需求类似,文档需求会推动其他类型的需求。特别是功能需求(系统必须对联机帮助的功能访问提供支持)和可用性需求(对支持系统整体可用性的系统使用情况信息的按需访问)。 

因此,与符合性需求相似,支持文档需求的详细需求应记录在前几个步骤中描述的“补充规范”的适用部分,但记录和概括系统的整体文档需求也是十分重要的。 所生成的需求可以引用适用的详细需求。

根据要为系统记录的文档需求数量,您可能希望为要对系统提供的不同种类的文档提供子节。

关键注意事项

跨用例的需求(可能是系统范围的需求)通常会推动系统体系结构的开发。事实上,在某些项目中,这样的需求明显比其特定于领域(或特定于用例)的需求更为重要。例如,如果要开发医疗生命支持系统,则可靠性需求将是关键。

不幸的是,这样的需求通常很难收集,且常常被忽视。此任务描述了收集这些需求的总体方法。关于使用特定问卷收集这些需求的“系统”方法,请参阅 [EEL2004]

更多信息