1前言

读者试用范围：需求调研人员、小组组长、开发人员等。

撰写本文目的：培训项目组成员需求调研过程中的工作技能。

需求调研是为需要说明书撰写做前期工作，需要说明书是从需求调研表中得到或抽取而出；是了解实际工作中真正需要什么样的程序的过程，再把这些需求细节整理由设计部开发，给用户使用。

需求调研在系统开发和部署试用阶段尤为重要，如何把项目组工作成果成功推广使用，得到用户的肯定认可是后期需求调研的重中之重。

开发软件系统最困难的部分就是准确说明开发什么。一旦出错会给系统带来极大伤害，并且以后对它修改也极为困难。

2 项目类需求调研的特点

•  《需求规格说明书》的出具比较仓促，质量低

1. 不切实际的工期（需求调研成了走过场）
2. 用户方怕担责任的心态（模棱两可的说法）
3. 认知程度的限制（项目达到的预期是什么？调研人员错误的理解，怕引出额外诉求）
4. 迫于工期压力，各方妥协签字了（没有争取广泛的支持）

 

• 大部分需求是《需求规格说明书》出来以后出来的

1. 程序被迫使用，与切身利益相关，被迫重视（流程、易用性、工作量全来了）
2. 用户认知程度逐渐被引导，使用积极性提高，提出更多的功能诉求

 

结论：作为项目组设计开发人员来说，做好后期的需求调研工作是项目成败的关键！

3 项目组前期准备

3.1    确定调研工具

选取需求调研过程中的一些辅助工具，选取要求是自己（本组）熟悉的工具， 工具最好也是要求是普通流行的，因为要考虑交流的问题。

如：WORD、EXCEL、PPT、POWERDESIGNER、STARTUML等。

3.2    调研项目前期情况

对象：售前人员、商务人员；

内容：招标书、答标书、合同、以及其他与用户交流的口头或书面材料（包括宣传、承诺等）

甲方行业情况的了解、最好看一些行业方面的书籍，学习业务领域知识

3.3    建立需求调研规范

一定建立一个专门的设计环境（文档目录）来为本项目服务，进行一定的资源分配，进行必要的文件管理。

1. 统一项目所用的工具
2. 统一项目文件模版
3. 其它资源列表（资料，相关网站，资询电话）

3.4    明确客户方组织结构

用户单位的组织机构是什么，哪些部门和人员岗位参与本系统的使用？上下级关系如何？

为项目组建立起外部联系通讯录。

3.5    制定项目的调研计划

调研计划制定目的：对调研活动序列进行划分、评估、资源分配。在制定计划时考虑到分析时间。计划在公司内部评审通过后，及时提交给客户，让客户对调研计划有充分的了解。

调研计划包含的内容：

1. 调查什么？通过什么方式调查？何人何时调查？
2. 明确项目组人员分工（培养我们的专家）
3. 调研中大家遵循的约定（如：不不需要签字？何时召开例会等）
4. 针对需求中的功能模块，客户方有明确的唯一配合联系人

注意事项：

项目任务书下达给后，项目经理及调研人员应该对合同中软件范围认真审阅，虽然只大概写了需求范围，但这些信息及为重要，它是调研计划制定的一个依据。

计划制定后最好召开项目启动会议，相关领导和业务部门参与，确定双方项目组成员，确定客户方的配合人（唯一联系人）、领导（唯一协调人），介绍项目组的人员安排、总计划、需求调研计划将行程和计划通知客户。上会以资重视。

 

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    这个比较难呢

我们编写完的需求分析报告，最终要展示给客户，让他们对我们的分析结果进行认可。其实这个过程非常重要，对于客户和我们同样的重要。将业务需求与用户进行确认（采用会议讲解的方式），用户领导签字。