注：之前一直从事幕后“积木搭建”工作，此次是第一次从需求调研开始到需求评审通过全程跟踪经历。在调研前，作者所属调研组计划在两周之内搞定需求过程，完成最终文档的评审工作，最后，现实花了我们一个月的时间完成预期的工作内容。

一、网上释义

对于需求调研，网上评价较高的相关文章是这样解释的：

1、需求调研是为需求说明书做前期工作，可以说需求说明书是从需求调研表中得到或抽取而出。

2、需求调研是要了解现实世界中做实际工作的人们真正需要什么样的程序的过程，再把这些需求进行细节整理由设计及开发部门设计开发，最后产出用户真正需要的产品。

二、需求文档的重要性及初期架设

结合以上解释，需求文档显然是重中之重，它将是需求的终极成果，在调研之初就要在做好最初架设工作。因此：

1、从需求调研开始调研者就应该对要呈现客户面前的需求文档结构（一般公司有提供模板）有一个清醒的认识；

2、在调研之初，根据合同要求的项目签订模块内容，架设自己脑中的项目原型（可以虚拟，至少有一个笼统性的意识）；

3、把对项目的架设方案在文档中以清晰地层次关系记录编写，形成文档雏形（即使只有简单的各主标题、下层级标题的空文档）。

显然，在文档的初期架设并不是一个简单的过程，其中要求的一个很重要的条件是系统分析师必须对整个系统要有非常的深刻的认识，而且在对相关系统认识的面上要广。在作者接触的该需求过程中，因为之前都是完成逐个模块化功能完成“搭积木式”的开发工作，并没有对相关系统有一个全面深刻的认识，所以在需求文档的初步架设时，没能做好工作，也导致之后的需求调研会上的尴尬，吸取了不少经验教训。好在作者并不是一个人，强大的调研组让作者不用面对很多来自客户及第三方的尴尬。

三、建立、磨合与甲方项目负责人、相关人的关系

甲方项目负责人（以下简称项目负责人）负责整个项目的周期，负责系统研发过程中的甲方乙方的交流协同工作，是系统使用者与开发人员的沟通桥梁，把握好与项目负责人之间的微妙关系至关重要。项目相关人可能是上级领导、系统直接使用人、第三方开发者等，也直接关系到需求获取、变更、系统体验获取、改善等环节的交流，是项目研发过程不可缺少的成员，其重要性也可见一斑。至于如何把握好人际关系相信读者自有体会，在此不做相关讨论，作者只从项目需求角度作简要分析：

1、根据对甲方的预期需求的理解，针对不清楚之处，向项目负责人提出疑问，得到适当回答内容，做相应记录；

2、询问项目负责人相关项目的项目组人员，并由项目负责人介绍，会见相关人员；

3、初次会面时，针对相关人员、领导，介绍项目总体情况，征求相关意见并要求相关人员调研过程中给予配合，尤其是系统的直接使用者。

4、定期向项目负责人发送周报（非必要）。

四、做好每次调研会议计划

调研会议是需求调研中最为重要的环节，需求过程中所有的调研会议是需求获取的主要来源（其他来源还有项目负责人等，因为项目负责人对自己公司业务熟悉，对相关人员的业务描述较容易转化为系统实现，且会做相关的补充），要完成一次完美的调研会议，显然会议计划必不可少。基于本次的调研过程，作者认为调研会议计划需要注意：

1、系统分析人员事前必须非常清楚自己想要什么，要项目相关人员做些什么，要他们提供什么信息，这样才能有目的性的提出相关问题，避免偏题跑题的会议；

2、必须清楚本次调研内容的归口人，也就是说要有针对性地确定参会人员，每次会议都让一批人来听两个人的讨论会令人反感；

五、做好调研会的提问、讲解及演示

毫无疑问，这是调研人员必备素质，是调研过程中最为重要的内容。调研会议过程能体现出系统分析是的专业程度及项目分析方法的掌握程度，没有扎实的专业功底，在该环节会出现诸多尴尬，作者由于相关专业知识欠缺，便在这环节除了不少问题，此文就且当做经验之谈吧，寄望能在系统分析方面茁壮成长。基于本次各个调研会议，作者有以下认识：

1、提问时，对要问的问题有条理性，要想想当前功能点能否实现，之前是怎么实现的，可以怎么样实现等，相关功能点的提问尽量全面；

2、可以在提问的时候尽量引导客户往对项目和系统实际应用最佳的方式走，因为可能业务人员之前没用过相关系统，没有相关概念，很多标准是在需求时调研组帮客户定的，当然关键的是帮客户定的标准要保证充分的科学性；

3、在调研的提问、讲解及演示过程中，尽量少用业内专业术语，不要用系统研发方式语言跟客户进行交流，站在用户的角度提问、答问，这样才能让人知所以然，可能你觉得很简单的术语，在业务人员看来很生涩，这样会浪费更多的时间在解释上；

4、在交流过程中记得做关键点的记录，很多时候你觉得你明白的某个功能点经过几个小时的会议之后，又会是一片模糊，记得养成会议记录的习惯，这样不至于浪费更多的时间在同样问题上，而且方便需求获取的信息整理，方便需求文档的编写；

5、存在第三方接口的调研情况下，应该事先跟第三方达成一致，完后才跟客户进行确认、答疑，对客户或第三方提出不能实现的功能，给予回绝或转包；

6、需求讲解、演示的时候尽量抓重点讲，不用每个点都很细致地讲解，把握时间与会议内容的平衡，才不至于拖延会议时间或者没最终完成会议演示计划；

7、当客户谈及与系统无关或偏离系统需求的事情时，找适当时机把话题转回来，不要发生会议主题变质；

8、适当拉动调研会议气氛，让会议朝你想象的方向走。

六、需求文档该注意的

前面说过，需求文档是调研成果的体现，决不能在需求文档上含糊，需求文档是系统分析人员的基本功之一，系统分析人员应该把需求文档当成产品看待，让客户看到的各文档版本应该是可读、条理、规范、专业的产品化文档。作者在调研需求文档编写过程中，出现了很多专业分析员不应该出现的问题（作者目前非专业系统分析员），需求文档看上去只是很简单的一个文档，但是把调研过程的需求获取内容清晰有条理、以专业化的语言整合到一起，以文档形式展现，并非易事。在此暂不讨论需求文档如何编写之类问题，作者只谈需求整合过程中的感受：

1、每次调研会议结束后，理顺对每次的调研会议记录内容，根据会议内容对需求文档更新；

2、文档编写过程中，对功能点的描述尽量详细，有条理，让人知其所以然，做到让开发人员看到文档知道要做成什么样的功能，不要一笔带过、简单描述或内容杂糅。例如一个审批流程每个节点每个过程分点描述，不宜在一段话中描述一个流程从始至终的操作过程，这样会让阅读者感到吃力；

3、需求文档的编写是不断完善、不断改进的过程，不可能在一次的编写就完成主要功能点的描述，需要不断地鹅推敲、琢磨；

4、确认需求文档版本，保证每次提交给项目负责人及相关人员的文档版本不一样。

以上纯属作者实践后理论性理解，篇幅原因，文章较少实例分析，希望对阅读者略有帮助。

本文章归目油菜所有，转载请注明出处。