2.1.5　业务需求列表

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

业务需求列表，又称为需求跟踪表，是用户对业务需求的最原始描述。它不掺杂任何需求分析人员对业务需求的分析与设计，是业务人员对该系统应当提供的功能的简要描述。

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

其次，需求列表应当是站在业务人员视角的，是对业务需求的简明扼要的描述。也就是说，用户对于软件开发来说是非专业的。但是，不论软件怎么设计，最终只要能达到某个效果，就能解决用户的难题，让用户满意。因此，后续的分析设计都应当围绕这个目标，并且用这个目标来验证。

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

最后，在系统需求日后变更过程中，每次变更都先将变更写入需求列表中，然后再变更与设计。完成了对变更的相关设计后，再回到需求列表中，验证我们的设计是否满足了此次变更的需求。对需求的跟踪和验证，能够有效地避免因对需求理解的不到位而带来的风险，这样的风险往往是大多数项目失败最主要的风险。