软件设计与软件工程（7）-需求分析

高质量的需求

程序员不仅仅要专注于编码，还应该关心开发活动的源头：需求。真正专业的程序员，会积极地投入到需求活动中，而不只是被动地接收来自产品经理或需求分析师的需求输出，因为他们知道：在“正确地做事”和“做正确的事”中，​“做正确的事”更加重要。如果努力的方向错了，肯定是越努力，越糟糕。实践一再证明：在一个项目中，如果程序员没有积极投入到需求活动中，而只是被动地接收需求进行开发，那么往往会错漏百出，即使产品经理或需求分析师的能力很强，也无法改变这个结果。关于这一点，事件风暴(Event Storming)的发明人Alberto Brandolini有一句很精确的表述：是程序员的理解，而不是产品经理的设计，成为系统最后的功能。

用结构化的方法分析需求

需求分析的本质是探索和发现。同时，沟通和确认是需求分析活动中的重要环节。在本节中，我们将首先介绍需求工程定义的三大活动，并在此基础上介绍需求分析的本质—探索和发现；然后介绍支持需求探索和发现的三层金字塔模型；最后介绍沟通和协作在需求探索和发现以及需求确认活动中的重要作用。

需求工程的三大活动

要顺畅启动软件开发，首先需要明确应该开发什么。这意味着要正确理解业务目标，即为什么做；要定义清晰的产品需求，即如何做；要让业务相关方对前两点达成共识。上述三点，恰恰就是需求工程定义的三大活动。．需求获取：正确地捕获业务方的诉求，对应达到的结果建立正确的预期。．需求分析和定义：把业务方的诉求成功转换为对软件系统的需求，并进行清晰的表述。．需求澄清和确认：让相关涉众（如开发人员和测试人员）都正确地理解需求，并达成一致。这和两个人沟通交流是一样的。你说清楚你的意思，我表达我的理解。然后互相确认。

需求获取

需求获取是一个问题导入的过程。在这个阶段，需要理解的核心问题是：要解决谁的问题？为什么要解决这个问题？只有明确了目标，才能做出正确的解决方案。业务目标并不一定宏大，但是再小的需求也必然有期望达到的业务目标或者要解决的具体问题。1需求获取这个术语带有时代的印记。它发源于软件工程的早期，那个年代的开发团队和需求方往往隶属不同的组织，​“需求获取”是站在开发视角的一种说法。今天“获取”一词已经不太精确，在需求发现过程中要更加积极地探索。假如我们要开发一个餐饮外卖的业务系统，在初始阶段的目标可能是：通过开发的系统，让用户无须亲临餐馆就可以吃到美味的食物，既方便了顾客，也扩大了餐饮企业的服务范围，自己则可以从餐饮企业增加的收益中获取部分佣金。如果已经进入业务的日常运作和改进阶段，那么需要解决的问题往往更为具体。例如，需要通过新增发红包的功能来促进销售，或者用户的常用地址管理功能不好用，需要增加新的常用地址推荐功能。

需求分析和定义

需求分析和定义是生成解决方案的过程：为了解决特定的问题，系统应该提供什么功能？这些功能包含哪些操作步骤？有哪些业务规则？例如，发红包这个业务可能需要包括管理员设定红包发放对象、为红包发放对象发红包、提醒用户使用红包消费、对红包进行核销等关键的功能。在管理员设定红包发放对象这样的业务功能中，还需要包含设定红包发放对象选择规则、根据选择规则圈定用户等更具体的业务步骤。如何设计这些功能，才能更好地达成业务目标，是在需求分析和定义阶段需要解决的问题。需求分析和定义需要专业的方法。用例分析、事件分析等都是在需求分析和定义过程中常用的方法。

需求澄清和确认

需求获取、需求分析和定义往往以产品经理或需求分析师为主体。但是，他们设计的方案是不是满足了业务方的诉求，有没有遗漏某些需求或者方案与需求是否存在不一致，是需要进一步确认的。此外，由于开发人员、测试人员往往和需求分析师是两拨人，所以还需要确认他们是否正确理解了这些需求方案并达成了一致。这些都是需求澄清和确认阶段需要做的工作。需求澄清和确认的核心挑战是细节。我们将探讨如何通过实例化需求等方式高质量地澄清和确认需求。

探索和发现用户的真正需求

需求描述的是客户（或用户）的期望，那是不是“你说我听”就可以了？如果只是请客户描述一下需求，然后把这些描述的内容记录下来加以整理，最后形成文档就完成了需求分析，那事情就简单多了。现实远没有这么理想。大多数时候，客户自己在项目早期对目标的认知是模糊的，无论他们表达的时候有多么自信，具体的需求细节更是不可能一开始就很清晰，而需求分析就是要把这些问题逐步清晰化、明确化。如果做不到这一点，就很可能开发的软件和客户的实际需求天差地别。需求分析的核心是探索和发现：通过持续探索，发现并确立真正的业务目标，从而设计出真正合理的方案，包括系统需求、操作步骤和业务规则等。

需求分析金字塔

