当我们谈“需求”时，我们在谈什么？

事实1

需求其实并非在谈需求。

对于软件产品、硬件产品、服务或任何你想构建的东西，需求就是它们要做的事或要成为的东西。不论你发现还是没发现，写下来或没写下来，需求都存在。显然，除非产品满足需求，否则就不对。所以从这个角度你可以认为，需求是某种自然法则，等着你来发现。

这就是说，需求活动主要不是编写需求文档。相反，它专注于理解业务问题，并为之提供解决方案。软件是要解决某种问题，硬件和服务也是。需求发现的真正艺术是发现真实的问题。只要你做到了这一点，就为识别和选择不同的解决方案奠定了基础。所以，从本质上说，需求与编写需求无关，而是发现要解决的问题。

另外，当我们说“业务”、“业务问题”或“工作”时，我们的意思就是你所关心的各种活动，它们可以是商业上的、科学上的、嵌入式的、政府的、军方的，实际上也可以是所有其他类型的活动、服务或消费品。

此外，在本书中，当我们说“他”（常指业务分析师）时，我们的意思是“他或她”。我们发现说“他或她”或“他/她”很不方便。请相信，需求工作不分性别。

在本文中我们用“他”来指所有性别。两位作者（一名男性和一名女性）觉得用“他或她”容易导致阅读不流畅，不方便。

事实2

如果我们必须构建软件，那么它必须为拥有它的人提供最理想的价值。

请注意，我们关注最终结果的拥有者，只是间接地关注用户。这种关注似乎与通常的优先级相反，所以我们最好解释一下。

拥有者是为软件（也可以是硬件或其他要构建的产品）付费的人或组织，不论拥有者为该软件的开发付了钱，还是从别处购买了该软件。软件部署时造成的业务影响，也是拥有者付出的成本。另一方面，拥有者从软件中得到好处。描述这种关系非常简单，拥有者花钱买好处。

我们可以用另一种方式来表述：除非产品提供了利益，否则拥有者不会付钱。这种利益通常表现为提供某种以前没有的能力，或改变某种业务过程，使之更快、更便宜、更方便。自然，这种利益为拥有者提供的价值，必须超过开发该产品的成本（参见图1）。

图1 随着软件变得越来越强大、成本越来越高，软件带来的利益也越来越大。但在某一点，构建的成本开始超过利益，项目就不再盈利了

要最好地体现价值，产品提供的利益必须与产品的成本相称。在某些情况下，如果带给拥有者的价值足够大，产品可以成本很高。例如，航空公司愿意付大量的钱来开发模拟器，确保飞行员获得合适的资质和技能。如果他们没有合适的资质和技能，就会造成生命财产损失。航空公司可能也会花大量的钱来开发自动化的值机系统，因为这将大幅减少乘客登机的成本。同一家航空公司只愿花很少的钱来开发食堂员工花名册系统，因为事实是：这类任务可以手工完成，食堂里的人不对可能带来烦恼，但几乎不会对生命构成威胁。

需求发现者（称为“业务分析师”、“需求工程师”、“产品拥有者”、“系统分析师”或其他头衔）的职责，就是确定拥用者看重的价值是什么。在某些情况下，提供一个小系统，解决一些小问题就能够为拥有者提供足够的利益，让他们觉得值。在另一些情况下（可能这种情况很多），扩展系统的功能将提供很大的价值，并且可能只要增加少量成本就可以实现。这都取决于拥有者认为什么有价值。

然后就是最佳价值：充分理解拥有者的问题，以便交付一个解决方案，以最好的价格提供最好的回报。

事实3

如果软件不必满足要求，那你怎么干都行。但是，如果它打算满足要求，你就必须知道要求是什么，才能构建正确的软件。

这样思考很有价值：如果开发者正确地理解了产品打算为用户完成什么，以怎样的方式完成，这些产品就是最有用的。要理解这些事情，你必须理解拥有者的业务工作，并决定将来工作如何进行。

如果这些事情得到理解并达成了一致意见，业务分析师就与拥有者沟通，探讨怎样的产品能为工作带来最大的改进。业务分析师得到需求，描述产品的功能（它要做什么）以及产品的属性（它做到什么程度）。

不知道这些需求，开发项目得到的产品就不太可能有太大价值。除了少数撞大运的意外，没有产品能在事先不理解需求的情况下成功。

不论拥有者希望做哪种工作，科学的、商务的、电子商务的或社交网络的，也不论使用什么开发语言或开发工具来构建产品，开发生命周期（敏捷、原型、螺旋、Rational统一过程或其他方法）也与理解需求的要求无关。

