描述软件需求

软件需求的定义

IEEE软件工程标准词汇表(1997年)中把传统软件需求定义为：

1. 用户解决问题或达到目标所需的条件或权能；
2. 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能；
3. 一种反映上面1或2所描述的条件或权能的文档说明。

需求分析工作的成果是需求分析文档。

软件需求的组成

图 1 软件需求的组成

软件需求由高到低可以分为三种不同的层次：业务需求、用户需求、功能需求。每个层次的需求代表了不同层次的需求特征。

业务需求：反映组织机构和客户对系统、产品高层次的目标要求。

用户需求：从用户使用的角度给出需求的描述。

系统需求：从系统的角度描述要提供的服务以及所受到的约束。

功能性需求：描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务。

非功能性需求：产品必须具备的属性或品质。

设计约束：设计与实现必须遵循的标准、约束条件。如运行平台、协议、选择的技术、编程语言和工具等。

例子：旅游服务公司需要一个机票预定系统。 业务需求：旅客需要查询航空公司的机票来预定机票；航空公司需要根据具体场景来销售或下架机票。 用户需求: 这两类用户怎样去查询系统，查询哪些信息，还需要哪些操作。

具体来说，可以将系统的需求分为功能需求和非功能需求两大类，具体可以分为如下8种类型：

功能需求

这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。

例如：如果旅客预定机票过程中没有指定座位偏好，机票预订系统就应当随机为它分配。

非功能需求

非功能需求描述了系统必须展现的属性或特性和必须要遵守的约束，包括系统在性能、可靠性和可用性、接口、约束等方面的特征。

性能需求

性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。

例如：机票预定系统所支持的用户在线人数至少为50000。

可靠性和可用性需求

可靠性需求定量地指定系统的可靠性。 可用性与可靠性密切相关，它量化了用户可以使用系统的程度。

例如：机票预定系统在一个月内发生故障的次数低于三次，体现了系统的可靠性需求。

在任何时刻系统中的服务器或备份服务器至少有一个是可用的，体现了系统的可用性需求。

出错处理需求

这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这类错误并不是由该应用系统本身造成的。 在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖自己的错误。总之，对应用系统本身错误的检测应该仅限于系统的关键部分，而且应该尽可能少。

例如：系统中若某个节点因负载过高停止运行时需要有一定的错误处理机制如启动备份节点来保证系统的正常运行。

接口需求

接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。

例如，系统应该提供第三方登录接口，客户端必须通过post请求的方式来向服务端系统请求数据。

约束

设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。在需求分析阶段提出这类需求，并不是要取代设计(或实现)过程，只是说明用户或环境强加给项目的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。

例如，系统应该满足跨平台的特性，应用所使用的所有文本数据将以XML格式的文件进行存储等。

逆向需求

逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。

例如：一个用户账号不允许多个设备同时登录。

将来可能提出的需求

应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。

例如：系统要尽可能地考虑向后兼容性，为下代版本更新留出预留空间。