需求分析是一个探索和发现的过程。在需求分析过程中一个常见的问题是：基本的问题尚未真正得到澄清，就匆忙开始了关于细节的讨论。可想而知，在业务目标、业务流程没有被正确理解时，过多地讨论细节只会偏离正确的方向，掩盖真正的问题。由粗到细、逐步展开显然是一个经济的方法。下图展示的是需求分析的金字塔模型，它形象地表达了由粗到细、逐步展开的需求分析过程。

不断质疑，澄清业务目标

金字塔的第一层是业务目标，这是所有需求分析和讨论活动的起点。它致力于搞懂需求获取阶段的核心任务：为什么要做这个功能？有时候这个问题还可以反过来：如果不做这个功能，又会怎样？通过这样反复地质疑，往往能把需求背后的思考表达得更为清晰。业务目标和基于业务目标的共识是后续开发活动的前提，这个前提必须非常清晰，才可以进行后续的工作。要澄清业务目标并不困难，只要持续、积极地挑战，就肯定能得到想要的答案。真正重要的是不要忽视它，因为目标在第一时刻常常不是以它本来的面目出现。许多时候，急于动手的开发团队往往会假定客户或者产品经理的描述是正确的，丝毫不加质疑就开始后续的详细分析工作。但是，有不少案例表明，通过对业务目标进行质疑和确认，业务分析人员经常会发现业务目标中存在未澄清或者不合理的部分。

探索业务流程，定义系统功能

金字塔的第二层旨在在功能概要的粒度上解决系统应该实现什么功能这个问题，我们称之为系统功能或系统责任。但是，不应该直接从业务目标跳到系统功能。在系统之外，一些外部系统、各种业务参与者也参与了业务活动，他们之间的交互共同构成了业务流程。业务流程的设计显然需要服务于业务目标。不过，这个设计往往不是简单地复制现实世界的业务流程。如果发现正在运作的业务流程不合理，就需要探索新的流程方案。因此，这一步的关键是“探索”​，而不是“描述”​。在业务流程分析清楚之后，系统功能就变得非常清晰了。系统功能就是业务流程中那些和软件系统有关的功能。例如，前述的发红包业务的管理员设定红包发放对象、为红包发放对象发红包等功能，都是在金字塔的这一层进行探索的结果。

设计操作步骤，澄清业务规则

金字塔的最下面一层关注的是需求的细节：具体的操作步骤和业务规则。例如，前述的设定红包发放对象选择规则等具体的步骤和规则，都是在这一层进行探索的结果。越往金字塔的下层，细节越多，对于讨论的清晰程度的挑战就越大。当然，越往金字塔的上层，细节虽然越少，但是一旦发生错误，影响是最大的。需求分析的过程，是一个持续探索和发现的过程。这个过程应该遵循金字塔结构，由粗到细，逐层展开。

共创、沟通和共识是需求分析活动成功的关键

用文档记录结果，不要用文档作为驱动

传统的需求分析方法特别强调文档的作用。例如，需求获取阶段需要产出业务需求的描述文档，需求分析和定义阶段需要产出产品需求的设计文档等。甚至有些开发团队，只要需求文档没有完成，就拒绝参与项目开发。这种做法是不合适的。需求分析的核心是探索与发现。尽管写文档能梳理思路，让人有所发现，不过总体来说既不有效也不高效。尽可能早地引入需求沟通，进行群体性的共创活动，有助于更早地发现问题，提升需求分析的质量。

在评审和共创活动中，参与者的心态是不同的。在评审活动中，需求和参与者是“被评审的内容”和“被动确认者”​，然而在共创活动中，需求和参与者是“待完善的内容”和“积极参与者”​。因此，协作空间中的主要工具不是投影仪（它只是偶尔被用来演示相关的信息和输入）​，而是报事贴、白板等适合共创的工具，以及便于协作的空间环境—例如，要尽量避免使用椅子摆放得整整齐齐、中间有大会议桌的会议室，这种会议室天然塑造了一种严肃的氛围，对讨论是不利的。共创离不开参与者角色的多样性。尽管需求的负责人一定是需求分析师或产品经理，但是开发人员和测试人员常常可以提供另外的视角，这对于完善需求分析的视角是有好处的。因此，在协作空间中，需要需求相关人员、开发人员、测试人员等不同角色共同参与需求分析，这样有助于得到高质量的分析结果。既然多种角色共同参与到了需求分析的共创活动中，那么需求工程定义的三大活动中的第三个活动—需求澄清和确认的形态也就有了变化，它不再是一个单独的阶段，而是会伴随着需求分析金字塔的探索，在共创空间中同步进行。这最大化了需求分析的反馈速度，同时提高了沟通质量。

利益相关人积极参与到需求分析中。

最大化发现能力，不畏惧需求变化

