需求分析-原型法

     软件项目需求分析是一个项目的开端，也是一个项目建设的基石。在失败的开发项目中，80%是由于需求分析的不明确而造成的。因此，一个软件开发项目想要成功的关键就是要做好需求分析。这是我经过在上个月不堪回首的痛苦折腾后，才深深领悟到的真意。在这里我想把在这个项目得到的教训和经验与大家分享。

在上个月，公司委派我负责一个小型的软件开发项目。在接手这个项目时，我看到该项目的需求比较简单，于是想当然的就直接开始工作了。结果是由于在开发初期忽视了与用户的信息沟通和深度需求分析，不但导致系统开发出来后不能很好地满足用户的需求，而且频繁的需求变更返工不仅在技术上给开发人员带来了巨大的麻烦，也使到软件性能深受影响且造成人力、物力的浪费。

轻视小型软件项目需求分析之痛

      一个软件项目的开发主要分为五个阶段：需求分析阶段、设计阶段、编码阶段、测试阶段和维护阶段。需求分析阶段所得到的结果是软件开发其它四个阶段的必备条件。从这次项目的经验来看，只要需求分析中有一个小小的偏差，就可能会导致整个项目无法达到预期的效果，或者说最终开发出的产品不是用户所需要的。

因此，需求分析在许多大型软件开发中都得到了很好的重视，但让人遗憾的是在小型软件项目中往往会认为需求很简单从而很容易就忽视了需求分析这个重要的步骤。教条主义式的经验使我在这个项目上犯了这个错误，结果是让我付出了更多的心力和更大的代价。反思这次的项目需求分析阶段，我主要犯有以下几个失误：

(1)轻视用户和开发人员之间的沟通

在软件开发过程中主要有两种角色：用户和开发人员。需求获取和需求调研是双方沟通的第一步。在小型软件项目中，由于双方都认为项目需求比较简单，就会对需求的描述产生一定的轻视，从而只用几句简单的话来描述。但实际上即使需求调研时用了详细的文字很完善的说明后，用户与开发人员之间还是会存在着或多或少的理解差异。因为文字性的描述总是缺乏精确性，更何况只是几句简单的描述。

实际上，就算是小型开发项目，其需求获取也可能是最困难、最关键、最易出错的方面。原因是用户可能会对软件开发过程不熟悉，或对自己的需求表达不清楚，而开发人员则对用户的业务流程不熟悉。在这种场合下，开发人员如果单单通过问/答的方式，或者更恶劣一点--只听不问的方式，是无法获取到真正需求的。因为有时候连客户自己也不清楚自己想要的是什么。还有用户表达的同一需求，不同的需求调研人员也可能会有不同的理解。而如果需求调研人员理解错了，就可能会导致以后的开发工作劳而无功。所以，如果因为需求简单就轻视的话，必然会导致后期大量的返工和修改。

(2)需求在开发前没有被准确地描述

在反思这次项目的失败原因时，我发现有时连客户对自己的需求也只有朦胧的感觉，或常常也说不清楚具体的需求。例如，用户可能很善于叙述其目标、对象以及他们想要前进的大致方面，但对于他们想要实现的细节却不甚清楚和难以确定。于是用户就会要求需求分析人员替他们设想需求，但需求分析人员要想详细而精确的定义用户心中的需求无疑是很困难的。结果是我们开发完成后，客户却认为这不是他们需要的。这种事情一而再，再而三的发生。不但让我们的开发人员哭笑不得，而且还无言以对。

(3)用户需求变更频繁，造成开发模式日渐紊乱

随着时间的推移，用户会对系统的界面、功能和性能等方面提出更高更多的要求。例如，在开发项目过程中，用户随时会提出一些新的需求，有时是在开发阶段中，有时在开发阶段后。而且，这些需求往往是后一次的需求与前一次不一致，也就是所谓的需求变更。后果是在开发中不断补充的需求使到项目越变越庞大，以致超过其计划及预算范围。

正常的需求变更本来也没有什么大事情，但由于我们在开发模式上没有对需求修改有足够的准备，结果是频繁的变更把整体结构变得日渐紊乱，补丁代码使得整个程序难以理解和维护。不但插入的补丁代码使模块违背强内聚、松耦合的设计原则，而且不断的收回变更和删除特性导致了更多的问题，例如出现软件质量明显下降等现象。

原型法工具使项目浴火重生

      看着日渐走向失败的项目，一筹莫展的我心里是哪个的焦急。这时，一位资深的软件需求分析前辈提示我，为何不尝试一下原型法工具。后来，我在应用原型法进行需求分析后，项目才得以起死回生。真所谓是：山穷水复疑无路 柳暗花明又一村;不经一事，不长一智。

(1)什么是开发项目的需求分析?

      软件开发中最为困难的是要准确知道应该要开发些什么。因为一旦需求分析做错了，不但会给系统功能带来极大的损害，并且不断的修改也会浪费资源。有资料表明，现在的软件项目中返工开销几乎占了总开发的一半，而导致返工的主要原因就是需求分析不明确。

