从一则笑话到需求分析

　　小编导读：回顾软件开发上的许多案例，软件开发失败率一直居高不下，特别在外包开发领域中，这个值可能会更高一筹。在分析项目失败的原因时，需求的因素可能是失败的关键原因，需求不明确，客户对需求的变更频频等等。
　　某日，老师在课堂上想考考学生们的智商，就问一个男孩：“树上有十只鸟，开枪打死一只，还剩几只？”
　　男孩反问：“是无声枪么？”
　　“不是。”
　　“枪声有多大？”
　　“80100分贝。”
　　“那就是说会震得耳朵疼？”
　　“是。”
　　“在这个城市里打鸟犯不犯法？”
　　“不犯。”
　　“您确定那只鸟真的被打死啦？”
　　“确定。”老师已经不耐烦了，“拜托，你告诉我还剩几只就行了，OK？”
　　“OK。鸟里有没有聋子？”
　　“没有。”
　　“有没有关在笼子里的？”
　　“没有。”
　　“边上还有没有其他的树，树上还有没有其他鸟？”
　　“没有。”
　　“方圆十里呢？”
　　“就这么一棵树。”
　　“有没有残疾或饿得飞不动的鸟？”
　　“没有，都身体倍棒。”
　　“算不算怀孕肚子里的小鸟？”
　　“都是公的。”
　　“都不可能怀孕？”
　　“，决不可能。”
　　“打鸟人的眼有没有花？保证是十只？”
　　“没有花，就十只。”
　　老师脑门上的汗已经流下来了，下课铃响起，但男孩仍继续问：“有没有傻的不怕死的？”
　　“都怕死。”
　　“有没有因为情侣被打中，自己留下来的？”
　　“笨蛋，之前不是说都是公的嘛！”
　　“同志可不可以啊！”
　　“，性取向都很正常！”
　　“会不会一枪打死两只？”
　　“不会。”
　　“一枪打死三只呢？”
　　“不会。”
　　“四只呢？”
　　“更不会！”
　　“五只呢？”
　　“绝对不会！！！”
　　“那六只总有可能吧？”
　　“不可能！”
　　“好吧，那么所有的鸟都可以自由活动么？”
　　“完全可以。”
　　“它们受到惊吓起飞时会不会惊慌失措而互相撞上？”
　　“不会，每只鸟都装有卫星导航系统，而且可以自动飞行。”
　　“恩，如果您的回答没有骗人，”学生满怀信心地回答，“打死的鸟要是挂在树上没掉下来，那么就剩一只，如果掉下来，就一只不剩。”
　　老师当即倒地。
　　当然这只是一个笑话，笑过之后可能不少人会认为这个小朋友是做需求调研的最佳人选。回顾软件开发上的许多案例，软件开发失败率一直居高不下，特别在外包开发领域中，这个值可能会更高一筹。在分析项目失败的原因时，需求的因素可能是失败的关键原因，需求不明确，客户对需求的变更频频等等。
　　一、需求的调研
　　需求调研是为需求说明书做前期工作，可以说需求说明书是从需求调研表中得到或抽取出来的。需求调研是要了解客户希望所要开发的系统能够解决他们的问题，以及了解他们对系统的期望等等。需求调研是整个开发的基础，经过需求调研的结果整理出需求说明书作为后续开发使用。
　　如果所做项目是一个陌生的行业（专业），往往需要专家或者顾问等角色的协助。但是作为调研人员最少要想办法了解这个行业，或许你需要成为这个行业的专家，但最少要了解一定的专业知识（最少专业词汇你要知道）。这样客户的沟通才能达到顺畅，不会出现牛头不对马嘴的现象。
　　在某些难度不是很大的行业或者项目，做需求调研的时候可以通过自学的方式了解行业的特点，这些项目往往因为规模比较小，也不需要专家指导。但是作为调研的时候我们最需要了解的一些问题如，
　　1、客户目前的问题与困难；
　　2、客户现在的工作模式；
　　3、客户对系统的期望；
　　4、客户哪些要求是自己能做到的，哪些是依靠系统来做；
　　5、客户对系统开发方式以及时间的要求等等。
　　其实做需求调研的时候最重要的目的在于资料收集，或许小孩的那种打破砂锅的方式会引起客户的反感，但是实际项目中往往需要的就是这些比较周全的调研方式，能够考虑到的问题点都需要和客户确认，尽量避免想当然的做法，只是采用的方式可能需要优化一下，采用良好的方式，尽量得到客户的最大配合。
　　二、需求的描述和确认
　　对于需求的调研内容需要进行整理和分类，分清有用功能、可选用功能、无用功能及不可实现功能。对于这些功能和客户再次确认之后才能最终形成开发的需求文档。对于需求的描述有很多方法和工具，但是无论采用哪种方法和工具都是相对抽象的方式，如何让客户能够理解需求的实际内容，需要客户有良好的理解能力，毕竟系统还只是纸面上的内容，客户还是很难完全了解到真实的系统。
　　如何对需求进行描述在项目开发中是一个很难定夺的题目，有些公司采用Demo的方式，有些采用传统的功能树方式，有些采用界面的描述方式，有些采用UML建模的方式，形式多种多样，各种方式都有其好坏。但是对于方式的选择需要注意一些问题，
　　1、了解客户是否能够理解所描述的问题；
　　2、避免先入为主；
　　3、避免形式主义。
　　有些公司采用UML描述需求，但是客户的能力达不到能够理解UML所描述的问题，甚至公司内部的开发人员也无法很好的理解UML，可能只有需求人员懂UML，这种需求结果就值得思考，客户是否知道你在说什么？如果你先入为主使用这种方式来描述问题，难道期望客户去学习这些知识吗？
　　三、需求的控制
　　客户往往很难知道他们需要什么样的系统，有时候系统做到一半的时候客户会提出一些新的想法，甚至等系统上线的时候客户才发现系统和他们脑子里想的东西完全不是一回事。对于这些可能会说当初需求定义的时候不是签过字，确定做成这样，怎么不是你想要的呢？问题可能会归根于与客户沟通的方式和手法上。但是对于需求的控制来说，对如何避免需求的反复，客户脑门一热就有新点子出来，还有许多不切实的要求等等，都在需求控制范围内。