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)问题选择
问卷要根据不同的问题、不同的岗位,设计不同的问卷题目,例如:
● 决策层:想要什么样的系统、达到什么目的、期望什么回报。
● 管理层:通过信息系统,希望解决什么实际存在的业务问题。
● 执行层:现在手工作业(或是既有系统)的问题,希望如何改进。
3)设计原则
首先要注意,问卷不是解决调研问题的决定手段,它只是初步沟通、了解的工具,因此:
● 要广而浅,不能指望用问卷的方式解决主要问题。
● 不可将问卷形式设计得过于复杂,否则在理解上容易产生歧义。
● 问题说明不要太长,表达不要太抽象,理解不能过于费力(减低参与者的热情)。
● 问题要尽量做到量化,尽量采用选择题的方式,问题要贴近被问者的专业。
4)问卷的作用
● 给予对方思考的时间,让客户可以根据问卷内容提前梳理思路。
● 可以让客户事前了解“需求调研”的工作内容等,做好心理准备。
● 问卷法节省时间、经费和人力,这是为什么经常采用问卷法的原因。
5.原型法调研
原型法是指在获取一组基本的需求定义后,利用高级软件工具可视化的开发环境,快速地建立一个目标系统的最初版本,并把它交给用户验证、补充和修改,再进行新的版本开发。反复进行这个过程,直到得出系统的“精确解”,即用户满意为止。
它在投入大量的人力、物力之前,在限定的时间内,用最经济的方法开发出一个可实际操作的系统模型,它可以减少与用户的沟通时间,可以让双方直观地、形象化地进行评价、提意见。制作这个原型需要本书提供的设计方法,因此,掌握了原型的设计方法后,就可以使用这个方法进行快速调研,原型的设计方法详见第13章和第17章的内容。
但是,这个方法是从“功能”的视角出发的,原型法只适用于调研和确认“点”的功能需求,所以用在相对比较简单的调研对象是高效率的,但是对于规模大、系统复杂的业务对象,仅用这个方法不能够解决对业务整体的理解和业务逻辑的获取,还需要采用本章推荐的“图、文、表”共举的方法。
6.项目启动会
通常软件项目的合同确定之后,在需求调研之前都会召开一次有相关各方参加的项目启动会,可能有的读者会认为就是双方相关人员相互介绍认识一下,走个形式,其实不然。对于软件商方面而言,项目启动会的作用是非常重要的,用“机不可失”来强调它的重要性也一点儿不为过,它是需求调研开始前的最后一个重要工作,可以说是进入调研前的最重要工作,这个会的重要性就在于:双方的领导,特别是客户的高层领导会参加,下一步调研相关的组织、管理、计划等主要事项一定要在这个会议上“当面落实、决定”,也就是说,软件商一侧要在会议前,将所有需要双方领导当面确定的事项全部准备好(可以是提纲,也可以包含尚未敲定的事项),例如:
● 建立联合调研组,双方的负责人、各个领域、部分的负责人、参与人的确定。
● 问题的解决流程,客户方面的业务问题最终决策人。
● 项目的推进计划(这个尤为重要,因为客户往往因为工作忙,不能保证参与时间)。
● 设立调研中间成果的汇报、评估会议。
这些原则性的问题一定要当面确定,不然调研开始后出现纷争时再调停,就有可能因为良好的合作气氛已被破坏,而造成工作效率的降低。
7.调研路线图
将前述内容整理成调研的路线图,路线图包括:
● 流程:作为路线图的载体,给出开始、中间步骤、结束。
● 节点:路线图上的每个节点包含的内容、对应的活动和模板(问卷、图形)。
这些资料的格式、名称、内容结构等都要与后续的调研、分析、设计的内容保持一致,以获得最大的工作效率比。
8.调研物品
作为最后一项,调研中要准备好以下一些物品,这些物品的作用很重要。
● 投影仪:准备好的资料要用投影仪展示。
● 白板/多色白板笔:临时发生的问题在白板上画张图会带来意想不到的效果。
分享
调研神器:白板+白板笔
在培训时学员经常会提出一个令人苦恼的问题:在需求调研的现场,客户参与的人越多场面就越难控制,常见的现象:对同一问题的意见不同、内容跑题、讨论的内容不在同一个层面、店大欺客等,常常是讨论了半天结果不收敛(没有结论),遇到这种场面该如何应对呢?
老师与大家分享了经验:调研现场最为重要的道具之一就是白板和白板笔(两种颜色以上),当出现上述情况时,你要勇敢地走到白板前拿起白板笔,针对讨论当中最具有权威(或是声音最大者)的客户提问并绘制排比图(一维),诱导他说出正在讨论内容的业务步骤,将这个业务步骤画成一条主线,然后以这条主线为背景,对主线上的每个节点逐一地询问:“发生的问题”“期望的对策”,并将他们的回答标注在排比图上,此时在场的所有人就会渐渐地安静下来并被吸引到白板的排比图上,进而参加进来,发表自己的意见,这样不但可以快速地控制局面和进程、调整现场气氛,而且还可以同时获得带有逻辑的现状图。
在事后的培训满意度问卷中,这个做法给大家带来了期待的效果,不但提升了需求调研的效率,在增加了客户对调研者信任度的同时也逐渐地得到了客户的尊重,取得了一石二鸟的效果。“排比图”的画法参见第4章。
需求分析师要牢记:与客户沟通和与软件企业内部人员沟通的意义不同,在调研初期与客户沟通的失败会严重地影响客户对需求分析师的信赖和信心,会造成客户与需求分析师之间的“不平等现象”(当然是客户在上),影响以后双方的合作。充分的事前准备不但可以提高调研工作的效率,更为重要的是可以提升需求分析师在客户心目中的地位和信赖程度。不打无准备之仗,准备周全的调研工作,可以展示出需求分析师的专业水平。
6.2.2 调研对象的区别
调研对象的不同获取的需要不同,想要获取什么需求就要知道找什么样的调研对象。
1.从企业外部看调研对象
从外部看企业,可以将调研的对象分为两大类,即:客户与用户,这两者对项目起着不同的作用,他们的关注点不一样,所以提出的需求也不同。
1)客户
客户,指的是管理信息系统的投资人、购买者,如企业决策者、企业信息化主管领导、信息中心负责人等。客户是站在企业的高端,从战略的层面去看待企业管理的信息化,他们的关注点在于导入信息系统的目的、目标、价值(效率、效益),如何提升企业的竞争力等。
2)用户
用户,指的是系统的直接利用者(操作),这个用户包括所有的系统使用者,不论是查看分析报表的企业高管、普通的凭证数据输入者,还是企业信息中心的维护员,他们都对自己所利用系统的功能有相应的需求。
用户是站在功能使用的角度上看待企业管理的信息化,他们的关注点在于:信息化优化和改善了那些具体的业务流程、操作方法,信息系统包含哪些功能、功能的易用性如何、工作效率是否提升、还有哪些难点和痛点问题可以用信息化手段来解决等。
3)客户与用户的区别
两者的关注点不同,客户需求的层次要高、抽象,用户的需求比较具体、直观,客户的需求是要转换为用户需求才能落地实现的。
当然,客户与用户关注的内容并非是没有重合的、完全分开的,这里只是强调他们的差异,而这个差异点非常重要,往往经验不足的需求分析师会将客户提的有些抽象的需求过滤掉,而只关注用户提的比较直观的需求,这样做就是常说的“捡了芝麻丢了西瓜”,在现实中往往价值最高的需求来自于客户。
注:客户与用户两者在使用时的区别
在本书中,如果说明某个功能的使用者时,会使用“用户”,而泛指软件商服务的对象时一般用“客户”,此时“客户”中也包含“用户”的含义,使用“客户”还是“用户”对后续的说明都不会产生歧义。
2.从企业内部看调研对象
一般企业组织可以划分为三个层次,即:决策层、管理层和执行层,各自的职责如下。
1)决策层
● 组织的实权机关,包括董事长、总经理、副总经理等。
● 他们提出的需求形式多为理念、目标、愿景、价值、期望等。
● 决策层的需求会影响到系统的顶层设计、范围规划、业务架构等内容。
2)管理层
● 决策层的下属机构,包括生产、计划、物资、销售等管理部门。其职责是落实决策层的战略目标,具体制定各个组织的目标、管理和协调等,他们只关注自己的分工内容。
● 管理层提出的需求形式多为业务表达,例如,优化采购流程、进行成本过程的精细化管理、建立业务与财务数据共享机制等。
● 管理层的需求会影响到对业务规划、业务架构、业务功能、管理深度等方面的判断。
3)执行层
● 直接受管理层的领导和协调,将所属组织部门的目标转换为具体行动和成果。
● 执行层的需求内容大多是对具体功能的描述,例如,合同管理模块、界面的字段、某个业务处理的计算规则等。
● 执行层的需求会影响到系统的业务架构、业务功能等详细设计内容。
这三个层次由上到下具有组织之间的关联,同时各自又有独立目标和职责。
6.2.3 需求调研的顺序
调研的方法有很多,这里介绍几个在企业管理类系统调研时最为常规的调研方法。
通常对客户进行调研时的路径为:首先是按照组织部门的划分调研,然后是按照工作岗位的划分调研,最后是按照业务自身结构调研,即:组织(部门)、岗位以及业务。三者的关系如图6-3所示。
图6-3 组织、岗位及业务关系图
1.按照组织部门
沿着企业的组织构成,以各个业务部门为单位逐一听取需求说明。
2.按照业务岗位
按照不同的角色,制定一张调研表,从该角色的视角理解业务,这个方法多用于对业务和管理过程起着重要影响的角色。
(1)决策层:如董事长、总经理等主管企业的战略、经营方向。
(2)管理层:如各个业务部门的负责人(财务、生产、销售)、业务线主管(采购)等。
(3)执行层:如各个业务流程上的活动的担当者、执行人。
3.按照业务划分
前两个维度都是从组织的视角进行调研的,第三个维度是从业务运行的视角进行的,此时部门、岗位信息仅作为参考属性,而将业务对象作为调研的主体,如成本管理主线、资金管理主线、材料采购主线等,以业务视角为主线的调研可能跨部门、跨岗位,它是搞清楚业务逻辑的主要手段。
三种调研方式缺一不可,三者的关系是:首先按照组织维度进行调研,这个方式对客户比较容易,他们可以各说各的,不用去考虑与其他部门的业务是否可以无缝衔接。最终需求分析师必须要用业务为主线的方法将前两种调研的成果进行串联,向客户确认,如果没有问题,则调研的结果是可信的。
6.2.4 需求真实性的识别
1.摆正与客户的关系
做过调研的读者一定会遇到过这样的纠结,感觉客户提的需求不对,但因为他是客户难以判断是否要按照他的意见去做。这个问题的关键就在于:在谈到客户的业务时需求分析师就认为客户比自己更加熟知业务工作,因此软件商就应该按照客户的意见去做。
客户在他所从事业务的方面会比需求分析师更加专业,但是客户在管理如何实现信息化方面未必是专家,例如,成本管理与成本管理信息化的区别。
(1)成本管理:指的是在“人-人”环境下进行的成本管理方式(包括知识和手段),讨论这个方面的内容时可能客户更加清楚。
(2)成本管理信息化:指的是在“人-机-人”环境下用信息化手段进行的成本管理方式,讨论这个问题时需求分析师应该比客户更加有经验。
通常第一次进行信息系统构建的客户,是基于“人-人”环境的工作背景来提需求的,而需求分析师要用基于未来“人-机-人”环境下的工作方式来判断是否需要这个需求。当然在判断的时候还受到其他因素的影响,例如,需求分析师与客户哪个经验多、客户是否是部门的领导、需求分析师是否做过同类产品等。
从结论上说,即:不要轻易地相信客户提的所有需求都是对的,按照客户做的就没有问题。因为当出现错误时还是要归结于需求分析师没有搞清楚客户的需求,因为客户不是信息化专家,最终需求分析师还是要为错误的结果负责。
2.判断真实的需求
如何解决上述问题,做到可以正确地判断是否是真实需求呢?
1)方法一:逻辑推演
当需求分析师不清楚客户的业务但又感到有问题时,可以用逻辑推演来判断,通过逻辑推演可以判断出客户的需求是否是合理的、正确的,例如:
● 为什么需要做这个功能?缺少这个功能会如何?
● 这个功能与其上游工作的关系。
● 这个功能与其下游工作的关系。
为什么通过业务的逻辑推演就可以搞清楚问题呢?因为很多的被调研者是客户某个业务流程上的某个业务功能的执行者,他可能有以下的局限性。
● 被调研者只知道某个业务点或某个局部的做法。
● 被调研者不知道为什么这样做(他的前任没有告诉他理由)。
● 被调研者说不清楚他所从事业务活动的输入与输出。
● 被调研者的上下级之间的看法不同,部门间的沟通不足;等。
2)方法二:多角度观察
需求分析师要记住“不要轻易相信你听到的”,因为需求分析师与客户在信息化知识方面是不对等的,客户并不知道他提的需求将来在系统中会带来什么后果,需求分析师也未必听懂了客户的真实需求,因此对客户提的“表面需求”要经过侧面的判断才能确定为“真实需求”。为了解决这个问题,可以参考使用如图6-4所示的5W1H分析法帮助做好判断工作,其含义如下。
(1)对象(What):什么事情。
(2)场所(Where):什么地点。
(3)时间(When):什么时候、顺序。
(4)人员(Who):责任人。
(5)为什么(Why):原因。
(6)方式(How):如何。
图6-4 5W1H
在需求调研过程中使用5W1H方法,首先要理解的是What、How,而作为判断的重要依据的是Why,其他Where、When、Who是附属的信息,没有经验的需求分析师只会从正面进行调研,即询问“做什么”“怎么做”,但是最为重要的“为什么做(Why)”却往往不问,这样就失去了多角度观察需求的机会,也同时失去了识别需求的虚实的机会。
3.价值判断方法
对于复杂的、规模较大的需求,用简单的、操作层面的能够做评估的依据难以确定是否是真实的需求,此时可以利用咨询中使用的“目的、价值和功能”三要素来判断需求。这三要素的关系如图6-5所示,三要素的定义如下。
①目标:首先,确认客户的需求目标是什么?
②价值:其次,确认该目标达成后,客户可以获得什么价值?
③功能:最后,确认软件商提供何种功能可支持该价值的实现?
图6-5 咨询三要素关系图
这三者的关系是:“目标”是做什么,“价值”是对目标达成的回报,“功能”是对价值的实现。如果针对某个需求的判断符合下述条件,那么它可能就不是真实的需求。
(1)确定不了这个需求的目标是什么。
(2)虽然知道目标,但看不出目标达成后会给客户带来什么价值(回报)。
(3)提出的功能需求实现后,并不能给客户带来预期的价值;等。
6.2.5 需求背景的记录
访谈记录中,一定要记住:每个需求都要有对应的“背景”,这个背景就是导入该需求要解决什么现状的问题,如果没有对该需求背景的描述,在需求分析时就搞不清楚要做到什么程度,在设计阶段就会拿捏不准,出现了设计不足或是设计过渡都是不好的,有了背景说明,很容易找到对策,从而找到对应的功能。例如:
● 成本管理需求:要记录下现在的成本管理现状是什么,问题是什么,可以改善的内容,提升的空间是什么。
● 销售管理需求:要记录下现在销售的现状,要改进什么内容,提升哪些效率,希望通过信息化的销售管理方式带来什么回报。
在信息系统上线后进行客户满意度评估时,如果没有这些需求的背景信息,则无法评估,因为不知道原始状态的情况,就无法说明信息化带来了什么改变,产生了什么价值。对于软件商来说也无法向新客户说明自己的解决方案有哪些效果案例。
6.2.6 需求的记录形式
不论采用何种调研方法,最终记录的主要形式都是三种:图形、文字和表格。
1.记录的三种形式
采用“图形、文字、表格”三种形式记录,不但可以将客户现在企业的状况、问题、希望、需求等搞清楚,而且调研的结果还包含非常清晰的逻辑性,要记住:调研结果不能只有“功能”,还必须有“逻辑”。这个清晰的逻辑表达方式正是未来可以高质量、高效率地进行需求分析、业务设计的保证,见图6-6。
图6-6 需求记录的三种形式
(1)图形:记录了客户业务现状的构成形态,包括业务流程、结构分解、逻辑关系等。
(2)文字:记录了与客户进行沟通时的内容,包括需求、期望、痛点等。
(3)表格:收集了客户实际使用的各类表单,如凭证、各类统计资料、分析报表。
三种记录形式的详细说明参见后续各节。
注:访谈记录表格与既存表单的区别
访谈记录的主要形式是“文字”,它可以用文章体记录,也可以记录在表格上,后者的目的主要是为了梳理、维护的方便性,“表格”并不是访谈记录内容的构成部分。而既存表单不同,表单的“表格”本身就是信息的一部分。
分享
记住:业务逻辑,是调研的重要成果之一!
培训会上,学员们经常说:我编写需求规格说明书花费了很多时间,内容也非常充实,但是最后开发的结果还是出现了大量的返工,受到了客户和开发的抱怨,问题出在了哪里?!
在投影仪上将部分学员的需求规格说明书展示出来,大家一起做了对比,发现了这些资料的共同点:说明书中不缺乏“功能一览”以及对功能需求的详细描述,但是缺少了一个关键的内容,就是对业务“逻辑”的记录,用组合原理来解释就是,大家重“要素”不重“逻辑”,缺少“逻辑”信息的最突出表现就是没有现状构成图或是业务架构图,缺少逻辑就无法支持后续的整体规划、业务架构以及精确地确定数据关系等,如此,即使是功能做得再好,由于系统是功能串联起来进行运行的,如果逻辑不清,则运行一定不顺。
学员们进行了反思,做了多年的需求调研和分析工作,重点都放在了“对功能的收集和确认”上,缺乏“对逻辑的收集和确认”的意识。出现这个现象与通常调研时基本上不用图形收集需求的做法是吻合的。
2.三种记录方式的使用顺序
根据调研对象的内容、客户对信息化知识了解的多少以及需求分析师的能力等不同,记录方式的使用顺序会有的不同,可以参考以下的情况做判断。
1)对客户业务不熟悉的情况
由于不熟悉,当然第一步先要听取客户的说明,那么就以访谈记录的方式开始,在记录了客户的需求后,经过梳理绘制成图,再向客户确认理解是否有出入。
2)对客户业务比较熟悉的情况
当对客户的业务比较熟悉时(如已经做过同类的产品),则可以预先准备相似的业务构成图,通过图形的展示说明,可以快速地与客户达成对业务要素、业务逻辑的统一认知,通过调整图形的构成,逐渐地拉近双方认识的一致性,同时做好访谈内容的记录,这个方法的工作效率最高。这种方式需要需求分析师预先做好图形的准备工作。
从作者的经历来看,即使是不熟悉的业务对象,经过预先进行调查,先绘制出一套业务构成图,不论其内容正确与否,在现场调研时它都会起到很大的作用,例如:
客户看了图后,如果不对,他可以准确地指出哪里有错误,什么是正确的。
如果正确,则需求分析师可以快速地理解业务要素、业务逻辑的内容。
另外,调研初期,由于客户不熟悉软件调研的方法,往往不知道如何参与,如果借助业务构成图绘制的业务场景进行交流、调研,则客户会感到很亲切,非常容易参与进来,在参与的过程中客户也可以自然而然地掌握业务架构图的看图方法,一举两得。
3.需求记录的原则
需求工程,不是设计工程,在需求调研的记录中要切记下述原则。
● 访谈记录,一定要保持原始记录的内容、表达方式。
● 不可以在访谈记录、现状构成图等资料中加入需求分析师自己的观点。
如果在调研记录中加入了需求分析师自己的态度、想法等,那么这个调研资料就不能表达客户的原始需求了,基于这个调研资料所做的分析如果出现了错误也无法进行追溯,特别是当需求分析师的知识、经验都不足时其带来的后果会更加严重。
注:调研过程的语音和录像资料不能算作需求记录,它们只能用来还原现场情况。