这一事实总是会出现：你必须得到需求的正确理解，并与客户达成一致意见，否则你的产品或项目就会有严重的缺陷。

不幸的是，需求并非总是得到正确的理解。作者Steve McConnell 和Jerry Weinberg提供的统计数据表明，多达60%的错误源自于需求活动。软件开发者（几乎）有机会消除这些错误，但许多人选择（或他们的经理选择）几乎跳过需求发现，直接轻率地开始构建错误的产品（这是不可避免的）。结果，他们在产品上花了许多倍的金钱。如果开始就发现了正确的需求，成本会低得多。糟糕的质量在开发生命周期中传递，事情就这么简单。

有两次我被问到：“请告诉我，Babbage先生，如果向机器输入错误的数字，会得到正确的答案吗？”我无法理解问出这种问题的混乱思维。
     ——Charles Babbage

事实4

构建一个软件和解决一个业务问题之间，存在巨大的差别。前者不一定实现后者。

许多软件开发项目只关注软件。这也许看起来很合理，毕竟，大多数软件项目设法开发出某种软件。然而，只关注软件有点像在建帕台农神庙时只关注石头。软件要对拥有者有价值，就必须解决拥有者的业务问题。

我们开发了相当多的软件。每年产生数千万行代码（也可能是数亿行）。这些代码中包含许多错误，最多的错误是需求错误。因此，世界上相当多的软件不能解决正确的问题。

某些开发过程基于一种理念，即向目标用户交付某种功能，然后请他们来说是否能解决他们的问题。如果不能解决，软件就返工一下，然后再次展示并请求批准。这样做有一个问题：我们永远不知道用户批准前一次交付是因为对它满意，还是因为被过程搞得筋疲力尽。

最重要的是，很难让单个用户理解部署一个软件在更大范围内造成的影响。通常软件用户不知道更大业务的足够信息，不能确定具体应用这种软件是否会对业务的其他部分带来问题。

就算是啰嗦，我们也要再次强调，软件就是要解决一个业务问题。于是很清楚，所有开发工作都必须从问题开始，而不是从看到的解决方案开始。

事实5

需求不一定要写下来，但构建者必须知道它们。

通常，需求项目的目标看起来就是尽可能得到一份厚厚的需求规格说明书。很少有人能理解它的大部分内容，甚至更少的人有耐心去读它，但这似乎都不重要。需求编写者相信，需求规格说明书越厚，他们的工作就越会受到欣赏。

在写好之后，这份可观的文档就被抛过墙头（或者应该说用铲车抛过墙头），交给开发者，盼望这些人对厚厚一叠规格说明书感到高兴。毕竟，它的页数越多，内容遗漏的可能性就越少。也许理论上是这样。自然，开发者几乎总是对这种文档毫无兴趣，要么忽略它，要么固执地坚持它。这两种方式的最终结果，通常都不能令人满意。

虽然有这种奇怪的行为，我们仍然需要分析需求，并将这些需求告诉给开发团队（参见图2）。

图2 自然，需要和产品构建者沟通需求

需求是否写下来，这不是问题的要点。在某些情况下，口头沟通需求更有效，在另一些情况下，必须永久地记录下需求。

虽然口头沟通需求效率高，但我们觉得，所有需求都用这种方式来沟通是不可行的。在很多时候，编写需求的活动有助于业务分析师和利益相关者彻底理解需求。除了改进理解之外，正确编写需求也提供了追踪文档。需求的理由，或故事卡上的缘故，记录了团队的决定。它也为测试者和开发者提供了清晰的指示，说明了需求的重要性，从而建议需要花多少工作量。此外，如果维护者知道为什么有这项需求，也会降低将来维护的成本。

需求并不是要为项目增加额外的负担，所以除非很有必要，否则就不应该写任何东西。但是，如果有需要，那么编写需求的工作将带来数倍的回报，因为需求的准确性和对将来维护工作的减少。

事实6

客户不一定总能给你正确答案。有时候客户也不可能知道什么是对的，有时候他就是不知道需要什么。

传统来讲，需求活动被看成是某种类似速记员的任务。也就是说，业务分析师仔细聆听利益相关者，准确记录他们说的所有东西，并将他们的要求翻译成产品的需求。

这种方式的缺点是，它没有考虑到利益相关者在试图描述需求时的困难。展望一个产品来解决一个问题，这不是一项简单的任务，尤其是问题并非总是理解得很彻底。考虑到今天业务的复杂性和规模，个人确实很难理解业务所有适当的部分。

