需求定义为“系统必须遵循的条件或能力”。

有许多不同种类的需求。有一种对需求分类的方式可描述为 FURPS+ 模型 [GRA92],使用首字母缩略词 FURPS 来描述主要的需求类别,其子类别显示如下。

FURPS+ 中的“+”提醒您要包含如下的需求:

(另请参阅 [IEEE Std 610.12.1990]。)

功能需求指定系统必须能够执行的操作,而不考虑物理约束。这些通常在用例模型用例中作了最好的描述。因此功能需求指定了系统的输入和输出行为。

非功能方面的需求(如以下列出的需求)有时称为非功能需求。许多需求是非功能的,仅描述系统的属性或系统环境的属性。虽然其中有一些需求可以在用例中捕获,但那些无法如此捕获的需求可以在补充规范中指定。非功能需求是解决诸如下述问题的那些需求。

软件需求的完整定义、用例补充规范可以封装在一起,来为某个“特性”或其它子系统分组定义软件需求规范(SRS)

功能 回到页首

功能需求可以包括:

  • 特性集合
  • 能力
  • 安全性

可用性 回到页首

可用性需求可以包括如下的子类别:

可靠性 回到页首

要考虑的可靠性需求如下:

  • 故障的频率和严重性
  • 可恢复性
  • 可预测性
  • 准确性
  • 平均故障间隔时间(MTBF)

性能 回到页首

性能需求对功能需求施加了以下条件。例如,对于给定操作,它可能会指定有关以下项的性能参数:

  • 速度
  • 效率
  • 可用性
  • 准确性
  • 吞吐量
  • 响应时间
  • 恢复时间
  • 资源使用率

可支持性 回到页首

可支持性需求可以包括:

  • 可测试性
  • 可扩展性
  • 适应性
  • 可维护性
  • 兼容性
  • 可配置性
  • 可服务性
  • 可安装性
  • 本地化(国际化)

设计需求 回到页首

设计需求(通常称为设计约束)指定或约束系统的设计。

实施需求 回到页首

实施需求指定或约束系统的编码或构造。示例有:

  • 必需的标准
  • 实施语言
  • 数据库完整性策略
  • 资源限制
  • 操作环境

接口需求 回到页首

接口需求指定:

  • 系统必须与之交互的外部项
  • 对格式、计时或此类交互所使用的其它因子的约束

物理需求 回到页首

物理需求指定系统必须拥有的物理特征;例如:

  • 材料
  • 形状
  • 大小
  • 重量

此类需求可用于表示硬件需求,如必需的物理网络配置。

更多信息

可在以下部分找到关于此主题的更多信息:



Rational Unified Process   2003.06.15