怎样做需求分析之十八确认之需求列表

1、怎样做需求分析之十八：确认之需求列表作者: fangang  发布时间: 2012-04-28 10:31需求分析是一个我们与客户不断沟通的过程，这个过程就如同我们与老板的一次对话。老板把你叫去，给你交待了一大堆任务。我们首先是仔细聆听任务的内容，然后整理个一二三四。然后我们复述一遍老板的意思：“老板，我复述一遍，您看看我理解得对不对。首先，您要求我×××，然后×××，最后×××。”老板：“恩，就是这意思，你照着办吧。”之后，我们开始了我们的工作。这个复述的步骤相当重要，因为

2、人与人的沟通最大的问题就是失真。由于人在知识水平、观点看法、性格特质的不同，听者常常会误解对方的意思。有了复述的步骤，误解就会立即被纠正，沟通得以顺畅。在需求分析中，这个复述的步骤就是需求确认。 但与一次简单的沟通不同，需求分析是一系列复杂的沟通过程，它涉及到许多人，谈论的是许多的事物。因此，一次简单的口头复述不足以满足需求分析的需要。因此，需求确认是一系列的确认过程，每次确认都可能需要与不同的人，在不同层次的确认。最终应当形成到纸面，形成文档性的东西，双方签字确认。这个过程中可以采用的一个好的方法就是原型法，最终产物应当是需求列表与需求规格说明书，最后结束于一场需求评审会，或者签字

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

4、如实记录原始需求的文档，就是需求列表。 需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。 首先，需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。从用例模型到领域模型我们不难发现，它是一个分析与设计的过程。需求分析员对业务需求进行捕获、认识、理解以后，需要结合软件专业知识进行分析设计，还要听取系统架构师和设计师对需求可行性的分析，最后才整理和编写出用例模型。在这样一个过程中，随着业务需求

5、复杂度的提高，以及各种技术分析的掺杂，最终的结果很有可能偏离原有的业务需求。这种偏离常常表现为对业务需求正确性与完整性的偏离，即需求已经变味儿了，或者某些需求项目缺失。需求列表就是那个最开初的、最完整的、正确的业务需求。用这样一个列表来开始我们的分析，最后用它来验证我们的设计，使之成为我们的分析设计之旅树立的一个正确的航标。有了这样一个航标，就可以使我们最终能够到达一个正确的彼岸。 其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。一个纷繁复杂的、业务庞大的管理系统，经过整理以后，被分解成一个一个的需求项目。每个需求项目是一句简明扼要的话。简明扼要意味着清晰易懂；分

6、解成需求项目意味着分解复杂问题为简单问题。每一次与业务人员讨论完业务需求以后，我们就整理成这样一个需求列表，使我们与客户的讨论都有一个清晰明了的讨论结果。当下一次与业务人员讨论时，我们拿出我们上一次讨论的需求列表，又使下一次的讨论有一个基点，使业务讨论能以演进的方式推进下去，提高我们的工作效率。然而，需求列表中应当剔除那些客户对系统设计的内容。前面我们提到，客户，特别是那些对信息化建设有一定经验的客户，容易提一些对系统设计的期望，比如什么功能应当做成什么样子，功能界面是怎样的。客户提的这些意见，也许不是最佳的，我们经过深入的分析设计以后，可能会提出一些更加合理的方案。因此，这样内容不能成为我们

7、验证系统功能的基石，因而不应当写入需求列表中。需求列表描述的更应当是客户对软件功能的意图，即客户使用这个功能所达到的目的，而不是功能的具体实现。这一点我们在后面通过具体实例详细说明。 最后，需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。一个大的需求项目可以分解为多个细的需求项目，进而形成一个树状的需求列表。需求列表应当细分到什么程度呢？将系统需求描述清楚为宜。简单需求不需过多的细分，而复杂需求则需要尽量写细一些。同时，需求列表也是一个不断变化的过程，日后的每一次升级维护都需要不断增添和修改需求列表，使其与实际系统保持一致。 现在我举一个具体实例来看看需求列表是怎

8、样编写的吧。这是一个公司内部的评审系统，它分为制订评审计划、执行评审、制作评审报告与问题跟踪四部分。经过初次与评审人员的业务讨论以后，我们整理出这样一个需求列表：1评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点，制订评审组长，并预计评审工作量，发起一个评审任务。 2评审者在收到邮件后，进入评审任务中，对评审内容进行评审，同时填写并提交各自的评审意见。 3评审组长汇总所有的评审意见，并在评审会上依次过所有的评审意见，对评审意见进行修改或删除，填写问题跟踪，形成此次评审会上最终的评审意见及问题跟踪表。 4评审组长制作评审报告，并形成评审结论，

9、以邮件的形式通知所有评审者。 5所有评审者对评审报告进行回复意见，如果都选择同意，评审组长关闭此次评审。 6评审组长跟踪所有问题，并可以依次关闭每个问题。 当然，在这个需求列表中，客户提出了一些名词，比如评审计划、评审意见、评审组长等。我们在整理需求列表的同时，应当注意整理这些名称，弄清它的内涵外延，以及它们相互之间的关系、作用。这将为我们后面的领域模型分析提供素材。毫无疑问，这样的需求列表过于粗略。因而在后面的业务讨论中，我们逐项对它们进行了细化： 1评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点，制订评审组长，并预计评审工作

10、量，发起一个评审任务。 1.1 评审时间应当分为数个阶段分别制订时间计划，如评审准备、评审会议、评审报告； 1.2 评审内容应当可以上传数个文件，分别描述文件的内容、作者、编写日期、版本号，供评审者下载与查看； 1.3 填写评审者时，选择一个评审者为评审组长，评审发起人不能是评审组长； 1.4 评审地点与预计评审工作量只需直接填写； 在我们后面的用例分析中，我们对这段需求列表进行了大量的分析设计。但这些都是设计与实现，它们会出现在后面的用例分析及其模型中，却不应出现在需求列表中。在后来的升级开发中，客户又提出了发邮件通知的功能。将该功能描述出来，并添加到需求列表中： 1.5 评审计