第6章 需求调研
需求调研，是整个软件工程中的第一步工作，要做好分析与设计，首先要做的事就是对客户需求进行咨询和调研，完整、准确地收集和记录客户的需求、期望、痛点和难点是正确地进行分析与设计的前提。
6.1 基本概念
6.1.1 定义与作用
1．定义
需求调研就是通过与客户／用户不断地沟通，采用包括问卷、访谈、绘图、收集原始资料等形式收集需求，并以图形、文字和表格的方式进行记录。需求调研就是收集系统需要做什么的过程。
2．作用
需求调研工作是决定软件开发能否成功的第一步，需求调研的质量对于应用软件的交付质量起着非常大的影响作用。需求调研的结果就是后续设计和开发的依据，因此，如果调研有了偏差或是遗漏，其结果就有可能导致后续的设计和开发工作都出现问题。反之，如果需求工程给出了非常全面、严谨、逻辑清晰的结果，就会让设计师与开发工程师可以非常顺利地进行后续的工作。
6.1.2 内容与能力
不论需求分析师采用何种方式进行调研，其结果都必须要按照“图、文、表”三种标准形式进行记录
6.1.3 思路与理解
1．用图形作为调研助手
对需求分析师来说，第一位的能力，不是知识、经验以及记录方法，而是与客户“沟通”的能力，例如遇到诸如调研之初如何打开“话匣子”？讨论僵持不下时如何解套？讨论中客户总出现跑题的现象如何应对？如何快速地打开局面或是控制局面？等等。一个非常行之有效的方法就是用“图形”来做引导，用图形做引导可以有如下的效果。
● 图形会引导大家的讨论方向一致、收敛，不易跑题。
● 图形会引起参与者的视觉共鸣，从而加速、加深理解的程度。
● 即使图形有错误，也可以调动起参与者的关心，成为吸引客户积极参与交流的“引子”。
● 图形的逻辑清晰，可以避免讨论结果似是而非的现象，为后续需求变动提供了证据。
另外，没有图作为调研助手，往往调研的结果只有“点需求、点功能”，而缺乏对客户业务的整体认知，特别是缺乏对“逻辑”的收集方法，造成后期的分析缺少逻辑支持，无法进行推演。
2．调研的合适粒度
关于需求调研的粒度要做到什么程度才算够呢？这个问题很难从正面回答，但是可以从结果上回答，那就是如果调研结束后，不需要再向客户进行咨询就可以进行设计工作了，那么这个调研就做到位了。否则，进入设计阶段了，还要再向客户进行咨询，例如，某个表单的公式不清楚、某个功能为什么需要、某个管控要做到什么力度等。第一次在现场沟通得越详细，调研的成本就越低，离开现场后需要再进行二次、三次的沟通，则调研成本就会增大（时间、费用、效率）。
6.2 需求调研方法
6.2.1 需求调研的准备
“知己知彼，百战不殆”，要想做好需求调研，必须要事前做足功课。调研前的准备工作是否充分决定了调研初期的沟通成本（时间、资源）。
1．背景资料的来源
事前了解客户的背景是十分重要的准备工作，了解客户背景就是调研工作的第一步，这些资料可以帮助事前做好准备，资料中的信息影响着与客户确定开发合同的内容、规模、金额、时间、技术复杂度等，了解客户背景可以有以下三个途径（不限于此）。
1）互联网从各类网站和媒体上可以快速地获得一些公开的企业基本信息。
2）宣传资料企业的各类宣传资料，会涉及企业的基本信息、产品、服务等。
3）人员沟通相对于从网站、宣传册中获得“过去时”的基本信息，通过市场销售人员可以了解到“现在时”的企业信息，这个信息的现实意义可能更大，可以利用的价值更多，包括：客户引入信息系统的目的、客户既存信息系统的情况，以及参与竞争的软件同行产品等。
2．背景资料的汇总
市场销售人员要对前述已经获得的信息进行梳理，做出一份背景分析报告，让需求分析师在调研开始前就掌握客户和项目的基本背景，让需求分析师在调研开始前就掌握客户和项目的基本背景，这样做带来的好处是：
● 勾勒出客户的“形象”，了解了这个形象后可以让需求分析师做到心中有数。
● 让初次见面的客户感受到需求分析师的“专业性”，增强信任感，提升沟通效率。
● 资料是判断客户需求的重要参考，也为需求分析师增加了交流时的话题、切入点。汇总的资料大体可以包括以下内容（不限于此）。
1）企业基本信息
● 企业发展愿景：了解企业的长远目标，帮助进行信息化的顶层设计。
● 主要领导发言：用以判明企业对管理信息化的看法、期待、支持力度等。
● 客户企业规章：理解企业的管理水平，能够接受的系统管理深度、难度等。
● 企业组织形式：组织结构、地域分布、部门的划分层级。
● 企业人员构成：员工人数、能力结构（高级、中级人才比例）。
2）企业业务情况
● 企业业务内容：包括企业的主营业务涉及的业务行业、领域、产品，辅营业务（财务、人资等）。这些内容可以帮助理解系统所需的功能。
● 企业业务数据：近三年的年产值、收益情况，用以判断管理信息化的效果，同时可以判断客户可以承受的开发费用。
● 有无业务问题：包括产值、成本、资金、收益、内控、质量、安全等诸方面的问题。
3）既存IT现状
IT现状与问题：既有系统覆盖的业务内容、存在的问题、其他硬件的环境等。
3．表达形式的统一
调研初期最为头疼的事就是针对一个双方都知道的问题，需求分析师与客户往往谈了很久都说不到一起，而经过一段时间的沟通后就会变得比较流畅了，造成这个现象的原因就是双方来自于不同的行业，有着各自的习惯，因此对同一个问题缺乏统一的定义，而相互熟悉之后，尽管用语还不明确但也知道对方指的是什么，这种现象造成了调研初期的沟通效率不高，而且进行信息系统的详细需求讨论时，用语的定义必须是精确的、不含糊的。所以，调研开始前要对所用专业表述进行统一，统一的内容包括两个方面：用语表达的统一，逻辑表达的统一。
1）用语表达的统一
从两个方面进行用语的确定，一是客户的业务专业用语，二是软件商的软件专业用语。
（1）业务专业用语（客户）。
用文字的形式，将系统涉及的各类客户专业用语进行统一定义。方法是从预先收集到的资料中，将频繁出现的专业用语、固定表达方式等抽提出来列成表，做好定义后交与客户进行确认。业务用语根据不同的业务领域不同，例如企业管理经常会用到的产值、利润、成本、成本管理、收支平衡、业务财务一体化等。
（2）软件专业用语（软件商）。
由于客户要引入信息系统，所以客户也必须要引入和掌握系统相关的基础用语。方法也是同样，预先将本系统可能用到的专业用语列表，进行定义。例如，企业管理系统常用到的需求、功能、流程、界面、流程分歧条件、管控规则等，软件专业用语也就是设计用语。
2）逻辑表达的统一
仅用语言还不足以保证双方的沟通顺畅，因为企业有很多复杂的业务逻辑是用语言无法描述清楚的，所以必须采用图形的形式进行表达和沟通，需要教会客户方相关人能够看懂与他们业务直接相关的，并且需要他们确认的业务架构图、原型界面图。预先准备好用于不同业务的标准用图，如
● 分解图（静态）：将组织结构、产品结构、客商分类等关系表达出来。
● 流程图（动态）：将客户的业务运行顺序、管控点布置等关系表达出来。
相对于用语表达的统一，逻辑表达的统一是一个更高层次的统一，因为即使是用语统一了，但在具体业务内容的描述上可能还是不一致的，只有在逻辑表达层面也统一了，才可以说是真正地对某个事物的理解是一致了（理解一致≠做法一致）。用图形表达业务逻辑的方式，是提升需求调研的效率、质量、价值等的最高效方法之一，当遇到的问题越复杂时，图形表达的沟通方式就越有效。
4．问卷调研
通常在大型或是复杂的软件项目进入现场调研前，会对客户的相关部门进行问卷调研，将需求分析师想要知道的、容易回答的问题提前发给客户，在进入调研前回收、研究。
1）设计形式
问卷可以采用两种方式，一种是文字类，另一种是图形类。
（1）文字类：适用于任何问题的询问。将问题列表，客户的回答方式有两种：文字描述或是选择项。
（2）图形类：适用于对逻辑关系的理解。例如，某个业务的操作过程（流程图）、某个对象的分解结构（分解图）。
2）问题选择
问卷要根据不同的问题、不同的岗位，设计不同的问卷题目，例如：
● 决策层：想要什么样的系统、达到什么目的、期望什么回报。
● 管理层：通过信息系统，希望解决什么实际存在的业务问题。
● 执行层：现在手工作业（或是既有系统）的问题，希望如何改进。
5．原型法调研
原型法是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户验证、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。它在投入大量的人力、物力之前，在限定的时间内，用最经济的方法开发出一个可实际操作的系统模型，它可以减少与用户的沟通时间，可以让双方直观地、形象化地进行评价、提意见。制作这个原型需要本书提供的设计方法，因此，掌握了原型的设计方法后，就可以使用这个方法进行快速调研。但是，这个方法是从“功能”的视角出发的，原型法只适用于调研和确认“点”的功能需求，所以用在相对比较简单的调研对象是高效率的，但是对于规模大、系统复杂的业务对象，仅用这个方法不能够解决对业务整体的理解和业务逻辑的获取，还需要采用“图、文、表”共举的方法。
6．项目启动会
通常软件项目的合同确定之后，在需求调研之前都会召开一次有相关各方参加的项目启动会，可能有的读者会认为就是双方相关人员相互介绍认识一下，走个形式，其实不然。对于软件商方面而言，项目启动会的作用是非常重要的，用“机不可失”来强调它的重要性也一点儿不为过，它是需求调研开始前的最后一个重要工作，可以说是进入调研前的最重要工作，这个会的重要性就在于：双方的领导，特别是客户的高层领导会参加，下一步调研相关的组织、管理、计划等主要事项一定要在这个会议上“当面落实、决定”，也就是说，软件商一侧要在会议前，将所有需要双方领导当面确定的事项全部准备好（可以是提纲，也可以包含尚未敲定的事项），例如：
● 建立联合调研组，双方的负责人、各个领域、部分的负责人、参与人的确定。
● 问题的解决流程，客户方面的业务问题最终决策人。
● 项目的推进计划（这个尤为重要，因为客户往往因为工作忙，不能保证参与时间）。
● 设立调研中间成果的汇报、评估会议。这些原则性的问题一定要当面确定，不然调研开始后出现纷争时再调停，就有可能因为良好的合作气氛已被破坏，而造成工作效率的降低。
7．调研路线图
将前述内容整理成调研的路线图，路线图包括：
● 流程：作为路线图的载体，给出开始、中间步骤、结束。
● 节点：路线图上的每个节点包含的内容、对应的活动和模板（问卷、图形）。这些资料的格式、名称、内容结构等都要与后续的调研、分析、设计的内容保持一致，以获得最大的工作效率比。
8．调研物品
作为最后一项，调研中要准备好以下一些物品，这些物品的作用很重要。
● 投影仪：准备好的资料要用投影仪展示。
● 白板／多色白板笔：临时发生的问题在白板上画张图会带来意想不到的效果。
需求分析师要牢记：与客户沟通和与软件企业内部人员沟通的意义不同，在调研初期与客户沟通的失败会严重地影响客户对需求分析师的信赖和信心，会造成客户与需求分析师之间的“不平等现象”（当然是客户在上），影响以后双方的合作。充分的事前准备不但可以提高调研工作的效率，更为重要的是可以提升需求分析师在客户心目中的地位和信赖程度。不打无准备之仗，准备周全的调研工作，可以展示出需求分析师的专业水平。
6.2.2 调研对象的区别
调研对象的不同获取的需要不同，想要获取什么需求就要知道找什么样的调研对象。
1．从企业外部看调研对象
从外部看企业，可以将调研的对象分为两大类，即：客户与用户，这两者对项目起着不同的作用，他们的关注点不一样，所以提出的需求也不同。
1）客户
客户，指的是管理信息系统的投资人、购买者，如企业决策者、企业信息化主管领导、信息中心负责人等。客户是站在企业的高端，从战略的层面去看待企业管理的信息化，他们的关注点在于导入信息系统的目的、目标、价值（效率、效益），如何提升企业的竞争力等。
2）用户
用户，指的是系统的直接利用者（操作），这个用户包括所有的系统使用者，不论是查看分析报表的企业高管、普通的凭证数据输入者，还是企业信息中心的维护员，他们都对自己所利用系统的功能有相应的需求。用户是站在功能使用的角度上看待企业管理的信息化，他们的关注点在于：信息化优化和改善了那些具体的业务流程、操作方法，信息系统包含哪些功能、功能的易用性如何、工作效率是否提升、还有哪些难点和痛点问题可以用信息化手段来解决等。
3）客户与用户的区别
两者的关注点不同，客户需求的层次要高、抽象，用户的需求比较具体、直观，客户的需求是要转换为用户需求才能落地实现的。
2．从企业内部看调研对象
一般企业组织可以划分为三个层次，即：决策层、管理层和执行层，各自的职责如下。
1）决策层
● 组织的实权机关，包括董事长、总经理、副总经理等。
● 他们提出的需求形式多为理念、目标、愿景、价值、期望等。
● 决策层的需求会影响到系统的顶层设计、范围规划、业务架构等内容。
2）管理层
● 决策层的下属机构，包括生产、计划、物资、销售等管理部门。其职责是落实决策层的战略目标，具体制定各个组织的目标、管理和协调等，他们只关注自己的分工内容。
● 管理层提出的需求形式多为业务表达，例如，优化采购流程、进行成本过程的精细化管理、建立业务与财务数据共享机制等。
● 管理层的需求会影响到对业务规划、业务架构、业务功能、管理深度等方面的判断。
3）执行层
● 直接受管理层的领导和协调，将所属组织部门的目标转换为具体行动和成果。
● 执行层的需求内容大多是对具体功能的描述，例如，合同管理模块、界面的字段、某个业务处理的计算规则等。
● 执行层的需求会影响到系统的业务架构、业务功能等详细设计内容。这三个层次由上到下具有组织之间的关联，同时各自又有独立目标和职责。
6.2.3 需求调研的顺序
调研的方法有很多，这里介绍几个在企业管理类系统调研时最为常规的调研方法。通常对客户进行调研时的路径为：首先是按照组织部门的划分调研，然后是按照工作岗位的划分调研，最后是按照业务自身结构调研，即：组织（部门）、岗位以及业务。
1．按照组织部门沿着企业的组织构成，以各个业务部门为单位逐一听取需求说明。
2．按照业务岗位按照不同的角色，制定一张调研表，从该角色的视角理解业务，这个方法多用于对业务和管理过程起着重要影响的角色。
（1）决策层：如董事长、总经理等主管企业的战略、经营方向。
（2）管理层：如各个业务部门的负责人（财务、生产、销售）、业务线主管（采购）等。
（3）执行层：如各个业务流程上的活动的担当者、执行人。
3．按照业务划分前两个维度都是从组织的视角进行调研的，第三个维度是从业务运行的视角进行的，此时部门、岗位信息仅作为参考属性，而将业务对象作为调研的主体，如成本管理主线、资金管理主线、材料采购主线等，以业务视角为主线的调研可能跨部门、跨岗位，它是搞清楚业务逻辑的主要手段。
6.2.4 需求真实性的识别
1．摆正与客户的关系
从结论上说，不要轻易地相信客户提的所有需求都是对的，按照客户做的就没有问题。因为当出现错误时还是要归结于需求分析师没有搞清楚客户的需求，因为客户不是信息化专家，最终需求分析师还是要为错误的结果负责。
2．判断真实的需求
如何解决上述问题，做到可以正确地判断是否是真实需求呢？
1）方法一：逻辑推演当需求分析师不清楚客户的业务但又感到有问题时，可以用逻辑推演来判断，通过逻辑推演可以判断出客户的需求是否是合理的、正确的，例如：
● 为什么需要做这个功能？缺少这个功能会如何？
● 这个功能与其上游工作的关系。
● 这个功能与其下游工作的关系。为什么通过业务的逻辑推演就可以搞清楚问题呢？因为很多的被调研者是客户某个业务流程上的某个业务功能的执行者，他可能有以下的局限性。
● 被调研者只知道某个业务点或某个局部的做法。
● 被调研者不知道为什么这样做（他的前任没有告诉他理由）。
● 被调研者说不清楚他所从事业务活动的输入与输出。
● 被调研者的上下级之间的看法不同，部门间的沟通不足；等。
2）方法二：
多角度观察需求分析师要记住“不要轻易相信你听到的”，因为需求分析师与客户在信息化知识方面是不对等的，客户并不知道他提的需求将来在系统中会带来什么后果，需求分析师也未必听懂了客户的真实需求，因此对客户提的“表面需求”要经过侧面的判断才能确定为“真实需求”。
为了解决这个问题，可以参考使用5W1H分析法帮助做好判断工作，其含义如下。
（1）对象（What）：什么事情。
（2）场所（Where）：什么地点。
（3）时间（When）：什么时候、顺序。
（4）人员（Who）：责任人。
（5）为什么（Why）：原因。
（6）方式（How）：如何。
在需求调研过程中使用5W1H方法，首先要理解的是What、How，而作为判断的重要依据的是Why，其他Where、When、Who是附属的信息，没有经验的需求分析师只会从正面进行调研，即询问“做什么”“怎么做”，但是最为重要的“为什么做（Why）”却往往不问，这样就失去了多角度观察需求的机会，也同时失去了识别需求的虚实的机会。
3．价值判断方法
对于复杂的、规模较大的需求，用简单的、操作层面的能够做评估的依据难以确定是否是真实的需求，此时可以利用咨询中使用的“目的、价值和功能”三要素来判断需求。三要素的定义如下。
①目标：首先，确认客户的需求目标是什么？
②价值：其次，确认该目标达成后，客户可以获得什么价值？
③功能：最后，确认软件商提供何种功能可支持该价值的实现？
这三者的关系是：“目标”是做什么，“价值”是对目标达成的回报，“功能”是对价值的实现。如果针对某个需求的判断符合下述条件，那么它可能就不是真实的需求。
（1）确定不了这个需求的目标是什么。
（2）虽然知道目标，但看不出目标达成后会给客户带来什么价值（回报）。
（3）提出的功能需求实现后，并不能给客户带来预期的价值；等。
6.2.5 需求背景的记录
访谈记录中，一定要记住：每个需求都要有对应的“背景”，这个背景就是导入该需求要解决什么现状的问题，如果没有对该需求背景的描述，在需求分析时就搞不清楚要做到什么程度，在设计阶段就会拿捏不准，出现了设计不足或是设计过渡都是不好的，有了背景说明，很容易找到对策，从而找到对应的功能。
例如：
● 成本管理需求：要记录下现在的成本管理现状是什么，问题是什么，可以改善的内容，提升的空间是什么。
● 销售管理需求：要记录下现在销售的现状，要改进什么内容，提升哪些效率，希望通过信息化的销售管理方式带来什么回报。在信息系统上线后进行客户满意度评估时，如果没有这些需求的背景信息，则无法评估，因为不知道原始状态的情况，就无法说明信息化带来了什么改变，产生了什么价值。
6.2.6 需求的记录形式
不论采用何种调研方法，最终记录的主要形式都是三种：图形、文字和表格。
1．记录的三种形式
采用“图形、文字、表格”三种形式记录，不但可以将客户现在企业的状况、问题、希望、需求等搞清楚，而且调研的结果还包含非常清晰的逻辑性，要记住：调研结果不能只有“功能”，还必须有“逻辑”。这个清晰的逻辑表达方式正是未来可以高质量、高效率地进行需求分析、业务设计的保证。
（1）图形：记录了客户业务现状的构成形态，包括业务流程、结构分解、逻辑关系等。
（2）文字：记录了与客户进行沟通时的内容，包括需求、期望、痛点等。
（3）表格：收集了客户实际使用的各类表单，如凭证、各类统计资料、分析报表。
记住：业务逻辑，是调研的重要成果之一！
说明书中不缺乏“功能一览”以及对功能需求的详细描述，但是缺少了一个关键的内容，就是对业务“逻辑”的记录，用组合原理来解释就是，大家重“要素”不重“逻辑”，缺少“逻辑”信息的最突出表现就是没有现状构成图或是业务架构图，缺少逻辑就无法支持后续的整体规划、业务架构以及精确地确定数据关系等，如此，即使是功能做得再好，由于系统是功能串联起来进行运行的，如果逻辑不清，则运行一定不顺。
2．三种记录方式的使用顺序
1）对客户业务不熟悉的情况
由于不熟悉，当然第一步先要听取客户的说明，那么就以访谈记录的方式开始，在记录了客户的需求后，经过梳理绘制成图，再向客户确认理解是否有出入。
2）对客户业务比较熟悉的情况
当对客户的业务比较熟悉时（如已经做过同类的产品），则可以预先准备相似的业务构成图，通过图形的展示说明，可以快速地与客户达成对业务要素、业务逻辑的统一认知，通过调整图形的构成，逐渐地拉近双方认识的一致性，同时做好访谈内容的记录，这个方法的工作效率最高。
客户看了图后，如果不对，他可以准确地指出哪里有错误，什么是正确的。如果正确，则需求分析师可以快速地理解业务要素、业务逻辑的内容。另外，调研初期，由于客户不熟悉软件调研的方法，往往不知道如何参与，如果借助业务构成图绘制的业务场景进行交流、调研，则客户会感到很亲切，非常容易参与进来，在参与的过程中客户也可以自然而然地掌握业务架构图的看图方法，一举两得。
3．需求记录的原则
需求工程，不是设计工程，在需求调研的记录中要切记下述原则。
● 访谈记录，一定要保持原始记录的内容、表达方式。
● 不可以在访谈记录、现状构成图等资料中加入需求分析师自己的观点。
则运行一定不顺。
6.3 记录方式1——现状构成（图）
6.3.1 定义与作用
1．定义
现状构成图，是采用架构模型将研究对象的业务构成以及业务运行情况表达出来的记录方式。作为分析、优化业务的依据，现状构成图可以同时表达出业务要素和业务逻辑。
观察研究对象的业务背景时，可以将其分成两个部分，一是静态的“非运行部分”，二是动态的“运行部分”。通常静态的非运行部分业务采用分解图、框架图等表达，动态的运行部分业务采用流程图。
1）静态的表达
即利用分解图、框架图等，绘制业务的结构状态，此图可掌握业务的“静态构成”，并从静态构成中获取“静态逻辑”。因为所有要素之间都存在着从属、关联的关系，用分解图等可以标识出它们之间的关系，如组织结构、工作分解、材料构成等。
2）动态的表达
即利用流程图，绘制业务的运行状态，此图可掌握业务的“动态构成”，并从动态构成获取“动态逻辑”。业务流程图给出了各个工作过程的开始、终止，以及中间活动的顺序，如报销流程、采购流程、支付流程等。
2．作用
现状构成图的方法与访谈记录采用的事前问卷方式有相似之处，这两种方式都是以“确认”为主的调研方式，而不是“询问”的方式，这样的方式效率高，可以较为快速地获得需求分析师想要的信息，而且还可以保证调研对象回答问题时不跑偏。现状构成图不仅是客户现状的记录，而且也是后续进行业务架构、优化、改进的重要参考物。没有此图，后续在设计时就不知道以什么为参考对象进行业务的优化了。
6.3.2 构成图1——静态构成
静态构成，表达了“有什么”。
1．要素的构成
这个方法适用的业务对象非常多，如业务、组织、物品等
● 业务类：销售活动、设计活动、采购活动、加工活动、财务活动、人资活动等。
● 组织类：销售部门、财务部门、生产部门等；董事长、经理、工程师、员工等。
● 物品类：设备、生产线、材料、运输工具、产品、计算机等。从这些静态的业务构成图中，可以清晰地了解企业有哪些业务，各类业务的结构、业务要素等信息，这就是静态的业务构成图带来的价值。
2．逻辑的构成
绘制上述要素的构成图时，对每个要素都注入了如下的信息。
（1）要素的位置。
（2）要素与周围其他要素之间的关联。
（3）要素之间的包含关系形成了系统、从属关系。这些信息就是“逻辑”，逻辑是难以用文字或是表格来记录的，最佳的方式就是用图形的方式记录，最为准确、快捷。常用来表达静态构成的架构模型有两种：框架图和分解图
6.3.3 构成图2——动态构成
动态构成，表达了“怎么做”。记录动态构成的方式有两种：第一种是采用记“流水账”的方式，第二种是采用“业务流程”的方式，两者在不同的场合各有各的用途。
1．动态构成——流水账方式
按照客户的叙述顺序将工作过程记录下来就形成了一个“流水账”，此时客户不可能按照规范的流程来叙述，因此将过程中的节点称为“步骤”。步骤可以是名词、名动词、动词等。这个方式的优点是快速，不打断客户的叙述思路，但是记录的结果需要进行梳理。
由于是记录流水账，所以只需要有一条线把各个步骤串联起来，并用箭头标明方向就可以了，不需要严格地按照流程图的标准绘制，因为它在后续的需求分析时还会发生变化。注：实体实体指的是该步骤对应的处理内容（数据），是后续设计界面时的依据，实体可以有以下几种形式。
（1）既存表单（表单上有格式、字段等信息）。
（2）与客户沟通的记录（需要输入的数据、界面形态）。
（3）上传资料（包括扫描文件、其他类型的数据、图形、声音等）。
2．动态构成——业务流程方式
1）要素的构成业务流程方式比较正规，按照正式的流程图标准绘制，流程图给出了构成流程的要素。流程架构图的特点是：所有的节点都是由“活动”要素构成的。
“活动”是指客户生产过程上的某个对应工作，是用动词来表达的。
2）逻辑的构成绘制上述要素的动态构成图时，对每个要素都注入了如下的信息。
● 要素之间的位置（顺序）。
● 要素与周围其他要素之间的关联（箭头）。
● 要素的分歧、流转等。这些“顺序、方向、流转……”就是逻辑，了解动态的业务逻辑必须要借助“流程图”来获取。
6.3.4 构成图3——管控构成
有了前述的业务构成图之后，以业务构成图为载体可以绘制出客户的管理现状图（参考分离原理，这样分开记录有利于后续的分析与设计）。
管理现状图中需要的管理要素有三类：业务载体、管控点、管理规则。
（1）业务载体：流程图、要素、分歧点等，如签约、设计。
（2）管控点：管理规则的加载位置，如在“签约”上有审批流程、利润控制两项。
（3）管理规则：管控点加载的管理规则，如在“采购”上有“材价不能超标”的规则。
6.4 记录方式2——访谈记录（文）
6.4.1 定义与作用
1．定义
访谈记录，是利用问卷或是面对面的交流，并将交流的结果用文字的方式记录下来。
1）事前问卷
为了提升访谈记录的效率，可以提前编制一个对客户起着诱导、启发作用的问卷，让受访者预先理解、准备。
2）当面访谈
这个部分的内容最多，工作量也是最大的，包括客户对信息化的明确需求、不明确的问题、对未来的期望等，所有用图、表格等不易表达的内容都可以用，例如：
● 决策层面的需求：理念、目的、商机等。
● 管理层面的需求：优化、效率、效益等。
● 执行层面的需求：功能、措施、规则等。
● 各层共有的问题，如企业运营中的难度、痛点等。
2．作用
访谈记录获取的信息量是最多的，所有无法用图形、表格等形式表达的需求都可以用语言的方式表达，如目标、期望、痛点、难点等内容。大多数的业务功能都是从访谈中直接或是间地获得的。访谈记录表是后续编制需求调研资料汇总的基础。
6.4.2 访谈记录表
访谈记录的基本内容
（1）需求提出人（Who）：提出者的部门、岗位、职责等。需求提出人是属于什么部门、岗位等。
（2）需求内容（Where/What）：在什么地方、做什么事。描述在什么地方（部门、岗位、流程），做的什么事情（有什么需求）。
（3）背景说明（Why）：为什么要做这件事，背景、痛点、希望获得什么效果等。这个背景对确定采用什么功能以及判断是否取得了相应的效果非常重要。
（4）对策（How）：采用什么方式（功能）应对需求。考虑到的可能对策，此时可以给出功能名称，也可以仅给出对策方案，具体的概念细节在分析时再确定。
（5）优先级（When）：说明什么时间或是按什么顺序完成这个需求。
6.4.3 需求与要求
在调研过程中，要注意获取的信息中的用语表达方式，特别要搞清楚“需求”和“要求”的区别，理解两者的差异很重要，这会对后续的设计范围、设计深度产生重要的影响。
1．需求
客户对某个功能是需要的，提出者只是想要，但对要的内容具体也说不清楚（定性、定量），需要需求分析师帮他搞清楚想要的是什么，在调研期间这类信息都属于“需求”，需求最终是否能够成为“功能”要到需求分析完成后才能确定。
2．要求
客户对某个功能是清楚的，给出了条件清晰的意愿，客户甚至可能给出了定性、定量的条件，这就是客户的要求了。一般来说，客户的要求是一定要实现的，尽管通过设计后呈现给客户的功能形态有所变化也无妨。
3．区别
对于“需求”，需求分析师要根据掌握的情况进行分析、有无必要、用什么功能来实现等，调研中获取的需求大多属于此类。而对于“要求”，则需求分析师的自主发挥的余地不大，通常发生在对信息化比较有经验的企业客户中。
6.5 记录方式3——既存表单（表）
客户已有的各类业务处理表单也是重要的需求来源，虽然这些客户日常使用的资料非常易于梳理，但它们往往是需求分析师做的最粗、最不到位的工作，致使后期开发过程中花费大量的无意义成本去分析和研究这些原始的表单。
6.5.1 定义与作用
1．定义
既存表单，是客户在导入信息系统前正式使用的，并且需要转换为用系统处理的各类资料，包括各类凭证单据、统计报表、分析资料等。它们的存在形式可以是电子表单、纸质表单。
2．作用
这是后续设计业务功能的重要参考物。这些资料提供了如下的信息（不限于此）。
● 业务功能、系统界面的参考。
● 数据定义、数据逻辑、数据规则（计算公式）。
● 业务流程上节点对应的实体等。
如果直接将这样的资料交给后续的设计师，设计师最终还是要通过需求分析师向客户询问才能得到解决，这样就造成了时间的浪费，而且最终需求分析师也没有省掉这些工作。
6.5.2 表单的梳理与记录
在客户现场对既存表单进行梳理的工作是非常重要的。表单梳理的参考方法包括：表单关系、表单分解和表单记录（需求4件套）三个步骤。
1．表单关系
一个大型的软件项目，可能会收集到十几张、几十张甚至更多的既存表单，理解它们之间的业务逻辑关系、数据逻辑关系是非常重要的，如果不在现场直接询问原编制者可能很难搞清楚它们之间的关系，搞清楚关系会对后续的分析与设计提供非常大的帮助。
（1）业务逻辑关系——流程图
第一步就是将它们展开，利用业务构成图（流程），将各类表单与流程的节点（活动）进行关联，建立表单与流程之间的业务逻辑关系，这是个粗粒度的关系，让后续的设计师可以知道这些表单获取的前后顺序，此时还看不出具体的数据之间的关系。
（2）表单关系——勾稽图
建立表单之间勾稽关系，这个图表达的是细粒度关系，它给出了表单之间的关键数据的传递路径，掌握了表单数据分级之间的顺序，对后续分析和详细设计起着非常重要的指导作用，从图中可以看出数据表之间的相互引用关系。
注：表单间的关联线既存表单之间的关联需要数据表的“主键”的概念
2．表单分解
由于在导入系统之前通过手工做成的表单中包括原始输入的表单，还有中间汇总用的表单，前者是产生数据的，后者是为了最终需要的资料而对数据进行中间加工产生的表单，这类表单作用不同，处理的形式也不同，需要在现场进行识别。
（1）一级表单：输入功能+显示功能。填写的是第一次录入的原始数据，如合同数据、报销数据、进货数据等，这类表单在未来的设计中，需要用两个功能来对应：输入功能（界面）、打印功能（报表）。只要表中存在着需要手工输入的数据（需要界面），那么它就属于一级表单。
（2）二级表单：有显示功能。包括二级和二级以上表单，这些表单记载的数据不是原始数据，而是对已经记录在案数据的二次加工、三次加工，如成本数据、利润数据、其他统计分析类的数据。这类表单由于不需要从界面上进行干预，所以在设计中只需要可以显示的表单功能即可。
（3）其他表单：无显示功能。还有一些表单根本就不要设计对应的功能，因为在手工计算的时候，它们的作用仅仅是为了完成最终的统计报表而作的中间计算结果，改用信息系统后，中间计算结果在系统的后台直接完成，就不需要用表单功能显示了，收集这类表单只是为了参考计算逻辑。
3．表单记录
1）基本信息将表单的名称、内容、部门等基本信息汇总成既存表单一览
2）详细定义有了业务逻辑、数据表间的关系之后，还必须要对每个表单上的字段进行定义，这是最细粒度的记录。表单记录，采用需求规格书（简称需求4件套）的形式进行记录，它要对表单上每个字段逐一地进行精准描述，包括字段的定义、管理规则、计算公式等。
6.5.3 梳理与记录的流程
对既存表单的梳理和记录顺序，根据需求分析师对客户业务的熟悉情况、经验积累、产品积累的情况不同而不同。下面给出梳理和记录的流程作为参考。
6.6 需求调研汇总
6.6.1 需求记录的原则
1．记录原则1——原始状态
需求记录一定要保持原有的状态，需求记录不是软件设计，因此不能在需求调研中加入设计内容。下面列举几个原则性的要求。
● 原始性：表达要采用客户语言进行记录，以避免由于需求分析师理解不清搞错了含义，更不要采用系统语言进行描述。
● 真实性：此时不要加入需求分析师自己的意见，要保证需求资料的真实性，否则需求调研的资料就不具有追溯性了。时间一长就记不清楚需求是谁提出来的。
● 意见：需求分析师个人的意见可以提，但是要单独标注，以示区别。
2．记录原则2——顺序
● 提供者信息：部门、岗位、业务，都是分析判断的依据。
● 需求的顺序：给出优先等级，必须符合业务的发生顺序。
6.6.2 需求记录的形式
对需求调研的所有内容进行归集、汇总，形成需求调研资料汇总，主要包括三大类：现状构成（图）、访谈记录（文）和既存表单（表）。
1．现状构成图
1）静态构成
● 组织结构：部署构成、岗位构成。
● 业务划分：销售、设计、加工、采购、物流。
● 物品构成：设备、固定资产等。
2）动态构成
● 工作流程：合同签订流程、采购流程、报销流程、物流流程。
● 审批流程：各类不同业务处理结果的审批步骤。可以使用线形流程图或是泳道式流程图。
3）管理现状管理的现状构成图（管理架构图）。
2．访谈记录
1）访谈问卷对调研的内容事先列出清单交与客户，收集初步客户的现状情况，以及客户的需求。
2）访谈记录对客户访谈的内容梳理、归集，形成访谈记录表。
3．既存表单
1）收集表单
● 收集各个部门、各个业务领域的单据、报表、账本等原始资料。
● 资料可以是电子版，也可以是扫描版。
2）表单分析分析的成果包括（这类内容属于现场调研的工作，不是后期的分析工作）：
● 流程图与实体。
● 表单的勾稽关系图。
● 表单的分级图等。
小结
在需求调研的方法中，获取需求有很多的方法，因人而异，因条件而异，甚至是因环境而异，但是有两个部分的工作基本上是可以一致的，即：事前准备内容与事后记录形式，这两个工作做到位了，则调研工作的效果最佳。
1．事前准备内容
无论什么样的软件项目，调研前的准备越充分调研的效果就会越好，调研前准备的目的就在于：全部的调研过程一定要按照预先制定的内容规划、节点计划推进，也就是说，整个调研过程要在需求分析师的“掌控”之下推进，而准备不足时在调研现场就容易出现“失控”的局面。
调研水平的高低判断可以用调研过程中是采用“确认”的方式多还是“问询”的方式多来判断，事前准备做得好，则在调研过程中使用“确认”的方法比例就高，反之，准备不足时就以“问询”为主，“确认／问询”的百分比越大，说明调研的效率高且质量好。“确认”多的调研就是主动掌握型的调研方式。要想做到在调研过程中掌握主动权，则需求分析师就必须在进入调研前投入大量的精力做准备工作。
2．事后记录形式
调研的手法可以有万千种，但是记录的内容和形式一定要统一，统一需求记录格式的重要性非常大，主要体现在下面两点。
1）调研遗漏少
需求记录采用了多维度、结构化的模板，由于模板记录的格式对业务要素、要素之间的业务逻辑具有要求，且不同的模板之间具有相互印证的作用，这样就可以大大地减少需求调研的遗漏，而且获得的调研内容比较全面、记述严谨，调研的质量也高。
2）分析效率高
在获得了全面、严谨且结构化的高质量需求后，在后期对这些调研成果进行分析的效率也高，得出的需求分析成果的质量也高，特别是那些通常比较让需求分析师头疼的复杂、抽象的需求（目标需求、业务需求、负面需求等），不但不是一个难题，而是成为一个可以找到软件开发亮点的宝库。这种记录形式也有利于在发现问题时，容易对原始需求继续追溯检查。
3）建立需求知识库
这种结构化的调研、记录方式非常有利于软件企业构建需求体系的知识库，每个项目的需求都有三种记录形式，如果再与后续的需求分析建立起链接关系，则会对其他项目的初期调研、分析带来非常大的帮助。
建立工程化的需求调研流程，是提升调研效率和质量的保证
“有效调研成果”指的是调研的成果是真实的、可以作为明确的设计输入、并最终能够成为要实现的功能。例如，调研成果采用了图、文、表的表达形式，这些表达方式之间可以相互确认、补完，不但给出了明确的功能需求（要素），而且给出了清晰的业务逻辑，用这种表达方式表达的成果具有很高的可信度和质量保证。