我们也有“增量改进”的问题。在询问有关新系统时，利益相关者常常会描述原有的系统，并加上一些改进。这种增量的方式通常排除了所有重大的创新，常常会导致平庸的产品，不能满足期望。

业务分析师必须表演戏法。有时候他必须记录下客户的要求，有时候他必须说服客户，他们要求的并不是他们需要的，有时候他必须从客户的解决方案中导出需求，有时候他必须提出没有人提到的创新，得到更好的解决方案。在所有情况下他都应该想到，每个利益相关者都可能是匹诺曹（见图3），不要什么都相信。

图3 有时候，你的客户就像匹诺曹，不会告诉你全部事实

事实7

需求不是偶然得到的，要通过某种有序的过程得到。

所有重要的努力都需要有序的过程。随机使用钢筋和水泥不会建成大楼，需要一个定义的过程来设计和建造这样的结构。类似地，有一个定义的、系统的过程来拍电影。摩托车也是通过有序的过程来设计和建造的，你的最近一次飞行也是一组有序的过程，几 乎是逐字执行的。甚至艺术工作，如写小说和画画，艺术家都会遵循一个有序的过程。

这些过程不是因循守旧的过程，不是无头脑地执行所有指令，不问任何问题，按预先描述的顺序，没有任何变通。相反，有序的过程由一组任务构成，实现预期的结果，但这些任务的次序、重点和应用程度需要采用该过程的人或团队来决定。

最重要的是，参与这个过程的人必须能看到，为什么过程中不同的任务是重要的，哪些任务对项目最重要。

事实8

你怎么迭代都可以，但仍需要理解业务的需求。

迭代式开发方法变得越来越流行，这肯定是有意义的进步，但像很多进步一样，这些技术有时候炒作过度了。例如，我们曾听到有人说（也有人印刷出版），迭代式交付让需求变得多余。

冷静的头脑会意识到，任何开发技术都需要发现需求，这是认真开发的先决条件。因此，冷静的头脑已经将需求过程吸收到他们的开发生命周期中。聪明的方法不是废除需求，而是从一个不同的方向接近需求。

真正值得关注的是既要发现需求，又不必编写无用的、不成熟的、浪费的成堆文档（这适用于所有类型的开发技术）。

不论你怎样开发软件，总是要理解客户的业务问题，以及产品必须做些什么来解决这个问题（即它的需求）。

事实9

没有银弹。所有方法和工具都无法弥补糟糕的想法和糟糕的手艺。

虽然我们需要一个有序的过程，但不应该认为它能够代替思考。过程有帮助，但它们对聪明人帮助较大，对不准备思考的人帮助较小。对于需求过程来说，这一点尤其正确。在需求过程中，业务分析师需要面对几个版本的需求，同时还要想象未来最好的软件产品是怎样的。

需求活动一点儿也不简单，要想成功，就需要业务分析师的思考和理解。一些自动化工具可以有所帮助，但它们只能作为辅助手段，而不能替代好的需求实践。盲目遵循事先制定的实践，根本不能取得有经验的业务分析师能取得的结果。分析师使用最重要的工具：头脑、眼睛和耳朵。

事实10

要想成功地实现需求，需求就必须可度量、可测试。

从本质上说，功能需求是产品支持其拥有者的业务时必须做的事。非功能需求是产品要在拥有者的环境中取得成功，必须将功能完成得多好的量化描述。

要让构建的产品完全满足这些标准，在编写需求时就必须准确。同时，必须考虑到需求来自于人，而人并非总是准确，可能总是不准确。要达到必要的准确程度，必须对需求进行某种测量。如果可以用数字代替文字来测量需求，就能让需求可测试。

例如，如果你的产品有一个需求是“应该对新用户有吸引力”，那么就可以建立一个测量指标，即初次使用的用户能够在2分钟内成功建立一个账户，对于用户应该知道的所有数据项，都不会有超过5秒钟的犹豫，如他的姓名、邮件地址和类似的数据项。（犹豫时间是测量产品直观程度的指标，是对用户的吸引力的一部分。）自然，如果你用这种方式来测量需求，测试人员就可以确定产品（有时候是产品原型）是否满足需求。

可以很放心地说，如果你不能为需求找到测量指标，那它就不是需求，只是一种无根据的想法。

事实11

作为业务分析师，你将改变用户思考这个问题的方式，不是现在就是将来。

