怎样做需求确认：需求列表

需求分析是一个我们与客户不断沟通的过程，这个过程就如同我们与老板的一次对话。老板把你叫去，给你交待了一大堆任务。我们首先是仔细聆听任务的内容，然后整理个一二三四。然后我们复述一遍老板的意思：“老板，我复述一遍，您看看我理解得对不对。首先，您要求我×××，然后×××，最后×××。”老板：“恩，就是这意思，你照着办吧。”之后，我们开始了我们的工作。这个复述的步骤相当重要，因为人与人的沟通最大的问题就是失真。由于人在知识水平、观点看法、性格特质的不同，听者常常会误解对方的意思。有了复述的步骤，误解就会立即被纠正，沟通得以顺畅。在需求分析中，这个复述的步骤就是需求确认。

但与一次简单的沟通不同，需求分析是一系列复杂的沟通过程，它涉及到许多人，谈论的是许多的事物。因此，一次简单的口头复述不足以满足需求分析的需要。因此，需求确认是一系列的确认过程，每次确认都可能需要与不同的人，在不同层次的确认。最终应当形成到纸面，形成文档性的东西，双方签字确认。这个过程中可以采用的一个好的方法就是原型法，最终产物应当是需求列表与需求规格说明书，最后结束于一场需求评审会，或者签字确认会。

当我对无数失败项目的分析总结之后，得出的一个重要的结论就是我们的项目需要对需求的跟踪。大家想想，当一个项目持续数月，经过数轮的需求分析与设计，再经过数轮的需求确认与变更。用户、需求分析员、系统架构师、设计人员、开发人员，甚至测试，一个一个的角色像走马灯一样加入进来。需求开始变得模糊不清，软件设计的初衷开始偏离。开发人员不知道依据哪个标准开发，测试人员不知道依据哪个标准测试，甚至一些需求被人所遗忘。最终，等到软件交付的时候，客户说这不是他们所需要的，项目走向了失败。问题出在哪里呢？问题就出在，不论我们如何分析与设计，我们都要如实记录原始的需求，并以此来验证我们最终的软件。这个如实记录原始需求的文档，就是需求列表。

需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。

首先，需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。从用例模型到领域模型我们不难发现，它是一个分析与设计的过程。需求分析员对业务需求进行捕获、认识、理解以后，需要结合软件专业知识进行分析设计，还要听取系统架构师和设计师对需求可行性的分析，最后才整理和编写出用例模型。在这样一个过程中，随着业务需求复杂度的提高，以及各种技术分析的掺杂，最终的结果很有可能偏离原有的业务需求。这种偏离常常表现为对业务需求正确性与完整性的偏离，即需求已经变味儿了，或者某些需求项目缺失。需求列表就是那个最开初的、最完整的、正确的业务需求。用这样一个列表来开始我们的分析，最后用它来验证我们的设计，使之成为我们的分析设计之旅树立的一个正确的航标。有了这样一个航标，就可以使我们最终能够到达一个正确的彼岸。

其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。一个纷繁复杂的、业务庞大的管理系统，经过整理以后，被分解成一个一个的需求项目。每个需求项目是一句简明扼要的话。简明扼要意味着清晰易懂；分解成需求项目意味着分解复杂问题为简单问题。每一次与业务人员讨论完业务需求以后，我们就整理成这样一个需求列表，使我们与客户的讨论都有一个清晰明了的讨论结果。当下一次与业务人员讨论时，我们拿出我们上一次讨论的需求列表，又使下一次的讨论有一个基点，使业务讨论能以演进的方式推进下去，提高我们的工作效率。

然而，需求列表中应当剔除那些客户对系统设计的内容。前面我们提到，客户，特别是那些对信息化建设有一定经验的客户，容易提一些对系统设计的期望，比如什么功能应当做成什么样子，功能界面是怎样的。客户提的这些意见，也许不是最佳的，我们经过深入的分析设计以后，可能会提出一些更加合理的方案。因此，这样内容不能成为我们验证系统功能的基石，因而不应当写入需求列表中。需求列表描述的更应当是客户对软件功能的意图，即客户使用这个功能所达到的目的，而不是功能的具体实现。这一点我们在后面通过具体实例详细说明。

最后，需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。一个大的需求项目可以分解为多个细的需求项目，进而形成一个树状的需求列表。需求列表应当细分到什么程度呢？将系统需求描述清楚为宜。简单需求不需过多的细分，而复杂需求则需要尽量写细一些。同时，需求列表也是一个不断变化的过程，日后的每一次升级维护都需要不断增添和修改需求列表，使其与实际系统保持一致。