软件需求分析的本质是一个持续探索和发现的过程，在这个过程中充满着不确定性。需求分析的复杂性常常来源于如下三个方面。(1) 需求问题本身很复杂，该分析清楚的需求没被分析清楚。(2) 需求沟通不充分，开发人员和需求分析人员在对需求的理解上存在偏差。(3) 业务环境发生了变化，或者在开发和业务运营过程中，相关人员产生了新的业务认知。其中，第(1)点和第(2)点可以使用高效的需求分析方法解决。通过采取积极的探索和发现策略，如结构化的需求分析方法、群体性的需求分析活动等，可以提升需求分析和沟通的质量，使发现能力最大化，避免问题的产生。第(3)点是软件开发特有的重要特征。面对变化，采取类似于传统的“冻结需求”方案是徒劳的。有效的方案是采取正确的软件工程实践，建立反脆弱2的系统，如采用敏捷的迭代开发方法，和利用高质量的领域建模​，提升软件系统对需求变化的适应性。反脆弱是一种应对复杂系统的理论。需求分析既需要高质量的分析框架，也需要积极的探索策略和及时演进的心智模式。采用正确的分析方法，能够避免遗漏问题，进行良好的沟通，达成共识。通过打造反脆弱能力，可以避免产生对错误的恐惧，做到与时俱进，持续演进。

定义业务目标

目标要反映关键利益方的诉求

需求不是“业务方告诉我怎么做，我就怎么做”​，而是要理解“为什么做这件事情”​。正如福特汽车公司的创办者亨利·福特的名言：（在汽车发明之前）如果你问客户需要的是什么，客户会告诉你，我需要的是一匹“更快的马”​。理解需求背后的业务目标非常重要。在上面的名言中，受限于认知水平，客户给出的并不是最恰当的解决方案—毕竟客户没有见过汽车，只知道骑马这样一种在当时相对较好的交通方式。但是，客户的诉求—能很快抵达目的地则是比较确定的。相对于客户，汽车生产商拥有更全面的知识，于是可以给出正确的解决方案。这个例子固然有点极端，但是在现实中因为没能把客户的关键诉求理解到位，只是“照章办事”而导致的问题屡见不鲜。最后即使功能开发出来了，也可能因为没有解决最关键的问题，导致项目没有达到期望的目标。业务目标反映了系统的关键利益方（后文统称为业务方）对“通过某个业务过程，达成某种业务目标”的期望，这些业务方往往是业务所有者、项目发起人等。

识别谁是业务方

大多数时候，项目发起人就是最关键的业务方。在不同类型的团队里，需求分析面对的业务方也可能有所不同。例如，在开发一款业务支撑型的内部软件时，开发团队面对的业务方是本团队的业务部门；而对于软件承包商或者外包商来说，业务方往往是外部客户。

达成关于业务目标的共识

任何需求都必然有一个业务目标。在编写需求文档时或者在非正式沟通中，业务方或需求分析人员大多数时候会介绍需求背后的业务目标。不过，成熟的开发团队一定会积极地挑战业务目标，而不只是把业务目标作为背景知识被动地接受。之所以称“积极地挑战”​，是因为这种挑战的动机是非常良好的，绝对不是为了使对方难堪，而是为了贡献更多思考，更好地探索和发现。在讨论业务目标的过程中，常常会出现下列问题。．为什么要做这个产品（或者功能）​？要达到什么样的业务目标？．做出了这个产品（或者功能）​，期望的业务目标能达成吗？不做的话，可以通过其他途径达到业务目标吗？．谁将从这个产品（或者功能）中受益？又有谁可能会受到影响？在着手开发之前，进行挑战是非常重要的。如果最终业务目标没有达成，那么无论是内部客户还是外部客户，无论软件开发团队是不是完美实现了软件需求，无论软件开发团队有多辛苦，都没法认为这样的软件开发是成功的。在团队层面达成关于业务目标的共识，还有一个重要的积极影响，就是在后续开发中难免会遇到各种细节，这时候团队成员就能先根据上下文做出有效判断，虽然判断结果还需要经产品经理确认，但是比把一切问题都抛给产品经理要快捷多了。

业务演进中的目标

几乎任何业务都会持续演进，在演进过程中往往要开发新的功能以支持新的业务场景。例如，在基本的餐品预订功能上线之后，就会发现餐品预订软件对后厨加工人员提出了新的要求。如果餐品加工时间过早，那么餐品可能在取餐前就变凉了；如果过晚，又可能导致到了取餐时间，同学却取不到餐品。这时候，就可以引入精益生产中的JIT（即时生产）​，增加一个为后厨加工人员制作生产餐品计划的功能。此外，通过预订数据能够发现，有一些相同的餐品组合在订单中经常出现。那么，为什么不推出优惠的套餐组合呢？套餐是标准品，当套餐的预订数足够多时，也能提升要准备食材和加工时间的可预测性。如果再使用保温箱对餐品进行保温，还能控制取餐时餐品的温度。如果套餐功能上线之后很受欢迎，那么一开始看起来很重要的JIT方案，就暂时没那么重要了，增加套餐预订的功能变成了一个优先级更高的需求。从这个例子中我们可以看出，解决不同的功能需求能够达到相同的业务目标。在这种情况下，应该根据具体的上下文决定开发其中的哪个需求。也就是说，需求开发仅仅是达到业务目标的手段。这一点在开发活动中务必注意。有一些方法可以帮助我们结构化地思考目标和功能之间的关系，例如影响地图。