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

怎样做需求分析之十八：确认之需求列表
作者：fangang发布时间: 2012-04—28 10：31
需求分析是一个我们与客户不断沟通的过程，这个过程就如同我们与老板的一次对话。

老板把你叫去,给你交待了一大堆任务。

我们首先是仔细聆听任务的内容，然后整理个一二三四。

然后我们复述一遍老板的意思：“老板，我复述一遍，您看看我理解得对不对.首先，您要求我×××,然后×××，最后×××。

”老板：“恩，就是这意思,你照着办吧。

”之后,我们开始了我们的工作。

这个复述的步骤相当重要，因为人与人的沟通最大的问题就是失真。

由于人在知识水平、观点看法、性格特质的不同，听者常常会误解对方的意思。

有了复述的步骤，误解就会立即被纠正,沟通得以顺畅。

在需求分析中,这个复述的步骤就是需求确认。

但与一次简单的沟通不同，需求分析是一系列复杂的沟通过程，它涉及到许多人，谈论的是许多的事物.因此，一次简单的口头复述不足以满足需求分析的需要。

因此,需求确认是一系列的确认过程，每次确认都可能需要与不同的人，在不同层次的确认。

最终应当形成到纸面，形成文档性的东西，双方签字确认。

这个过程中可以采用的一个好的方法就是原型法,最终产物应当是需求列表与需求规格说明书，最后结束于一场需求评审会，或者签字确认会。

当我对无数失败项目的分析总结之后，得出的一个重要的结论就是我们的项目需要对需求的跟踪。

大家想想，当一个项目持续数月，经过数轮的需求分析与设计，再经过数轮的需求确认与变更。

用户、需求分析员、系统架构师、设计人员、开发人员，甚至测试，一个一个的角色像走马灯一样加入进来。

需求开始变得模糊不清，软件设计的初衷开始偏离。

开发人员不知道依据哪个标准开发，测试人员不知道依据哪个标准测试，甚至一些需求被人所遗忘.最终，等到软件交付的时候，客户说这不是他们所需要的,项目走向了失败。

问题出在哪里呢?问题就出在，不论我们如何分析与设计,我们都要如实记录原始的需求,并以此来验证我们最终的软件。

这个如实记录原始需求的文档，就是需求列表。

需求列表，又称之为需求跟踪表,是最原始的、用户对业务需求的描述。

它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句,以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能.
首先，需求列表不掺杂我们对业务需求的任何分析与设计,这是需求列表的核心，也是它存在的意义.从用例模型到领域模型我们不难发现，它是一个分析与设计的过程。

需求分析员对业务需求进行捕获、认识、理解以后，需要结合软件专业知识进行分析设计，还要听取系统架构师和设计师对需求可行性的分析，最后才整理和编写出用例模型。

在这样一个过程中，
随着业务需求复杂度的提高，以及各种技术分析的掺杂,最终的结果很有可能偏离原有的业务需求。

这种偏离常常表现为对业务需求正确性与完整性的偏离，即需求已经变味儿了，或者某些需求项目缺失。

需求列表就是那个最开初的、最完整的、正确的业务需求。

用这样一个列表来开始我们的分析,最后用它来验证我们的设计，使之成为我们的分析设计之旅树立的一个正确的航标。

有了这样一个航标,就可以使我们最终能够到达一个正确的彼岸。

其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。

一个纷繁复杂的、业务庞大的管理系统，经过整理以后,被分解成一个一个的需求项目。

每个需求项目是一句简明扼要的话。

简明扼要意味着清晰易懂;分解成需求项目意味着分解复杂问题为简单问题。

每一次与业务人员讨论完业务需求以后,我们就整理成这样一个需求列表,使我们与客户的讨论都有一个清晰明了的讨论结果。

当下一次与业务人员讨论时，我们拿出我们上一次讨论的需求列表，又使下一次的讨论有一个基点，使业务讨论能以演进的方式推进下去，提高我们的工作效率。

然而，需求列表中应当剔除那些客户对系统设计的内容。

前面我们提到，客户，特别是那些对信息化建设有一定经验的客户，容易提一些对系统设计的期望，比如什么功能应当做成什么样子，功能界面是怎样的。

客户提的这些意见，也许不是最佳的，我们经过深入的分析设计以后，可能会提出一些更加合理的方案。

因此，这样内容不能成为我们验证系统功能的基石，因而不应当写入需求列表中.需求列表描述的更应当是客户对软件功能的意图，即客户使用这个功能所达到的目的,而不是功能的具体实现。

这一点我们在后面通过具体实例详细说明。

最后，需求列表也不是一步到位的,而是经过由粗到细逐渐整理形成的。

一个大的需求项目可以分解为多个细的需求项目，进而形成一个树状的需求列表。

需求列表应当细分到什么程度呢？将系统需求描述清楚为宜。

简单需求不需过多的细分,而复杂需求则需要尽量写细一些。

同时，需求列表也是一个不断变化的过程,日后的每一次升级维护都需要不断增添和修改需求列表,使其与实际系统保持一致。

现在我举一个具体实例来看看需求列表是怎样编写的吧。

这是一个公司内部的评审系统，它分为制订评审计划、执行评审、制作评审报告与问题跟踪四部分。

经过初次与评审人员的业务讨论以后,我们整理出这样一个需求列表：
1．评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点,制订评审组长,并预计评审工作量，发起一个评审任务。

2．评审者在收到邮件后，进入评审任务中，对评审内容进行评审，同时填写并提交各自的
评审意见.
3．评审组长汇总所有的评审意见，并在评审会上依次过所有的评审意见，对评审意见进行修改或删除,填写问题跟踪，形成此次评审会上最终的评审意见及问题跟踪表。

4．评审组长制作评审报告，并形成评审结论，以邮件的形式通知所有评审者。

5．所有评审者对评审报告进行回复意见，如果都选择同意,评审组长关闭此次评审。

6．评审组长跟踪所有问题,并可以依次关闭每个问题。

当然，在这个需求列表中,客户提出了一些名词，比如评审计划、评审意见、评审组长等。

我们在整理需求列表的同时，应当注意整理这些名称，弄清它的内涵外延,以及它们相互之间的关系、作用。

这将为我们后面的领域模型分析提供素材.毫无疑问，这样的需求列表过于粗略。

因而在后面的业务讨论中，我们逐项对它们进行了细化：
1．评审发起人填写一份评审计划,详细记录评审时间、评审内容、评审者、评审地点，制订评审组长,并预计评审工作量,发起一个评审任务。

1。

1 评审时间应当分为数个阶段分别制订时间计划，如评审准备、评审会议、评审报告；1。

2 评审内容应当可以上传数个文件，分别描述文件的内容、作者、编写日期、版本号，供评审者下载与查看；
1.3 填写评审者时，选择一个评审者为评审组长,评审发起人不能是评审组长；
1。

4 评审地点与预计评审工作量只需直接填写；
在我们后面的用例分析中,我们对这段需求列表进行了大量的分析设计。

但这些都是设计与实现，它们会出现在后面的用例分析及其模型中,却不应出现在需求列表中。

在后来的升级开发中,客户又提出了发邮件通知的功能.将该功能描述出来，并添加到需求列表中：
1。

5 评审计划提交以后，以邮件的形式发送给每个评审者，通知该评审任务.
有了这样的需求列表，当需求分析工作完成时，我们将一项一项检查用例模型是否满足需求列表的内容；当软件开发完成时，我们将一项一项检查软件功能是否满足需求列表的内容；当用户验收时，我们同样使用需求列表，一项一项检查我们的软件是否满足用户需求。