| 1前言
读者试用范围：需求调研人员、小组组长、开发人员等。
撰写本文目的：培训项目组成员需求调研过程中的工作技能。
需求调研是为需要说明书撰写做前期工作，需要说明书是从需求调研表中得到或抽取而出；是了解实际工作中真正需要什么样的程序的过程，再把这些需求细节整理由设计部开发，给用户使用。
需求调研在系统开发和部署试用阶段尤为重要，如何把项目组工作成果成功推广使用，得到用户的肯定认可是后期需求调研的重中之重。
开发软件系统最困难的部分就是准确说明开发什么。一旦出错会给系统带来极大伤害，并且以后对它修改也极为困难。
2 项目类需求调研的特点
《需求规格说明书》的出具比较仓促，质量低
不切实际的工期（需求调研成了走过场）
用户方怕担责任的心态（模棱两可的说法）
认知程度的限制（项目达到的预期是什么？调研人员错误的理解，怕引出额外诉求）
迫于工期压力，各方妥协签字了（没有争取广泛的支持）
大部分需求是《需求规格说明书》出来以后出来的
程序被迫使用，与切身利益相关，被迫重视（流程、易用性、工作量全来了）
用户认知程度逐渐被引导，使用积极性提高，提出更多的功能诉求
结论：作为项目组设计开发人员来说，做好后期的需求调研工作是项目成败的关键！
3 项目组前期准备
3.1 确定调研工具
选取需求调研过程中的一些辅助工具，选取要求是自己（本组）熟悉的工具， 工具最好也是要求是普通流行的，因为要考虑交流的问题。
如：WORD、EXCEL、PPT、POWERDESIGNER、STARTUML等。
3.2 调研项目前期情况
对象：售前人员、商务人员；
内容：招标书、答标书、合同、以及其他与用户交流的口头或书面材料（包括宣传、承诺等）
甲方行业情况的了解、最好看一些行业方面的书籍，学习业务领域知识
3.3 建立需求调研规范
一定建立一个专门的设计环境（文档目录）来为本项目服务，进行一定的资源分配，进行必要的文件管理。
统一项目所用的工具
统一项目文件模版
其它资源列表（资料，相关网站，资询电话）
3.4 明确客户方组织结构
用户单位的组织机构是什么，哪些部门和人员岗位参与本系统的使用？上下级关系如何？
为项目组建立起外部联系通讯录。
3.5 制定项目的调研计划
调研计划制定目的：对调研活动序列进行划分、评估、资源分配。在制定计划时考虑到分析时间。计划在公司内部评审通过后，及时提交给客户，让客户对调研计划有充分的了解。
调研计划包含的内容：
调查什么？通过什么方式调查？何人何时调查？
明确项目组人员分工（培养我们的专家）
调研中大家遵循的约定（如：不不需要签字？何时召开例会等）
针对需求中的功能模块，客户方有明确的唯一配合联系人
注意事项：
项目任务书下达给后，项目经理及调研人员应该对合同中软件范围认真审阅，虽然只大概写了需求范围，但这些信息及为重要，它是调研计划制定的一个依据。
计划制定后最好召开项目启动会议，相关领导和业务部门参与，确定双方项目组成员，确定客户方的配合人（唯一联系人）、领导（唯一协调人），介绍项目组的人员安排、总计划、需求调研计划将行程和计划通知客户。上会以资重视。
4 需求调研内容
4.1 需求调研要收集的内容
需求分析报告的读者有客户、设计人员、开发人员，在编写时一定要考虑到文档的可读性。需求调研形成的成果具体如下：
1) 收集用户需要产生的单据和报表 ；表单及报表的适用对象
2) 画出业务流程图，并认真检查和核对每条路径中是否完备，异常情况怎样处理（系统的动态特性）；
3) 依据流程图收集每个步骤需要的使用和操作的数据，确定数据的类型和范围（系统的静态特性）；
4) 画出业务实体及其关系，并估计业务实体的产生频率和数据量；
5) 评估业务流程和实体中需求变化的可能性；
6) 用户权限；
7) 信息系统建设现状；
8) 收集用户对系统界面风格、版式、颜色的偏好和需求；
9) 对系统将来使用的硬件、操作系统、网络情况进行了解；
10) 收集系统初始化数据，或者要求客户进行收集和整理，明确期限时间；
11) 编制简单界面原型（该步骤也可放在需求分析之后完成，再次和用户进行沟通）
4.2 形成的成果
《需求规格说明书》
系统原型
5 如何做好需求调研
5.1 要做什么就要先了解什么
如果对客户业务不熟悉，在调研前要先做好充分的准备。
如果做的项目是你所不了解的行业（专业），最好要有专家——最终用户做专家是最好的，调研要了解这个专业，不是要你成为专家，但最少要了解一定的专业知识（最少专来词汇你要知道），否则就不知道去问什么或如何去问他们，甚至于人家在说什么你也不知道。
相应的专业资料是必须的，最少要有专业入门书籍和对应的资料，也需要更深入的一些资料。当然有专家的参与就另当别论。
如果行业的难度不是很大，可以通过分析人员的自我学习在短时间内了解行业，也许可以不用专家，否则专家是必须的。
5.2 采用多种手段挖掘需求
重视调研资料的准备：调研资料（Rose图、Ppt、原型准备）一般客户图形化界面感兴趣，最好是采用图的方式把东西展示给用户，可以意思转换为用例图、用户界面、流程协作图、状态图等。
需求调研过程有选择的确定调查方式，例如：
12) 与客户交谈，向用户提问题
13) 参观用户工作流程，观察用户操作
14) 向用户发调查问卷
用户通常没有耐心回答论述题，所以应当以选择题和是非题为主。
15) 与同行、专家交谈，听取他们的意见
16) 分析已经存在的软件产品，提取需求
17) 从行业标准、规划中提取需求
18) 上网搜索相关资料
5.3 站在用户的立场上考虑系统功能
设身处地的成为用户，考虑适用型和用户体验；
用户的语言与用户交流；
总结以往的实施经验，提出建议
总结以往的实施经验，引导需求
*以上各条也是尽量减少需求变更的手段之一；
5.4 5W + 1H方法
5W：why、what 、who、when、where
1H：How to accomplish(实现) the system?
WHY定律：WHY就是为什么用户要引入系统，引入新的信息系统对用户有什么帮助，在总体工作效能上如何实现一个最终的结果？WHY定律是要求在需求开始时，项目经理就应该明确的，这个项目是为了改进用户工作效率；提高部门间的协作机制；加快对客户反应的体系服务；提升企业的竞争力等等。有了这么一个WHY引入思想，项目经理就可以理清用户最终要的是可以提供给他们什么样的系统，在系统的定位和建立上，就有一个明确目标。
WHAT定律：有了一个总体的目标性，从各业务流程的要求入手，引入第二个W定律__-WHAT定律，WHAT则是这个系统要做什么？实现什么？提出各业务流程问题、流程局限性问题、系统要解决的问题等，在这个WHAT的基础上，把系统划分成各功能模块，逐步弄清模块流程需求、功能需求、结构需求。引入WHAT定律可以让我们了解到系统的初步需求
WHO、WHEN、WHERE定律：这个阶段是需求细化阶段，在WHAT定律的基础上，细分系统的用户需求：分析什么人，在什么时间，什么阶段可以或必须操作这个功能，结合前面的WHAT定律，理清系统的流程阶段划分，记录并分析系统功能实现的细节，在这个阶段就可以产生系统需求的用例图（Use
Case），作为下阶段设计的依据。
HOW定律：就是怎样实现系统了，在前面的WHY、WHAT、WHO、WHEN、WHERE基础上，已经搭建了一个非常好的系统需求基础框架，如何在这些用户需求的基础上，分析系统的需求，如何进行需求规格的分析与下阶段的设计、实现工作，就是How
to accomplish(实现) the system?
引入这5W+1H的定律，在一定程度上保证了系统需求的准确性，使得项目经理或需求分析人员可以有序、有条理地开展需求挖掘和调研活动，这样的安排用户在配合上也非常清晰，知道如何与项目人员配合。
5.5 调研注意事项
n 做好会谈纪要
一定要有记录的习惯，谈上几个小时，很多细节是记不住的。
n 守时守约
尊重别人才能让别人尊重自己。答应别人的事，尽量做到，做不到的及时交流说明原因。
n 调研前期准备
提前约定调研活动的计划，达到的目标，时间安排，参与的人员，并根据用户安排，适当调整计划。
最忌参加会议时目标不明确、汇报人员不明确。
n 铭记一把手原则
需求调研开始时，客户明确的唯一配合联系人既是我们每个模块的一把手！我们要做的就是“拿着鸡毛当令箭”！找对人才能办好事。
什么是一把手原则？任何信息管理系统的研发不但涉及到技术的复杂性、需用资源的密集性和用户需求的多样性，更涉及到管理思想、管理制度、管理方法、权力结构和人的习惯的改变，充分认识到这一点，要想确保系统研发的成功实施，单靠某一部门的努力无法顺利推行，必须将其列为“一把手”工程来抓，建立以“一把手”为首，相关部门领导参与的系统实施小组，组建由核心职能部门和业务部门负责人参加的实施团队，并把实施任务分解到项目应用的具体部门，使各个使用部门根据自身的要求，组织更多的力量和资源来推行系统的实施，从而可有效确保实施进度和实施效果。
n 客户永远是对的（学会聆听，态度决定一切）
不要一棒子打死异己的观点，尝试站在他人的立场思考问题，这样会更容易找到满意的答案。
n 拒绝不合理的需求
客户需要的不一定的是客户真正所需要想要的。客户永远没有错，错的只有我们没有真正理解客户的需要。
调研时要把握主题的能力，分清有用功能、可选功能用、无用功能及不可实现功能，及时表达我们的观点，让谈话接近主题。
n 功劳是客户的
n 随时强化调研成果
需求调研、相关会议纪要及时转发，及时总结成果，让客户听听你的理解是否他们提的需求一致。
定期汇总的成果：什么情况下？什么人？做了什么决定？产出了什么？
n 警惕不明确因素
实现某一个功能的前提条件是什么？如果没有哪个先决条件，哪些工作是无法开展的？责任划分清楚。
n 成本，成本还是成本
高水平的设计师高就高在设计出“恰好”满足客户需求的软件，并且在开发方和客户方获取最大的利益，而不是不惜代价设计出最先进的软件。
n 避免片面听取了某些用户的需求而忽视其他用户的需求
6 什么是成功的需求调研
6.1 需求规格说明书具备的特性
正确、清楚、无二义性、一致（各个需求之间不产生矛盾）、必要（不画蛇添足增加开发成本）、完备（不遗漏必要的功能如权限配置）、可实现性、可验证性（提供交付依据）、明确优先级（不被细节拖死比如UI）、阐述“做什么”而不是“怎么做”。
6.2 覆盖合同中所有合理的需求
对待需求工程的态度可以分为“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。
在实际工作中，可以建立合同与需求规格说明书对应章节对应表、合同与软件功能对应表。时刻提醒需要提供实现的业务范围。
6.3 成本风险在控制之内
6.4 挖掘潜在的需求
适当站在商务的立场上思考，为项目的寻找出路，申请更多的财力物力。
7 签字画押
7.1 如何形成习惯
7.2 这个比较难呢
我们编写完的需求分析报告，最终要展示给客户，让他们对我们的分析结果进行认可。其实这个过程非常重要，对于客户和我们同样的重要。将业务需求与用户进行确认（采用会议讲解的方式），用户领导签字。 |