在你开始理解需求时，尤其在需求来自于不同的利益相关者时，你就开始建立一些抽象概念，并建立一个词汇表。你展示业务过程的模型，与利益相关者一起发现工作的本质，得到清晰和可测量的需求，并将所有这些事实反馈给利益相关者。在做这些事情时，你就会改变（改进）他们对业务问题的看法。

如果人们对需求的含义有了更好的理解，他们就可能看到改进的办法。你的一部分工作就是帮助人们尽早理解和质疑他们的需求，这样他们就可以帮助你发现他们真正的需求。

需求究竟是什么

在了解这些事实之后，我们一直在讨论的需求到底是什么呢？简而言之，需求就是产品支持其拥有者的业务所必须完成的事，或让拥有者接受并感兴趣所必须具备的品质。需求之所以存在，要么因为该类型的产品要求某些功能和品质，要么因为客户希望该需求成为交付的产品的一部分。

1 功能需求

功能需求描述了一个动作，产品要对操作者有用，就必须执行该动作。功能需求源于利益相关者需要完成的工作。几乎所有的动作（计算、检查、发布或其他动作）都可以是一项功能需求。

  功能需求是产品必须完成的那些事。

  产品应该生成一份所有道路的除冰调度表，这些道路在给定的时间参数内预计会结冰。

这类需求是产品要做的一件事。产品要在拥有者的业务背景下有用，就必须做这件事。你可以推断，上例中的拥有者是一个组织机构，负责保持道路的安全，实现方式是分派卡车，在快要结冰的道路上播撒除冰物质。

2 非功能需求

非功能需求是产品的属性或品质。产品要让拥有者和操作者接受，就必须具备这些属性或品质。非功能需求描述了诸如观感、可用性、安全性和法律限制等需求，在某些情况下，这对于产品的成功是至关重要的。例如下面这个例子：

  产品必须在0.25秒以内确定对方是“朋友”还是“敌人”。

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

有时它们作为需求的原因是为了改进产品，或让人们想买它。例如：

  产品应该提供愉快的用户体验。

有时它们让产品可用：

  产品应该能被到达大厅的旅行者使用，这些旅行者可能不使用当地的语言。

非功能需求可能开始看起来很模糊，或不完整。在本书后面的内容中，我们会看到如何为它们制定验收标准，让它们可度量、可测试。

3 限制条件

限制条件是全局性的需求。它们可以是对项目本身的限制，或是对产品最终设计的限制。例如，这是一个项目限制条件：

  产品必须在新的税务年度开始前准备好。

  限制条件是一个全局问题，约束着所有的需求。

产品的客户是在说，如果顾客不能在新的税务年度中使用该产品，那么它就没有什么用了。其效果是，需求分析师必须对需求进行限制，只包括那些在最后期限内能够提供最大价值的需求。

还有一些限制条件是针对产品的最终设计和构造的。例如，下面的例子：

   产品应该作为iPad、iPhone、Android和Blackberry应用来运行。

如果这是一个真正的业务限制条件，而不只是某种看法或观点，那么不满足这个限制条件的所有解决方案显然是不能接受的。

不论限制了什么，限制条件都可以看成是另一种类型的需求，参见图4。

   限制条件只是另一种类型的需求。

图4 最终产品的功能受到限制条件的约束。功能性是用户能得到的好处，但“交付”功能性的非功能需求让产品可用，被用户接受

本文节选自《掌握需求过程（第3版）》

内容简介

本书论述了软件开发中的重要课题—如何得到正确的需求。书中用一个接一个的步骤、一个接一个的模板、一个接一个的例子，向读者展示了经过业界验证的需求收集和验证过程，为精确地发现顾客所需所想提供了技巧和深刻见解。第3版延续了之前版本的优势，提供了Volere需求过程和需求规格说明书模板，同时为传统、敏捷和外包开发提供了不同的策略指导。对客户价值、迭代式开发和故事卡片的讨论，体现了作者对敏捷软件开发的深刻理解。利用验收标准让需求可测试，是在项目早期消除需求缺陷的好方法。书中还提供了各种检查清单，帮助识别利益相关者、用户、非功能需求。第3版引入了Brown Cow模型，清晰地展现了“做什么”和“怎么做”的关注点分离。各种需求案例的讨论，是作者多年实践经验的结晶。书中还探讨了复用需求和需求模式的方法。

本书可作为软件开发人员在开发过程中随时参考的手册，是产品经理、系统分析师、软件开发者和测试者必读的一本好书。

本文转载自异步社区

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF913EA00001DF1E1DDD180F9420