第6章 需求开发与管理
软件需求是整个软件研发的基础，无论是软件开发工程师还是软件测试工程师本质上都是依赖软件需求来开展工作的，因此产生了软件需求工程（Requirement Engineering，RE）。软件测试工程师也需要对需求工程有所了解，尤其是需求管理的部分。
6.1 需求
理解需求管理的第一步就是对什么是需求达成共识。软件行业存在的一个问题就是缺乏统一定义的名词术语来描述对应的工作。客户所定义的“需求”对于开发者似乎是一个较高层次的产品概念，而开发人员所说的“需求”对于用户来说又像是详细设计。实际上，软件需求包含多个层次，不同层次的需求从不同角度与不同程度反映了细节问题。
6.1.1 什么是需求
IEEE软件工程标准词汇表（1997年）中需求的定义如下。
●用户解决问题或达到目标所需的条件或权能（capability）。
●系统或系统部件要满足合同、标准、规范或其他正式规定文档应具有的条件或权能。
●一种反映第1条或第2条所描述的条件或权能的文档说明。
需求不仅包括通常意义上的产品功能，而且包括行业规范中定义的标准。例如，对于相应的产品来说，银行的行业技术规范、电信的入网标准等都是需求，我们在开发行业软件时需要结合这些标准来分析需求。当我们开发一款手机时，一定要了解移动行业的规范，不能说手机可以通话、发短信了，即满足了手机通信功能；而在设计开发一款财务系统时，一定要了解其行业背景，不能孤立地看问题。
举个简单的例子，用户要我们生产一款榨汁机，用户想要的榨汁机的需求如下。
●功能：能够榨豆浆、水果汁（苹果、梨、西瓜……）。
●性能：榨1kg黄豆需要1h。
●耗能：榨1kg黄豆的耗电量1kW·h。
●安全性：榨汁过程中有人体安全防护措施，有漏电保护。
●可靠性：榨汁机能持续稳定运转1h。
●易用性：榨汁机的操作简单方便。
这些需求是不是已经很详细了？能够开始生产了吗？
回答：不行。就这么一个小小的榨汁机，我们同样要考虑行业背景，像家电的3C标准，如果要销往不同的国家，其插头和电源标准也是不一样的，在英国、法国等国家的标准都不同，如果不考虑这些背景，生产出来的榨汁机即使运到销售地，也卖不出去。
6.1.2 需求的类型
需求有不同的类型，各组成部分之间的关系如图6-1所示。
图6-1 需求各组成部分之间的关系
1．业务需求
业务需求（business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用项目愿景和范围（vision and scope）文档来记录业务需求，这份文档有时也称为项目轮廓图（project charter）或市场需求（market requirement）文档。
以自动取款机（Automatic Teller Machine，ATM）为例，从银行业务人员的角度来看，ATM能够代替柜员执行存取款操作，节约劳动力成本。这就是ATM的业务需求。
2．用户需求
用户需求（user requirement）描述的是用户的目标，或用户要求系统必须完成的任务。场景描述和事件响应表都是表达用户需求的有效途径，即用户需求描述了用户能使用系统来做些什么。
为了得到一台可用的ATM，用户应该把ATM实现的功能描述出来，这就是ATM的用户需求，如自动存款，自动取款，账务查询，密码验证，出错处理，……
3．系统需求
系统需求（system requirement）用于描述包含多个子系统的产品（系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件子系统又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
ATM简单地分为软件子系统和硬件子系统，软件部分主要实现用户验证、存取款的账务处理、远程通信等功能，而硬件部分主要实现吞吐卡、触摸屏、点/验钞机等功能。
4．功能需求
功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也称为行为需求（behavioral requirement），因为习惯上总是用“应该”对其进行描述，如“系统应该发送电子邮件来通知用户已接受其预订”。功能需求描述开发人员需要实现什么。
ATM的软件功能需求如下。
（1）用户登录。
●验证卡的合法性和正确的密码后，用户才能登录。
●本行卡……
●外行卡……
●密码出错……
（2）取款。
●取款金额合法性判断。
●账户扣款处理。
●手续费……
业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定操作，或者，规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，当对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
ATM应该遵守银行电子系统相关的规范，如《银行计算机信息系统安全技术规范》中对系统中网络安全的规定，要求ATM与后台服务器之间的网络通信必须是高度安全的，必须采用加密机制。
5．软件需求说明书
软件需求说明书（Software Requirement Specification，SRS）中的功能需求充分描述了软件系统所应具有的外部行为。软件需求说明书在开发、测试、质量保证、项目管理及相关项目功能中都起了重要的作用。对于一个复杂的产品来说，软件功能需求也许只是系统需求的一个子集。
作为功能需求的补充，软件需求说明书还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。软件需求说明书包括产品必须遵从的标准、规范和合约，外部接口的具体细节，性能要求，设计或实现的约束条件及质量属性。约束是指对开发人员在软件产品设计和构造上的限制；质量属性通过多种角度对产品的特点进行描述，从而反映产品功能。
从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是客户究竟想开发什么样的软件产品。项目也有其他方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。
版权声明：51Testing软件测试网获得人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
