某日，老师在课堂上想考考学生们的智商，就问一个男孩:“树上有十只鸟，一只，还剩几只？”
“恩，如果您的回答没有，”学生满怀信心的回答，“的鸟要是挂在树上没掉下来，那么就剩一只，如果掉下来，就一只不剩。”
正值六一儿童节之际，用这篇笑话故事来做开头，笑过之后可能不少能会认为这个小朋友是需求调研的最佳人选。回顾软件开发上的许多案例，软件开发失败率一直居高不下，特别在外包开发这个领域中，这个值可能会更高一筹。在分析项目失败的原因的时候，需求的因素可能是失败的关键原因、需求不明确，客户对需求的变更频频等等。
需求调研是为需要说明书做前期工作，可以说需要说明书是从需求调研表中得到或抽取而出。需求调研是要了解客户希望所要开发的系统能够解决他们的问题，以及了解他们对系统的期望等等。需求调研是整个开发的基础，经过需求调研的结果整理出需求说明书作为后续开发使用。
如果做的项目是一个陌生的一个行业（专业），这是往往需要专家或者顾问等角色的协助，但是作为调研人员最少要想办法了解个专业，或许你需要成为这个行业的专家，但最少要了解一定的专业知识（最少专业词汇你要知道）。这样客户的沟通才能达到顺畅，不会出现牛头不对马嘴的现象。
在某些难度不是很大的行业或者项目，做需求调研的时候可以通过自学的方式了解行业的特点，这些项目往往因为规模比较小，也不会有专家的影子出现。但是作为调研的时候我们最需要了解的一些问题如：
其实做需求调研的时候最重要的目的在于资料收集，或许小孩的那种打破砂锅的方式会引起客户的反感，但是实际项目中往往需要的就是这些比较周全的调研方式，能够考虑到的问题点都需要和客户确认，尽量避免想当然的做法，只是采用的方式可能需要优化一下，采用良好的方式，尽量得到客户的最大配合。
对于需求的调研内容需要进行整理和分类，分清有用功能、可选用功能、无用功能及不可实现功能。对于这些功能和客户再次确认之后才能最终形成开发的需求文档。对于需求的描述有很多的方法和工具，但是无论采用那种方法和工具都是相对抽象的方式，如何让客户能够理解需求的实际内容，需要客户有良好的理解能力，毕竟系统还只是纸面上的内容，客户还是很难完全了解到真实的系统。
如何对需求进行描述在项目开发中是一个很难定夺的题目，有些公司采用Demo的方式，有些采用传统的功能树的方式，有些采用界面的描述方式，有些采用UML建模的方式，形式多种多样。各种方式都有其好坏。但是对于方式的选择需要注意一些问题：
有些公司采用UML描述需求，但是客户的能力达不到能够理解UML所描述的问题，甚至公司内部的开发人员也无法很好的理解UML，可能只有需求人员懂UML，这种需求结果就值得思考，客户是否知道你在说什么？如果你先入为用这种方式来描述问题，难道也期望客户去学习这些知识吗？
客户往往很难知道他们需要什么样的系统，有时候系统做到一半的时候客户会提出一些新的想法，更甚至等系统上线的时候客户才发现系统和他们脑子里想的东西完全不是一回事。对于这些可能会说当初需求定义的时候不是签字下来说是做成这样，怎么不是你想要的呢？问题可能会归根于与客户沟通的方式和手法上，但是对于需求的控制来说，对如何避免需求的反复，客户脑门一热就有新点子出来，还有许多不切实的要求等等，都在需求的控制范围内。
有些人会说我们和客户说好了，协议也签订说：除了纸上描述的东西之外，其余的都是变更追加。但是这个观点固然好，也是完全归于一方有利来考虑，而且有很多时候我们签署在合同内的需求文档也比较含糊，而且双方在问题的理解上可能会有歧义，一旦真正要将合同拿出来对峙的时候，我想彼此都很难对方。就像树上有十只鸟一样，没有说好，状态等等的假设，一切的结果应该说都可能是合理的。
如何控制需求，我想除了软件工程上提出的那些理论之外，也很难有新的观点，但是在实际的操作过程中，我们可能一方面要和客户的关系，另一方面也要考虑系统的开发时间和整体工数等等，做一个权衡。不过我个人更趋向使用问题具体化的方式来控制，尽量将能够想出的问题通通罗列出来和客户确认，同时采用换位思考的方式，尽量能够让客户理解我们所描述的系统的状况，如果在调研和需求的确认阶段能够把工作做得很好，在后期的开发过程中变更的内容就会比较少，变更的内容也就容易控制。
和客户进行良好的沟通，多为客户做一个考虑，避免将自己以一个姿态介入和客户的沟通中，说一些客户很难懂的专业术语，将客户喷的云里雾里，自以为自己的专业领域多么了不起，这种和客户的共通方式最容易造成需求空洞，后期翻盘的概率很高。如果客户不懂你口中所说的内容，可能问题出于客户，另外更大的程度出于你，我们需要考虑采用的沟通的方式以及内容是不适通俗易懂，能将复杂的问题讲的简单就表示你不简单。
推荐：
网友评论 ()条 查看