软件需求分析(Software Requirement Analysis)是一个项目的开端，也是项目最重要的关键点。它的定义是指研究用户想要得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，并建立可确认的、可验证的一个基本依据。曾有调查报告显示，软件产品存在不完整性、不正确性等问题，80%以上是由于需求分析错误所导致的，而且由于需求分析错误造成功能性问题尤为突出。所以，一个成功的需求分析是软件项目能否成功的关键一步。因此，在软件开发中产生了一个核心问题：如何在用户需求不明确的情况下进行系统开发?

(2)什么是原型法?

软件需求分析方法有很多，如传统方法、原型方法、模型驱动方法、结构化方法等。一般来说，选择那种方法要根据项目的具体情况和资源来选择，不能盲目套用。这里着重阐述原型法。

原型法(Prototyping)的理念是指在获取一组基本需求之后，快速地构造出一个能够反映用户需求的初始系统原型。让用户看到未来系统的概貌，以便判断哪些功能是符合要求的，哪些方面还需要改进，然后不断地对这些需求进一步补充、细化和修改。依次类推，反复进行，直到用户满意为止并由此开发出完整的系统。简单的说，原型法就是不断地运行系统的"原型"来进行揭示、判断、修改和完善需求的分析方法。

(3)原型需求分析法的特点

原型法是一种循环往复、螺旋式上升的工作方法，它更多地遵循了人们认识事物的规律，因而更容易被人们掌握和接受。原型法强调用户的参与，特别是对模型的描述和系统需求的检验。它强调了用户的主导作用，通过开发人员与用户之间的相互作用，使用户的要求得到较好的满足。不但能及时沟通双方的想法，缩短用户和开发人员的距离。而且能更及时、准确的反馈信息，使潜在问题能尽早发现并及时解决，增加了系统的可靠性和适用性。

简单的说，原型法是将系统调查、系统分析和系统设计合而为一，使用户一开始就能看到系统开发后是一个什么样子。而且用户参与了系统全过程的开发，知道哪些是有问题的，哪些是错误的，哪些需要改进等，就能消除用户的担心，并提高了用户参与开发的积极性。同时，用户由于参与了开发的过程将有利于系统的移交、运行和维护。

但需要注意的是，原型法的适用范围是比较有限的。它只对于小型、简单、处理过程比较明确、没有大量运算和逻辑处理过程的系统比较合适。它的局限性是对于大型的系统不太适合，因为对于需要大量的运算、逻辑性较强的程序模块，原型法是很难通过简单的了解就构造出一个合适的模型，供用户评价和提出修改建议。

使用原型法进行需求分析的流程

(1)快速分析，弄清用户的基本信息需求

需求分析原型法的第一步是在需求分析人员和用户的紧密配合下，快速确定软件系统的基本要求。也就是把原型所要体现的特性(界面形式、处理功能、总体结构、模拟性能等)描述出一个基本的规格说明。快速分析的关键是要选取核心需求来描述，先放弃一些次要的功能和性能。尽量围绕原型目标，集中力量确定核心需求说明，从而能尽快开始构造原型。

这个步骤的目标是要写出一份简明的骨架式说明性报告，能反映出用户需求的基本看法和要求。这个时候，用户的责任是先根据系统的输出来清晰地描述自己的基本需要，然后分析人员和用户共同定义基本的需求信息，讨论和确定初始需求的可用性。

(2)构造原型，开发初始原型系统

在快速分析的基础上，根据基本规格说明应要尽快实现一个可运行的系统。我在这个项目得到的经验是原型系统可先考虑原型系统应必备的待评价特性，暂时忽略一切次要的内容。例如安全性、健壮性、异常处理等。如果这时为了追求完整而把原型做得太大的话，一是需要的时间太多，二是会增加后期的修改工作量。因此，提交一个好的初始原型需要根据系统的规模、复杂性和完整程度的不同而不同。本步骤的目标是：建立一个满足用户的基本需求并能运行的交互式应用系统。在这一步骤中用户没有责任，主要由开发人员去负责建立一个初始原型。

(3)用户和开发人员共同评价原型

这个阶段是双方沟通最为频繁的阶段，是发现问题和消除误解的重要阶段。其目的是验证原型的正确程度，进而开发新的原型并修改原有的需求。由于原型忽略了许多内容和细节，虽然它集中反映了许多必备的特性，但外观看起来还是可能会有些残缺不全。因此，用户可在开发人员的指导下试用原型，在试用的过程中考核和评价原型的特性，也可分析其运行结果是否满足规格说明的要求，和是否满足用户的愿望。并可纠正过去沟通交流时的误解和需求分析中的错误，增补新的要求，或提出全面的修改意见。

总的来说，原型法是通过强化用户参与系统开发的过程，让用户获得系统的亲身体验，找出隐含的需求分析错误。原型需求分析法是鼓励改进和创造，通过不断交流来提高需求实现的质量和软件产品的质量，目的是为了更好的提高客户满意度。