需求分析，在大公司可能并不需要项目经理主导，有专门的需求分析师和架构师去完成这个工作，中小公司可能仍然需要项目经理充当主角，由项目经理负责与甲方业务人员共同完成需求的收集、整理以及分析工作。
不管哪种情况，项目经理都必须对业务充分了解，只有这样才能更好地把控项目的进度，而且了解业务的最佳场合就是需求搜集阶段，这个阶段可以和甲方业务人员充分接触，充分了解对方的业务。
很多项目经理是从开发工程师转变而来，对什么是业务有些人云亦云，很多人只要一谈到业务就立即联想到系统和平台，这种做法有些欠妥。我们说的业务，是指甲方的业务，换句话说就是甲方每天干的工作，但是，我们显然并不需要了解全部，而只是一部分，而系统只是对这些业务的线上体现。为了充分理解甲方的业务，我们需要在需求分析阶段获取很多的信息，下面我针对这个阶段的工作提一些建议：
1、首先我们需要准备一些必要的工具，本子、笔、录音笔、照相机、文件夹等是必须的。很多人就带一双耳朵，回来全凭回忆，这是不建议的；
2、准备一些需求分析文档的模板，输出文档一定要正规化；
3、准备好调研清单，这份清单不是苦思冥想出来的，要有根据。在制作清单之前，我们先要初步了解对方的业务，主要是依据对方的网站或搜索出来的零星资料，顺便了解一下对方有哪些系统。然后根据这些了解到的内容结合自己的理解，形成调研清单。清单中的内容很多，我这里也无法一一列举，这里给大家一些常用的方法，了解对方都有哪些部门，就是组织结构。了解对方的产品是什么，实际上就是生产什么？了解生产过程如何？概括起来就是过程、操作者、输入、输出。抓住这几点，基本上就可以理清思路。
另外，清单上也要问及对方的IT建设情况，为后续的平台部署做好准备。
4、准备一份申请书，向对方申请调研，上面有调研日期、天数、调研对象(部门或个人)、调研主题、调研方式、日程安排等。
5、将申请书和调研清单提交本公司领导和销售，一般会由销售和对方联络人进行沟通，约定时间；
6、调研时一般会按照申请书上的调研计划去进行，如有临时变更的，一定要提前和对方商议，另外，未经对方允许，不要随意向其他无关的人询问甲方情况，这是比较忌讳的。
7、每天的调研内容要及时汇总形成需求文档，并在小组进行交流，如果遇到问题，及时加入调研清单，以备次日向对方咨询；
8、需求调研只是需求分析的第一个环节，需求调研形成的文档也原始需求文档，也叫需求说明书，这个需求说明书只是记录了一条一条的需求，不存在主观地分析。但是这个需求说明书一般也会让甲方负责人签个字，但是大多数人不会去签，这没有太大的关系，所谓的签字仅仅表示该需求属实而已。
9、需求说明需要经过认真地分析，这种需求分析的过程是非常复杂的过程，需要依赖理论的支持和经验的积累，限于篇幅，我无法在这里详细描述，今后我会安排专门的系列来介绍如何进行需求分析。需求分析的结果就形成了需求分析说明书，也就是我们通常所说的需求分析规格说明书。这个说明书一方面将用户的需求进行条理化，从而更加清晰和容易理解，另一方面为概要设计提供了原始的业务框架。
需求分析规格说明书是需要按照一定的模板来进行撰写，一般甲方可能都要求提供这个文档，一方面为了存档，另一方面也为了今后维护系统提供依据。
10、注意穿着正式，言行规范。
需求调研分析阶段是很重要的环节，也属于重要的里程碑节点，很多甲方就是从这时开始结算，所以要非常重视。同时还有一个重要的方面就是，很多甲方都选择在这个时候近距离观察项目团队，稍有不慎，就会造成恶劣的影响。
