第1章
软件需求的本质
“喂，Phil吗？我是人事部的Maria。我们在使用你开发的人事系统时遇到一个问题。有位职员刚刚把她的名字改成Sparkle Starlight，但我们无法在系统中改。你能帮个忙吗？”
“那么她是结婚了，随老公姓Starlight？”
“没有，她没结婚，只是改名字了，”Maria回答道，“问题就出在这里。好像我们只能在某人婚姻状况发生变化时才能在系统中改名。”
“好吧，是，我从来没想过有人可能会改自己的名字。当初我们在讨论系统的时候，你可没告诉过我有这种可能性。” Phil答道。
“我以为你知道任何人随时都可以合法更改名字呢，”Maria回应道，“我们得在星期五之前解决这个问题，否则Sparkle就领不到工资了。你可以在此之前修复这个bug吗？”
“这不是什么bug，好吗？！” Phil反驳道，“我从没想过你们需要这项功能。我现在正忙着做一个新的绩效评估系统。你所说的问题我只能在月底修复，但周五之前肯定不行，抱歉。下次如果再有类似情况，请早点告诉我，并请提供书面材料。”
“那我怎么和Sparkle说呢？”Maria追问道，“如果她领不到工资，会很难过的。”
“嗨，Maria，这不是我的错，”Phil抗议道，“如果当初你早提醒我你需要能够随时更改某人的姓名，这种事情就不会发生。你不能因为我没猜透你的想法就怪我。”
Maria怒了，但又无可奈何，只好厉声说：“是，你说的都对！好吧，这种破事儿让我对电脑简直是恨之入骨。问题解决好了，就马上打电话告诉我，可以吗？”
如果你是以上对话中的客户一方，就会明白无法使用软件系统来完成一项基本任务多么令人沮丧。你会痛恨自己得求着开发人员，因为关键变更请求最终掌握在他们手中。另一方面，开发人员也很沮丧，因为他们只有在系统开发完成之后才会明白用户期待有哪些基本功能。对于开发人员来说，更恼火的是，得中断手头的项目去修正以前已经完成的系统（因事先未被明确告知而疏忽的需求）。
软件中的很多问题大多数来源于人们了解、记录、协商和修改产品需求的方法不当。就Phil和Maria这个例子而言，问题就包括：信息收集不正规；功能隐晦；对假设功能有理解上的分歧；需求指定不明确以及变更过程不正规。很多研究表明，软件产品中发现的缺陷有40%～50%是在需求阶段埋下的“祸根”（Davis 2005）。在具体说明客户需求和管理客户需求过程中用户输入不足和有误，是造成项目失败的罪魁祸首。尽管证据确凿，但很多组织仍然在实行这些没有什么成效的需求方法。
在软件项目中，所有干系人的利益交接点主要集中在需求方面。（更多干系人方面的内容，参见第2章）这些干系人包括客户、用户、业务分析人员和开发人员等。如果处理得当，这种交接既可以让客户满意，又能鼓舞开发人员。若处理不当，则会引发误解和摩擦，最终降低产品质量和业务价值。正是由于需求是软件开发和项目管理活动的基础，因此所有干系人都应该致力于需求实践活动，这是打造一流产品的前提。
但开发和管理需求确实很难！既没什么捷径，也没有任何灵丹妙药。另外，很多组织都在朝着一个目标努力，要找到一种能适应不同情景但又有共性的技术。本书后面将讲到很多这样的实践。这些实践假定你正在开发一种全新的系统。但是，它们中的多数也可用于改进、替换以及重构项目（详见第21章），还可以用于融合商业现成品的（COTS）打包解决方案项目（详见第22章）。即使项目团队遵循敏捷开发过程渐进式构建产品增量，团队也要理解每一个增量所涉及的需求（详见第20章）。
本章将帮助你：
* 理解软件需求领域所用的一些关键术语；
* 区分产品需求和项目需求；
* 区分需求开发和需求管理；
* 警惕可能出现的与需求相关的一些问题。
给自己的需求把把脉
要想对组织中现有的需求实践做一次快速体检，就对比下列问题，看看有多少条出现于你最近的项目中。如果其中有三四条以上与你的经历相符，那么本书就是为你量身定做的。
* 从来没有清晰制定过项目的业务目标、愿景和范围。
* 客户太忙，没有时间与分析师或开发人员共同处理需求。
* 团队无法与用户代表直接互动，不理解他们的具体需要。
* 客户认为所有的需求都很关键，因此没有对需求排定优先级。
* 开发人员在写代码时遇到了模棱两可或者遗漏的信息，所以只能靠猜。
* 开发人员与干系人沟通的重点集中于用户界面展示或者特性，并没有关注用户要使用软件完成的具体任务。
* 需求从来没得到过客户的认可。
* 客户认可了某个发布或者迭代的需求，但事后又不断更改。
* 不断接受客户的需求变更请求，项目范围随之扩大，由于没有增加资源或者删减功能，进度最后完全被打乱。
* 有人提出了变更请求，但被忽略，没人知道特定变更请求的具体状态。
* 客户提出特定的功能要求，而且开发人员也建好了，但就是没有人用过。
* 在项目接近尾声时，虽然满足规范说明，却不满足客户或业务的目标。
软件需求的定义
人们在讨论需求时，开始经常会遇到专业术语问题。人们从不同的角度阐述同一样东西，例如：用户需求、软件需求、业务需求、功能需求、系统需求、产品需求、项目需求、用户故事、特性或者约束条件。人们又赋予了不同的需求交付物多种称谓。对于开发人员来说，客户所定义的需求听起来更像是一种高级产品概念。对于用户来说，开发人员所说的需求理念可能听起来更像一种具体的用户界面设计。这种理解上的偏差让人困惑，令人沮丧。
关于“需求”的一些解释
即使计算机编程技术已经有很多年头，软件从业者仍然在激辩“需求”的准确定义。我们不想在本书中继续这种争论，只想从实用定义的角度简单表述一下。
顾问布莱恩·劳伦斯（Brian Lawrence）认为，需求是“任何能够驱动设计做出选择的东西。”这种口语化定义不错，因为很多信息都印证了他的说法。毕竟，开发需求的目的就是要做出合适的设计选项，最终满足客户需要。另外一种定义认为需求是产品所必备之属性，目的是向干系人提供价值。这也没错，但不太准确。我们比较倾向于Ian Sommerville and Pete Sawyer （1997）所提出的观点：
需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。
这个定义认为“需求”是多种不同类型的信息的统称。需求涵盖来自客户视角的外部系统行为以及来自开发人员视角的一些内部特征。它们包含系统在特定条件下的行为和属性，使目标用户觉得系统易于甚至乐于上手。
字典中的“需求”
字典对“需求”的解释为：“被命令或者强制性的东西；需要或者必要。”这与软件界所使用的“需求”不是一个含义。人们有时会怀疑是否有必要对需求进行优先级排序，因为有的低优先级需求可能永远不会被实现。人们认为如果对某些东西的需求不是太强烈，就说明它们不是需求。可能是这样，但我们管这类信息叫什么？如果将当前项目中的需求推迟到未来某个不确定的发布之中，它还是需求吗？当然是。
软件需求包含一个时间维度。它们可能是描述目前系统性能的现在时。或者它们可能是近期（高优先级）、中期（中等优先级）或者想象中（低优先级）的未来。甚至可能是过去时，也就是那些曾经被人指定但后来又被舍弃的需要。我们没必要浪费时间争论某个东西是否是需求，即使知道自己会为了某个合理的业务原因而永远不执行它。需求就是需求。
需求的层次和种类
由于有很多不同类型的需求信息，所以我们现在需要用一组形容词来修饰一下被人们赋予太多意义的“需求”。表1-1列出了需求领域的一些常用术语。
表1-1 一些类型的需求信息
术语
定义
业务需求
开发产品的组织或者获取产品的客户所需的高层次业务目标
业务规则
策略、纲领、标准或者制度，能够定义或者约束某些方面的业务。虽然本身并不是软件需求，但它却是一些类型的软件需求的鼻祖
约束
对开发人员在产品设计和构建上的限制条件
外部界面需求
对软件系统和用户、其他软件系统或硬件设备间的关联进行说明
特性
单个或者多个为用户提供价值的、有逻辑关系的系统性能，可以通过一个功能需求集合进行描述
功能需求
描述系统在特定条件下展现的行为? 续表
术语
定义
非功能需求
描述系统必须展现的属性或者特性，或者必须遵守的约束
质量属性
一种非功能需求，描述的是服务或者一个产品的性能特征
系统需求
包含多个子系统的产品的顶层需求，子系统可以是软件，也可以是软硬件
用户需求
特定用户群必须能够用系统所完成的目标或任务，或者是用户期望有的产品属性
软件需求有三种不同的层次：业务需求、用户需求和功能需求。此外，每个系统都包含某种类别的非功能需求。不同种类的需求如图1-1中的模型所示。正如统计学家乔治E.?P.?巴克斯（George E. P. Box）的一句名言所述：“从本质上讲，虽然一切模型都是错误的，但有些还是有作用的。”（Box and Draper 1987）。这句话用来形容图1-1真是恰如其分。这个模型也许并不全面，但提供的方案非常实用，可以帮助组织需求方面的知识。
图1-1所示椭圆中的内容代表需求信息的种类，长方形表示储存信息的文件。实线箭头表示具体类型的信息通常储存于所示文件之中。（业务规则、系统需求应与软件需求独立存储，例如存储在业务规则目录或者系统需求规范说明之中。）虚线箭头代表一种信息起源于或者受另外一种信息的影响。此图没有具体展示数据需求。数据受控于功能，因此数据需求贯穿于这三个层次的需求之中。第7章有很多这些不同种类的需求信息的示例。
图1-1 各类需求之间的关系。实线代表“被存储于”；虚线代表“起源”?或“影响”
业务需求描述组织为什么要执行系统（组织希望获得的业务收益）。其关注点在于组织或者提出系统要求的客户有哪些业务目标。我们假设有家航空公司打算把机场的柜台工作人员成本降低25%。为此，人们通常想到的是建一个自助服务终端，供乘客在机场自行检票。项目的出资方、目标客户、实际用户的管理层、市场部门或者产品规划部门一般都会有业务需求。我们喜欢将业务需求记录在愿景或者范围文件之中。还有一些战略性指导文件有时也会用于此目标，包括项目图表、业务实例以及市场（或者营销）需求文件。第5章的主要内容是对业务需求进行详细说明。考虑到本书的主旨，我们假定已经确定了业务需求或市场机遇。
用户需求描述了用户使用产品必须完成的目标或者任务，并且这个产品要能够为人提供价值。用户需求主要还包括对用户满意度最为关键的产品特性或特征的描述。用例（Kulak and Guiney 2004）、用户故事（Cohn 2004）以及事件响应表都是用户需求的表示方式。理想状态下，这种信息由实际用户代表提供。用户需求表达的是用户通过系统来完成哪些具体工作。通过航空公司网站或者机场自助检票机“办理登机手续”是“用例”的典型例子。如果将其写为“用户故事”，同样的用户需求可能是这样的：“作为一名乘客，我想办理登机手续，以便能够登机。”还有一点我们不能忘记，即大多数项目都有若干个用户类别和其他干系人，我们还必须获取它们的需求。第8章将对这种层次的模型进行解释。有些人喜欢用“干系人的需求”这个更广义的术语来说明各类干系人比直接客户更能提供需求。这当然没有问题，但是我们要在这个层级集中注意力，理解实际用户要用这个产品完成哪些具体目标。
功能需求说的是产品在特定条件下所展示出来的行为，主要描述开发人员需要实现的功能以便用户能够完成自己的任务（用户需求），进而满足业务需求。这三种需求环环相扣，对项目的成功至关重要。人们经常将功能需求记录为传统意义上的“应当”句式：“乘客应当能够随时打印自己已经办好登机手续的所有航段的登机牌”或者“如果乘客信息没有指定座位偏好，航班预订系统就应当为它分配。”
业务分析师（BA）①将功能需求记录在软件需求规范说明（software requirements specification，SRS）之中，尽可能详尽地描述人们对软件系统的预期行为。SRS用于开发、测试、质量保障、项目管理和相关项目功能。它的称谓很多，包括业务需求文件、功能规范说明、需求文件等。SRS可以是一个报告，由存储在需求管理工具中的信息所生成。由于它已成为一种行业标准术语，所以我们在本书中将其统称为“SRS”（ISO/IEC/IEEE 2011）。要想进一步了解SRS，请参见第10章。
系统需求描述了人们对某个产品的需求，而这个产品由多个组件或者系统子集组成（ISO/IEC/IEEE 2011）。“系统”在此不单单是信息名义上的系统。所有软件或软件、硬件系统子集都可以算是系统。甚至人和过程也是系统的一部分，因此某些特定的系统功能可以分配给人。有些人使用“系统需求”这个词来表达对软件系统的具体需求，但我们在本书中并不这样使用该术语。
超市收银员的工作台算是“系统”的一个典型例子。超市里有与称重设施相连的条形码扫描仪和手持式条形码扫描仪。收银员有键盘、显示器和现金抽屉。我们在超市里面还可以发现用于刷积分卡、信用卡或者借记卡的读卡器和PIN盒，甚至还有自动找零机。甚至还可以看到三台打印机分别打印购物小票、信用卡签单和优惠券，只不过这些对你来说无关紧要。这些硬件设备都在软件控制下互相关联。随后，业务分析师根据系统或者产品的整体需求提取具体功能，将其分配给这些组件系统子集中的某一个，同时了解它们之间的接口。
业务规则包括公司政策、政府法规、工业标准以及计算算法。在第9章中，将说明业务规则本身并不是软件需求，因为它的存在已经超出了任何特定软件应用的范围。然而，它们又经常决定着系统为了切合相关规则而必须包含哪些功能。正如公司安全策略一样，业务规则有时又引申出具体的质量特性，这些特性又以功能的方式由开发人员实现。因此，特定的功能需求可以追溯到具体的业务规则。
除了功能需求，SRS还包含某些类别的非功能需求。质量属性也被人们称为质量因子、服务需求质量、约束以及“***性”。它们从不同角度描述产品特征，例如性能、安全性、易用性和可移植性，这些对于用户、开发人员和维护人员来说都非常重要。还有一些非功能需求描述系统与外部世界的接口，包括与其他软件系统、硬件组件、用户以及沟通界面的关联。在创建产品的过程中，开发人员的选择受限于设计和实现约束。
非功能需求到底是什么？
要想对组织中的现有需求实践做一次快速体检，就需要对比下列问题，看看有多少条出现于你最近的项目。如果其中有三四条以上与你的经历相符，那么本书就是为你量身定做的。
在项目接近尾声时，虽然满足了规范说明，却不满足客户或业务的目标。
多年以来，人们从广义上将软件产品需求分为功能需求或者非功能需求。功能需求理解起来很容易，它们描述的是系统在不同条件下能够被用户观察到的行为。然而，大多数人都不喜欢“非功能”这个术语。因为这个形容词强调的是需求不是什么，并没有说明需求是什么。很遗憾，对于这个问题，至今没有一个令人满意的答案。
功能之外的需求强调的并不是系统要做什么，其重点在于系统做得有多棒。它们对系统最重要的特征或属性进行描述，包括系统的易用性、易用性、安全性和性能等很多特征，这些都在第14章中有所体现。有些人将非功能需求等同于质量属性，但这过于狭隘。例如，设计和实现约束也是非功能需求，外部接口需求也是。
还有其他一些非功能需求，它们描述的是系统运行环境，例如平台、可移植性、兼容性和约束。很多产品还受兼容性、监管和发行许可的影响。我们甚至还要考虑到产品的地域性需求，例如用户的文化、语言、法律、货币、专有名词、拼写和其他特征。虽然此类需求被归入功能需求，但业务分析师仍然可以从中获得大量的功能，确保系统的所有行为和属性符合用户的预期。
尽管有其局限性，但由于没有一种合适的替代选项，所以我们在本书中仍使用“非功能需求”这一术语。这类信息的名称是否准确并不重要，但要保证将它们纳入需求获取和分析活动。交付的产品虽然囊括所有预想的功能，但用户还是不喜欢，因为它不符合人们对其产品质量（通常未明确表达）的预期。
一个特性包含一个或者多个逻辑上有关联的系统功能，能够为用户提供价值，这些由一组功能性需求来共同描述。客户预想的产品特性清单与描述客户的任务相关的需求不能画等号。网页浏览器的书签、拼写检查、为运动器械设定定制锻炼程序、杀毒软件中病毒库的自动升级，这些都是典型的特性。特性包含多种用户需求，每种需求都表示特定的功能需求必须实现，以便用户能完成用户需求中所描述的任务。图1-2就是一个特性树，也可以说是一个分析模型，展示的是特性如何层层分解为更小的特性组，这些小特性与具体的用户需求关联，最终引出功能需求（Beatty and Chen 2012）。
图1-2 特性、用户需求和功能性需求之间的关系
为了解释这些不同类型的需求，我们假设在开发某个文本编辑程序的新版本。“在6个月内将非美国地区的销量增加25%”可以算是一种业务需求。市场部发现参与竞争的产品只有英语拼写检查器，因此他们决定新版本要包括一个多语种拼写检查器特性。对应的用户需求可能包含诸如“为拼写检查器选择语言”“发现拼写错误”和“将词添加到字典”这样的任务。拼写检查器有很多独立的功能需求，涉及的操作包括高亮拼写错误的单词、自动纠错、显示建议替代选项、用正确的单词整体替代拼写错误的单词。易用性需求明确指定如何使用特定语言和字符集来定位软件的使用区域。
……
FREE
