用户需求分析方法

‘壹’ 用户需求分析方法

客户的需求是我们销售行为的关键，但是客户不会每次都会毫无保留的告诉你，所以我们要通过行业分析，客户需求分析，了解客户需求，解决问题。


一、分析竞争对手

想要了解客户需求，就要先了解市场发展及我们的竞争对手。中国自古就有一句古话：知己知彼百战百胜，销售更应牢记这句话，因为只有你足够了解你的竞争对手，才能做出应对。了解竞争对手，不仅要了解竞争对手的价格、特征，还要了解有哪些长处、不足、销量及销售形式等，我们只有足够透彻的了解竞争对手，才能在市场掌握主动权，同时也能从另一方面了解到市场需求。


二、客户特点及习惯

一方面要了解客户的兴趣爱好，消费习惯等，另一方面要从销售本身出发，了解客户的内心，一般客户都比较重视产品质量和售后服务，我们只需要把握好这两点往往销售会比较容易成功。

三、客户的真实需求

要想了解客户的真实需求需要寻找客户需求、仔细发现、等待客户需求呈现、确认客户需求、最后成交。了解客户需求是成交的必要条件。


四、满足客户

要学会维护客户自尊，沟通过程中多用：有什么我可以帮您的吗？您的事我一直放在心上，会尽快给您处理的；您好有眼光等等。可以让对方感觉到受到了尊重和重视，同时客户也会感觉有良好的消费体验。

细心聆听客户心声，沟通过程中多用：您的意思是......对吗？原来是这样；我知道您的感受或心情等。要认真听客户讲的话，体会对方感受，并及时给予回应，说出自己的想法。

‘贰’ 300字思考:目标用户需求分析方法

目标用户需求分析法主要是了解用户的需求，根据用户的需求进行生产。并且提供服务。

‘叁’ 如何进行用户需求分析

1.概念
需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.
关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".
百事通
而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.
需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:
需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.
从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.
任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.
2.需求分析的任务
开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.
目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.
对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?
然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.
近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.
相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.
事实上,需求文档在开发过程中一直起指导作用.
3.需求分析过程
可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:
图4-1 需求工程域的层次分解示意图
需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面:
确定产品所期望的用户类别.
获取每个用户类的需求.
了解实际用户任务和目标以及这些任务所支持的业务需求.
分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.
将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件.
了解相关质量属性的重要性.
商讨实施优先级的划分.
将所收集的用户需求编写成文档和模型.
评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.
需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括:
定义需求基线(迅速制定需求文档的主体).
评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.
以一种可控制的方式将需求变更融入到项目中.
使当前的项目计划与需求一致.
估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上.
让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.
在整个项目过程中跟踪需求状态及其变更情况.
以上几点说明是我总结了成功实施项目后系统分析人员的经验,同时也根据国内外的其他系统实施的相关成功经验,进行了总结.
4.需求的类型
下面这些定义是需求工程领域中常见术语的定义.
软件需求包括三个不同的层次:业务需求、用户需求和功能需求(也包括非功能需求).
1.业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明.
2.用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(use case)文档或方案脚本说明中予以说明.
3.功能需求(functional requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求.
在软件需求规格说明书 (SRS)中说明的功能需求充分描述了软件系统所应具有的外部行为.软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用.对一个大型系统来说,软件功能需求也许只是系统需求的一个子集,因为另外一些可能属于子系统(或软件部件).
作为功能需求的补充,软件需求规格说明还应包括非功能需求,它描述了系统展现给用户的行为和执行的操作等.它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性.所谓约束是指对开发人员在软件产品设计和构造上的限制.质量属性是通过多种角度对产品的特点进行描述,从而反映产品功能.多角度描述产品对用户和开发人员都极为重要.
下面以一个字处理程序为例来说明需求的不同种类.业务需求可能是:"用户能有效地纠正文档中的拼写错误",该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器.而对应的用户需求可能是"找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词".同时,该拼写检查器还有许多功能需求,如找到并高亮度提示错词的操作;显示提供替换词的对话框以及实现整个文档范围的替换.
从以上定义可以发现,需求并未包括设计细节、实现细节、项目计划信息或测试信息.需求与这些没有关系,它关注的是充分说明你究竟想开发什么.项目也有其它方面的需求,如开发环境需求或发布产品及移植到支撑环境的需求.尽管这些需求对项目成功也至关重要,但它们并非本书所要讨论的.
5.需求分析的原则
不重视需求过程的项目队伍将自食其果.需求工程中的缺陷将给项目成功带来极大风险,这里的"成功"是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望.下面将讨论一些需求风险.
不适当的需求过程所引起的一些风险:
1. 无足够用户参与
客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫,开发人员可能也不重视用户的参与.究其原因:一是因为开发人员感觉与用户合作不如编写代码有意思;二是因为开发人员觉得已经明白用户的需求了.在某些情况下,与实际使用产品的用户直接接触很困难,而客户也不太明白自己的真正需求.但还是应让具有代表性的用户在项目早期直接参与到开发队伍中,并一同经历整个开发过程.
系统人员在实践过程中,也有些感觉,在实施一家公司的项目时,若无足够的用户参与,系统人员获得的需求是片面的,不完整的,这样系统在需求之初就埋下风险.
2. 用户需求的不断增加
在开发中若不断地补充需求,项目就越变越庞大以致超过其计划及预算范围.计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致,这使得问题更难解决.实际上,问题根源在于用户需求的改变和开发者对新需求所作的修改.
要想把需求变更范围控制到最小,必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明,并将此说明作为评价需求变更和新特性的参照框架.说明中包括了对每种变更进行变更影响因素分析的变更控制过程,有助于所有风险承担者明白业务决策的合理性,即为何进行某些变更,相应消耗的时间、资源或特性上的折中.
产品开发中不断延续的变更会使其整体结构日渐紊乱,补丁代码也使得整个程序难以理解和维护.插入补丁代码使模块违背强内聚、松耦合的设计原则,特别是如果项目配置管理工作不完善的话,收回变更和删除特性会带来问题.如果你尽早地区别这些可能带来变更的特性,你就能开发一个更为健壮的结构,并能更好地适应它.这样设计阶段需求变更不会直接导致补丁代码,同时也有利于减少因变更导致质量的下降.
3. 模棱两可的需求
模棱两可是需求规格说明中最为可怕的问题.它的一层含义是指诸多读者对需求说明产生了不同的理解;另一层含义是指单个读者能用不止一个方式来解释某个需求说明.
模棱两可的需求会使不同的风险承担者产生不同的期望,它会使开发人员为错误问题而浪费时间,并且使测试者与开发者所期望的不一致.一位系统测试人员曾告诉我,她所在的测试组经常对需求理解有误,以致不得不重写许多测试用例并重做许多测试.
处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍.仅仅简单浏览一下需求文档是不能解决模棱两可问题的.如果不同的评审者从不同的角度对需求说明给予解释,但每个评审人员都真正了解需求文档,这样二义性就不会直到项目后期才被发现,那时再发现的话会使得更正代价很大.
4. 不必要的特性
"画蛇添足"是指开发人员力图增加一些"用户欣赏"但需求规格说明中并未涉及的新功能.经常发生的情况是用户并不认为这些功能性很有用,以致在其上耗费的努力"白搭"了.开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路,具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡,开发人员应努力使功能简单易用,而不要未经客户同意,擅自脱离客户要求,自作主张.
同样,客户有时也可能要求一些看上去很"酷",但缺乏实用价值的功能,而实现这些功能只能徒耗时间和成本.为了将"画蛇添足"的危害尽量减小,应确信:你明白为什么要包括这些功能,以及这些功能的"来龙去脉",这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能.
5. 过于精简的规格说明
有时,客户并不明白需求分析有如此重要,于是只作一份简略之至的规格说明,仅涉及了产品概念上的内容,然后让开发人员在项目进展中去完善,结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明.这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况.但在大多数情况下,这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作),也会给客户带来烦恼(他们无法得到他们所设想的产品).
6. 忽略了用户分类
大多数产品是由不同的人使用其不同的特性,使用频繁程度也有所差异,使用者受教育程度和经验水平也不尽相同.如果你不能在项目早期就针对所有这些主要用户进行分类的话,必然导致有的用户对产品感到失望.例如,菜单驱动操作对高级用户太低效了,但含义不清的命令和快捷键又会使不熟练的用户感到困难.
7. 不准确的计划
据统计,导致需求过程中软件成本估计极不准确的原因主要有以下五点:频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析.
对不准确的要求所提问题的正确响应是"等我真正明白你的需求时,我就会来告诉你".基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右.要作出估计时,最好还是给出一个范围.未经准备的估计通常是作为一种猜测给出的,听者却认为是一种承诺.因此我们要尽力给出可达到的目标并坚持完成它.
6.需求分析人员和用户的合作关系
优秀的软件产品是建立在优秀的需求基础之上的.而高质量的需求来源于客户与开发人员之间有效的交流与合作.通常,开发人员与客户或客户代理人,如市场人员间的关系反而会成为一种对立关系.双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦,在这种情况下,不会给双方带来一点益处.
只有当双方参与者都明白要成功自己需要什么,同时也应知道要成功合作方需要什么时,才能建立起一种合作关系.由于项目压力与日渐增,所有风险承担者有着一个共同的目标这一点容易被遗忘.其实大家都想开发出一个既能实现商业价值,又能满足用户需要,还能使开发者感到满足的优秀软件产品.
软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求.每一项权利都对应着软件开发人员、分析人员的义务.而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务.如果愿意,可以将其作为开发人员的权利书.
客户有如下权利:
1:要求分析人员使用符合客户语言习惯的表达
需求讨论应集中于业务需要和任务,故要使用业务术语,你应将其教给分析人员,而你 不一定要懂得计算机的行业术语.
2:要求分析人员了解客户的业务及目标
通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要.这将有助于开发人员设计出真正满足你的需要并达到你期望的优秀软件.为帮助开发人员和分析人员,可以考虑邀请他们观察你或你的同事是怎样工作的.如果新开发系统是用来替代已有的系统,那么开发人员应使用一下目前的系统,这将有利于他们明白目前系统是怎样工作的,其工作流程的情况,以及可供改进之处.
3:要求分析人员编写软件需求规格说明
分析人员要把从你和其他客户那里获得的所有信息进行整理,以区分开业务需求及规范、功能需求、质量目标、解决方法和其它信息.通过这些分析就能得到一份软件需求规格说明.而这份软件需求规格说明便在开发人员和客户之间针对要开发的产品内容达成了协议.软件需求规格说明书可以用一种你认为易于翻阅和理解的方式组织编写.要评审编写出的规格说明以确保它们准确而完整地表达了你的需求.一份高质量的软件需求规格说明能有助于开发人员开发出真正需要的产品.
4:要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性软件需求规格说明的补充.因为如工作流程图那样的图表能很清楚地描述出系统行为的某些方面.所以需求说明中的各种图表有着极高的价值.虽然它们不太难于理解,但是你很可能对此并不熟悉.因此可以要求分析人员解释说明每张图表的作用或其它的需求开发工作结果和符号的意义,及怎样检查图表有无错误及不一致等.
5:要求开发人员尊重你的意见
如果用户与开发人员之间不能相互理解,那关于需求的讨论将会有障碍,共同合作能使大家"兼听则明".参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间.同样,客户也应对开发人员为项目成功这一共同目标所作出的努力表示尊重与感激.
6:要求开发人员对需求及产品实施提供建议,拿出主意
通常,客户所说的"需求"已是一种实际可能的实施解决方案,分析人员将尽力从这些解决方法中了解真正的业务及其需求,同时还应找出已有系统不适合当前业务之处,以确保产品不会无效或低效.在彻底弄清业务领域内的事情后,分析人员有时就能提出相当好的改进方法.有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性.
7:描述产品易使用的特性
你可以要求分析人员在实现功能需求的同时还要注重软件的易用性.因为这些易用特性或质量属性能使你更准确、高效地完成任务.例如,客户有时要求产品要"用户友好"或"健壮"或"高效率",但这对于开发人员来说,太主观了并无实用价值.正确的应是:分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性.
8:调整需求,允许重用已有的软件组件
需求通常要有一定的灵活性.分析人员可能发现已有的某个软件组件与你描述的需求很相符.在这种情况下,分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发中重用一些已有的软件.如果有可重用的机会出现,同时你又能调整你的需求说明,那就能降低成本和节省时间,而不必严格按原有的需求说明开发.所以说,如果想在产品中使用一些已有的商业常用组件,而它们并不完全适合你所需的特性,这时一定程度上的需求灵活性就显得极为重要了.
9:获得满足客户功能和质量要求的系统
每个人都希望项目获得成功.但这不仅要求你要清晰地告知开发人员关于系统"做什么"所需的所有信息,而且还要求开发人员能通过交流了解清楚取舍与限制.一定要明确说明你的假设和潜在的期望.否则,开发人员开发出的产品很可能无法让你满意.
客户有下列义务:
1:给分析人员讲解你的业务
分析人员要依靠你给他们讲解的业务概念及术语.但你不能指望分析人员会成为该领域的专家,而只能让他们真正明白你的问题和目标.不要期望分析人员能把握你们业务的细微与潜在之处,他们很可能并不知道那些对于你和你的同事来说理所当然的"常识".
2:抽出时间清楚地说明并完善需求
客户很忙,经常在最忙的时候还得参与需求开发.但无论如何,你有义务抽出时间参与"头脑风暴"会议的讨论,接受采访或其它获取需求的活动.有时分析人员可能先以为明白了你的观点,而过后发现还需要你的讲解.这时,请耐心一些对待需求和需求的精化工作过程中的反复,因为它是人们交流中的很自然的现象,何况这对软件产品的成功极为重要.
3:准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的.由于处理细节问题不但烦人而且又耗时,故很容易留下模糊不清的需求.但是,在开发过程中,必须得解决这种模糊性和不准确性.而你恰是为解决这些问题作出决定的最佳人选.不然的话,你就只好靠开发人员去正确猜测了.在需求规格说明中暂时加上待定(to be determined, TBD也可采用汉语拼音略写"DQD:待确定")的标志是个不错的办法.用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方.不过,有时也可能因为某个特殊需求难以解决或没有人愿意处理它而注上TBD标志.尽量将每项需求的内容都阐述清楚,以便分析人员能准确的将其写进软件需求规格说明中.如果你一时不能准确表述,那就得允许获取必要的准确信息这样一个过程.通常使用所谓的原型技术.通过开发的原型,你可以同开发人员一起反复修改,不断完善需求定义.
4:及时地作出决定
正如一位建筑师为你修建房屋,分析人员将要求你做出一些选择和决定.这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等.有权做出决定的客户必须积极地对待这一切,尽快做处理、做决定.因为开发人员通常只有等你做出了决定才能行动,而这种等待会延误项目的进展.
5:尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本价格,开发人员最适合预算这些成本(尽管许多开发人员并不擅长评估预测).你所希望的某些产品特性可能在技术上行不通,或者实现它要付出极为高昂的代价.而某些需求试图在操作环境中要求不可能达到的性能或试图得到一些根本得不到的数据,开发人员会对此作出负面的评价意见,你应该尊重他们的意见.有时,你可以重新给出一个在技术上可行、实现上便宜的需求,例如,要求某个行为在"瞬间"发生是不可行的,但换种更具体的时间需求说法("在50ms以内",但若没有准确的技术分析不能轻易下结论),这就可以实现了.
6: 划分需求优先级别
大多数项目没有足够的时间或资源来实现功能性的每个细节.决定哪些特性是必要的,哪些是重要的,哪些是好的,是需求开发的主要部分.只能由你来负责设定需求优先级,因为开发者并不可能按你的观点决定需求优先级.开发者将为你确定优先级提供有关每个需求的花费和风险的信息.当你设定优先级时,你帮助开发者确保在适当的时间内用最小的开支取得最好的效果.在时间和资源限制下,关于所需特性能否完成或完成多少应该尊重开发人员的意见.尽管没有人愿意看到自己所希望的需求在项目中未被实现,但毕竟是要面对这种现实的.业务决策有时不得不依据优先级来缩小项目范围或延长工期,或增加资源,或在质量上寻找折衷.
7:评审需求文档和原型
正如我们将在第1 4章讨论的,无论是正式的还是非正式的方式,对需求文档进行评审都会对软件质量提高有所帮助.让客户参与评审才能真正鉴别需求文档是否的确完整、正确说明了期望的必要特性.评审也给客户代表提供一个机会,给需求分析人员带来反馈信息以改进他们的工作.如果你认为编写的需求文档不够准确,就有义务尽早告诉分析人员并为改进提供建议.通过阅读需求规格说明,很难想象实际的软件是什么样子的.更好的方法是先为产品开发一个原型.这样你就能提供更有价值的反馈信息给开发人员,帮助他们更好地理解你的需求.必须认识到:原型并非是一个实际产品,但开发人员能将其转变、扩充成功能齐全的系统.
8:需求出现变更要马上联系
不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响.变更是不可避免的,但在开发周期中变更越在晚期出现,其影响越大.变更不仅会导致代价极高的返工,而且工期也会被迫延误,特别是在大体结构已完成后又需要增加新特性时.所以一旦你发现需要变更需求时,请一定立即通知分析人员.
9:应遵照开发组织处理需求变更的过程
为了将变更带来的负面影响减少到最低限度,所有的参与者必须遵照项目的变更控制过程.这要求不放弃所有提出的变更,对每项要求的变更进行分析、综合考虑,最后作出合适的决策以确定将某些变更引入项目中.
10:尊重开发人员采用的需求工程过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性.分析人员采用的方法有其合理性.也许你认为需求过程不太划算,但请相信花在需求开发上的时间是"很有价值"的.如果你理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术,那么整个过程将会更为顺利.尽管去询问分析人员为什么他们要收集某些信息,或参与与需求有关的活动.
系统分析人员在开发过程中可能会遇到以下问题,一些很忙的客户可能不愿意积极参与需求过程,而缺少客户参与将很可能导致不理想的产品.故一定要确保需求开发中的主要参与者都了解并接受他们的义务.如果遇到分歧,通过协商以达成对各自义务的相互理解,这样能减少今后的摩擦.
7.需求文档
需求开发的最终成果是:客户和开发小组对将要开发的产品达成一致协议.协议综合了业务需求、用户需求和软件功能需求.就像我们早先所看到的,项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求.你必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档,包括质量属性和外部接口需求.只有以结构化和可读性方式编写这些文档,并由项目的风险承担者评审通过后,各方面人员才能确信他们所赞同的需求是可靠的.
你可以使用以下三种方法编写软件需求规格说明:
用好的结构化和自然语言编写文本型文档.
建立图形化模型,这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系.
编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求.
由于形式化规格说明具有很强的严密性和精确度,因此,所使用的形式化语言只有极少数软件开发人员才熟悉,更不用说客户了.虽然结构化的自然语言具有许多缺点,但在大多数软件工程中,它仍是编写需求文档最现实的方法.包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受.图形化分析模型通过提供另一种需求视图,增强了软件需求规格说明.

‘肆’ 项目需求分析的分析方法

需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.

‘伍’ 怎么编写用户业务需求分析

需求分析
格式
1 引言
1.1 编写目的
【说明】目标：对用户的需求进行收集、整理与分析，弄清楚系统究竟要 “干什么”及“由谁干”，并用合乎规范的文字及图表予以描述。不需要说明“怎么干”，因为那是设计阶段的事情。有关文字与图表应尽量让用户便于理解。
预期读者：用户方的相关业务人员、双方的开发人员和系统维护人员。
作用：实现开发方与用户方的双向沟通，是把业务需求计算机化的关键步骤。
为下一阶段的概要设计工作提供依据。当用户的需求发生变更时，应添写补充说 明；如变动过大可形成新版本。
软件需求说明（Software Requirements Specification）的主要作用为：
 为用户方与开发方建立共同协议奠定基础。
 提高开发效率、强化进度控制。
 为项目的的评测与验收提供依据。
 便于移植。
 作为系统不断提高的基础。
1.2 编写背景
1.2.1 系统名称及版本号
【说明】形如“网银三期***系统V3.0.0”。其中，版本号的格式为“XX.XX.XX”，X为阿拉伯数字，左“0”可省略。

1.2.2 使用者
【说明】适应对象和范围。主要指预期读者，也供有关领导审阅。

1.2.3 与其它系统的关系
【说明】在用户现有的及预期的整个应用系统中，给本系统准确定位。用示意图及相应的文字予以说明。

2 用户的基本情况
2.1 系统建设背景
【说明】项目背景与依据、现有基础、项目规模、预期目标等。可繁可简，格式自定。

2.2 组织机构与职能
【说明】用层次示意图及相应文字表示(如果需要开发的系统与部门没有直接依赖关系此节可省略,本章随后的小节数将顺次减1)，

加注：组织机构的层次数、数目、各个机构的职能简述。

2.3 用户特点
【说明】所在行业特征、操作人员与系统维护人员的数量、学历与水平、数据量大小、使用频度等。
2.4 用户业务分析
【说明】在本部分，希望系统分析人员能够对用户业务现状进行分析、对用户对本系统的未来发展方向作出一定的预测等。以便设计人员对业务及其发展有所了解，增强系统设计的前瞻性。
2.5 计算机应用现状
【说明】可繁可简，格式自定。
3 业务需求
3.1 项目概述
【说明】
第一、 指明项目的开发意图、应用目标（总目标、分期目标）、作用范围、预期效益等。
第二、 指明在输入信息转变为输出信息的过程中，为了满足用户的业务需求，应用软件必须完成的基本功能(采用自然语言叙述)。但此时不要求对基本功能进行分解。
第三、 如果本系统与其他系统相关联，则应确定本系统的基本功能边界（可采用图示+文字说明的形式，用蓝色标示出本系统的功能，用绿色标示出相关系统的功能）。
3.2 约束条件
3.2.1 费用约束
【说明】 预计投资金额概算、其中软硬件费用的比例、资金分期到位计划。

3.2.2 进度约束
【说明】预计完成日期、分步实施期限。

3.2.3 其它约束
【说明】场地面积限制、通信设施基础、其它干扰因素。
注意：任何计算机系统都不是包罗万象的；用户自身的能力也是有限的。轻诺必寡信。故应特别指出：由于哪些条件的约束，本系统不能满足哪些业务需求与系统需求。
本章主要介绍项目的总体业务功能,要求站在客户的角度把握系统需求.
3.3 性能需求
【说明】依据ISO9000标准及我们的理解，下面列出了软件的6组性能，共涵盖21个子特性。这些性能/子特性的相对重要性并不是等同的。编写时，可以基于具体项目的实际需求，对下述标题或内容进行取舍/侧重。事实上不可能做到面面俱到，往往要作出某些折中。
本节说明系统在性能方面的预期目标，不要求提供实现上述目标的具体实施方案。

3.3.1 功能性
【说明】指与软件实现的各项功能及其指定性质有关的一组属性。这些功能都是满足规定需求和潜在需求所必需的。它包括5个子特性：
适用性：与指定业务所需各项功能的实现及其适合程度有关的一些软件属性。
准确性：与保证正确（或符合要求的）结果（或效果）有关的一些软件属性。
互操作性：与软件同一些指定系统交互作用能力有关的一些软件属性。
复合性：使软件遵守相关的标准、约定/法律或类似规定有关的一些软件属性。
保密安全性：与针对蓄意（或无意）而非法存取程序和数据的预防能力有关的一些软件属性。这里主要指的是保护软件的要素，旨在防止各种非法访问、修改、破坏、泄密及感染计算机病毒等。
3.3.2 可靠性
【说明】指在规定的条件和期限内，与软件保持其性能水平有关的一组软件属性。
成熟性：与软件故障引起的失误频率有关的一些软件属性。
容错性：在软件故障发生或其规定界面被破坏的情况下，与软件仍能保持规定性 能水平的能力有关的一些软件属性。
可恢复性：在失效的情况下、在限定的期限和强度范围内，与软件重建性能水平 并恢复直接受影响的数据的能力有关的一些软件属性。
3.3.3 易使用性
【说明】指与规定用户（或潜在用户）使用软件所需的努力程度、对这种使用所做的评估有关的一组软件属性。它包括3个子特性：
易理解性：与用户为理解其逻辑概念及适用范围需做的努力有关的一些软件属性。
易学习性：与用户学习其应用（例如操作控制、输入、输出）需做的努力有关的一些软件属性。
易操作性：与用户操作及运行控制需做的努力有关的一些软件属性。

3.3.4 高效性
【说明】指在特定的运行环境中，描写软件性能水平与所用的资源量之间关系的一组软件属性。它包括两个子特性：
时间特性：在完成软件功能时，与响应时间、处理时间、吞吐率有关的一些软件属性。
资源特性：在完成软件功能时，与所用资源量及占用时间有关的一些软件属性。

3.3.5 可维护性
【说明】与对软件进行指定的修改所需的工作量有关的一组软件属性。它包括4个子特性：
易分析性：与诊断故障、确定失败原因、在需要修改的部位进行标识等所做努力有关的一些软件属性。
易修改性：与实施修改、排除故障、环境改变所做努力有关的一些软件属性。
稳定性：与修改的意外影响带来的风险有关的一些软件属性。
易测试性：与对经过修改的软件进行检验/确认做努力有关的一些软件属性。
3.3.6 可移植性
【说明】指软件从一个环境转移的另一个环境时，与其适应能力有关的一组软件属性。它包括4个子特性：
适应性：除已有手段外，无须采用其它措施或手段，软件便应能适应指定的环境。与这种能力有关的一些软件属性称为适应性。
易安装性：在指定环境内，与安装软件所需努力有关的一些软件属性。
一致性：软件从一个环境转移的另一个环境时，应符合一定的标准和约定。与这种符合程度有关的一些软件属性，称为一致性。
易替换性：有时会出现这种需求：在某个其它软件的运行环境下，要用本软件来置换那个软件。与这种可能性及所需努力有关的一些软件属性。

4 用户需求
【说明】本章下面介绍的是一般规模软件系统的书写格式。在书写过程中可能要以业务名称划分小节(例如:5.1 代收电话费)。每个业务小节包含两个部分：第一部分是对此业务中角色和功能的定义；第二部分是此业务的图形分析方法。
在本章开始未分节的部分，应当绘制一个总体结构图，依据这个总体结构图进行一个总体描述，使得阅读者对下面分节描述的各个功能形成一个整体印象。这个总体结构图不一定是指在ROSE工具中绘制的用例总图， 而是根据需要可以选择包括“用例总图”、“适当级别的数据流图”、“IDFF图”、“数据流程图”或其他专业图形分析图示等。
每个小节中的第二部分采用rational公司的rose2000作为工具绘制用例（use case）图和顺序（sequence）图。在这里采用rose工具是作为绘图分析工具使用，对需求的描述和分析并不代表我们的设计采用UML标准和面向对象的设计，具体分析人员应当根据实际的用户需求描述绘制顺序图，而并不着重考虑对象的分析限制。
需求变更的处理原则：获得批准的需求变更，需要在《需求分析》中有所体现。增加的需求，需直接从本章尾部顺序添加，相应的小节编号也需要依次增加。例如：本章小节为5.1—5.5，增加的需求小节编号则为5.6。删除的需求，不需要将相应需求直接从《需求分析》中删除，而只需在相应需求小节上注明删除，并标出《需求变更单》编号。修改的需求，可在相应的需求小节直接修改。所有对《需求分析》内容的修改必须在修改历史中留有记录。
4.1 业务名称1
4.1.1 角色/功能定义
【说明】根据会议纪要、小组讨论，确定系统中的角色（角色可以为外部系统或系统用户），和功能，并给出相应的定义或解释。

4.1.2 图形分析
【说明】本节主要描述相应业务的用例图和顺序图的内容
统一建模语言（UML）是一个通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。它记录了对必须构造的系统的决定和理解，可用于对系统的理解、设计、浏览、配置、维护和信息控制。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模方法。
在本需求模板中我们选取的是UML视图来辅助进行图形需求分析，选用Rational公司的ROSE工具完成。在需求分析过程需要完成结构分类中的用例分析，绘制用例图；对用例的动态行为进行交互分析，描述执行系统功能的各个角色之间相互传递消息的顺序关系，绘制顺序图。
在这里请作者将制作的用例图和顺序图拷贝到本文档中。
基本成分：用例（use case）、用例视图（use case view）、角色（role、actor）、顺序图（sequence diagram）、协作图（collaboration diagram）。
模板和命名：为更好地使用ROSE图形分析工具，我们设定一个基本的分析模板，文件名为lansoftmdl.mdl。该文档涉及项目开发的需求、概设和详设3个阶段，在需求阶段主要完成模板中用例视图（use case view）规定完成的部分。在项目中使用该模板后生成的mdl文件纳入文档的配置管理，具体命名参照SEMP体系的命名规定。修改历史记入文档开始部分的“mdl文档修改历史表”中。

【ROSE使用要求】
1、 要求使用ROSE工具时必须完成模板和使用要求中规定完成的内容，在完成基本内容的基础上，可以根据需要增加部分内容。
2、 在公司没有购买确定版本的ROSE以前，使用的ROSE版本应在项目开始前在项目组规定好，并由配置管理员负责配置。
3、 在用例视图（use case view）中建立一个名称为main的主用例图（use case diagram），具体内容应当包括所有用例图的全部内容，具体应用时还可以根据情况建立多个用例图（use case diagram）。
4、 在用例视图中请采用中文对所有的角色（actor\role）进行命名。其中角色必须在双击该对象图后，详细填写该角色的描述（documentation）和该角色代表的角色数量（detail-multiplic）。
5、 在用例视图中请采用中文对所有的用例（use case）进行命名。命名中在一般的中文概括前应增加代表本节编号的部分，如“1.用户认证”，顺序编号。其中用例必须在双击该对象图后，详细填写该用例的描述（documentation）。
6、 在每个用例下必须组织建立相应的顺序图（sequence diagram），对于一个用例可以包含多个顺序图（sequence diagram），各个顺序图（sequence diagram）的命名需在一般的中文概括前增加代表本节编号的部分，如“1.1用户认证”，顺序编号，其中第一个1代表所属的用例，第二个1代表顺序图（sequence diagram）的编号。产生顺序图的数量根据说明需求的具体要求设定。其中顺序图中的各个对象消息（object message）必须在双击该对象图后，详细填写该对象消息（object message）的描述（documentation）。
4.1.3 数据存储需求
【说明】根据会议纪要、小组讨论，对于在需求调研中有关的数据实体对象或数据实体信息，应当根据需要提出可能数据类型和数据长度以及单位量纲的记录或建议。

5 运行环境
【说明】本章只提出运行环境的逻辑结构，物理结构将在《概要设计说明书》中给出。
容许提出几种可选方案。

5.1 硬件平台
【说明】指出本应用软件适用的主机/服务器与终端/工作站的技术指标、基本配置、接口特点、特殊约定等。
应尽可能地说明上述设备在各级用户机构预计的分布状态。
5.2 网络平台
【说明】选型标准、网络类型、基本部件、接口情况、对综合布线的要求、限制条件等。应画出网络（广域网、局域网）的拓扑结构图，说明后者对前者的接入方式。

5.3 软件平台
【说明】操作系统的名称、生产厂家、版本号等。
数据库的名称、生产厂家、版本号等。
数据库设计工具的名称、生产厂家、版本号等。
网络通信协议的名称、生产厂家、版本号等。
前端开发工具的名称、生产厂家、版本号等。
测试开发工具的名称、生产厂家、版本号等。
现场运行时需要的工具软件的名称、生产厂家、版本号等。
配置管理工具软件的名称、生产厂家、版本号等。
6 附录
【说明】列出基础素材中的文件、报表、单据等的样张，再附上必要的注释。
如果条件成熟，可以把数据字典（data dictionary）作为附件列于后。
6.1 电子文档编写方式与使用工具
【说明】编写要求、工具名、版本号、操作系统平台。使用多种工具时，应分别说明。形如：
Microsoft Word 97 for Windows 95/98
Power Designer 6.0 for Windows 95/98
Rational Rose 98 for Wintel
Visio或Power Point 97 for Windows 95/98

6.2 定义说明与符号
【说明】包括对专用术语及缩略语的解释、所用到的图（如use case、sequence图）之图符的表示与解释等。

6.3 参考资料
【说明】格式：作者，[版本号，]资料来源，日期 [，起止页号] 。其中，《质量保证计划》是必选的参考资料。

6.4 有关表格清单
【说明】列出用户提供的素材，加上我们积累的有关文件，作为系统分析的基础。在这里除系统内部没有用户参与的需求分析工作外，必须包括一个以上的用户访谈纪要、用户确认签名文件以及用户访谈计划等文件的列表。在列表中的文件应当作为附件与需求文档共同纳入配置管理

‘陆’ 网站用户需求分析的方法是什么意思

网站需求分析分为两部分：

• 市场对网站产品的需求分析(可以得出，网站能发展的空间有多大)，简称市场分析。

• 用户需求的分析(做用户喜欢的网站，让用户记住的网站，具有一定黏粘性，满足用户需求性的网站)，简称网站开发分析。

网站开发的需求分析报告 一个网站项目的确立是建立在各种各样的需求上面的，这种需求往往来自于客户的实际需求或者是出于公司自身发展的需要，其中客户的实际需求也就是说这种交易性质的需求占了绝大部分。

‘柒’ 用户需求分析怎么进行分类

说说纯理论化的用户需求分析流程吧。
一、产品定位是什么：这点是重中之重，产品不知道是干什么的，解决什么问题的，目标是什么的，那这个产品一定悲催了。
二、目标用户是谁：这点也很重要，要定位产品都面向哪些用户，我觉得很少有产品能说自己的产品适合所有用户的，总归会有一个定位的，而且要将目标用户进行分类，在每类抽取出用户角色卡片进行分析（其实这步现在很多产品都不做的，包括我自己做的产品）。
三、目标竞品是谁：特别是对于已经是红海的市场来说，看清楚目前竞品都有哪些功能，为什么做这些功能而不做那些，市场占有情况如何等，并划出产品的SWOT图，这点其实个人认为是最重要的，即使不进行目标用户分析，也要做关于竞品的分析工作。
四、情景分析：开始对用户使用产品的几个重要的场景和流程进行分析啦，这个分析清楚后产品的需求列表就可以形成了，并根据前期的竞品分析的结果将产品的需求进行优先级划分
五、需求文档撰写：最后是形成需求文档，包括了需求的介绍、用例分析、交互设计、数据字典等等部分。

作者：晓瑞
链接：https://www.hu.com/question/19713012/answer/12732801
来源：知乎
着作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

‘捌’ 需求分析方法主要包括哪些

结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业务需求阶段的周期相对容易控制；通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。

面向对象的分析方法的最大好处是在需求阶段，就能够非常精确地描述一个系统，采用程序语言的方式和最终用户交流（最终用户必须要熟悉这种语言），能够在项目一开始就发现很多问题，避免在开发的过程中出现需求的反复，而且在系统设计和开发阶段不需要最终用户参与。在实施上，一般可以采用场景、业务功能等方式来描述，比较适合于业务流程环节多的系统，或者软件产品的开发。但是，我们也要看到，在现实中，绝大多数的应用系统都很难在需求阶段就可以被精确地抽象化定义，所以这种方法的缺点和困难也是显而易见的：首先，用户要非常清楚地知道最终的业务系统应该是什么样，或者采用一种抽象的方式能够确定最终的应用系统；其次，因为最终用户不需要参与设计和开发阶段的工作，所以双方确定业务需求的过程也会比较长；同时，因为是精确描述，因此描述系统的语言是非常逻辑化的，一般通过某种方式可以使机器识别业务需求，采用这种方式写的业务需求是非常格式化的，一方面描述一个系统需要的信息非常多，可能使需求说明的篇幅非常长，不便于理解和阅读；另外由于通过抽象的方式来推演最终系统的运行方式，对业务人员的要求非常高。

‘玖’ 需求分析常用方法都有哪些，请举例说明

问卷调查法，是指设计方就用户需求中的一些个性化的、需要进一步明确的需求或问题，通过采用向用户问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。 这种方法适合于设计方和建设方、使用方都清楚项目需求的情况。因为建设方和使用方都清楚项目的需求，需要双方进一步沟通的需求或问题就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。显然对于乐百氏集团这样规模庞大的公司，简单的问卷调查是不能够满足准确获得需求的需要的。会议讨论法，是指设计方和用户相关人员召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法。这种方法适合于设计方不清楚用户的详细业务需求，但使用方清楚项目需求的情况。因为使用方清楚项目的需求，他们能准确地表达出他们的需求，而设计方有专业的需求，而我们有专业的软件开发经验，经过回忆讨论交流之后，能够对用户的需求进行准确描述和把握。这个方法对于准确的获得乐百氏公司的需求是一种不错的选择。在本案例中系统的设计人员也是这么做的，他们通过和乐百氏项目组经理的讨论，很快了解了乐百氏的运作过程的数据。界面原型法，是指设计方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。这种方法比较适合于设计方和用户都不是非常清楚项目需求、只是大概了解用户需求的情况。因为设计方和用户方都不能非常准确的描述出客户的需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解

‘拾’ 如何系统的进行用户需求分析

产品的构思初期，我们会罗列尽可能多需求，也会收集到很多需求。但有些需求是伪需求，有些需求也不具备实现价值，那我们如何做判断呢？每天有无数产品诞生，也有无数产品陨落，很多时候会谈到一个原因，没有把握住用户需求，吸引不了用户。那如何把握住用户需求呢？

用户需求

1、用户需求与产品需求

用户需求是用户从自身角度出发，自以为的需求。

用户经常提出的需求，从他们角度而言都是正确的，但更多是从自身情况考虑，对于产品的某个功能有自己的期望，但对产品定位、设计的依据等情况不了解，他们的建议也许并不是该功能的最好实现方式，也就不足以直接作为产品规划的直接依据。

产品需求是提炼分析用户真实需求，并符合产品定位的解决方案。解决方案可以理解为一个产品，一个功能或服务，一个活动，一个机制。

需求分析：从用户提出的需求出发，挖掘用户内心真正的目标，并转为为产品需求的过程。我们不能简单地看用户需求，而是应该去挖掘用户产生这个需求时，其心里是什么驱动着用户。所以，更应该思考，需求分析的过程，是如何把用户需求转为为产品需求，中间的纽带是什么？

在想如何把用户需求转化为产品需求的中间纽带是什么，不禁要问一个问题，用户需求是怎么产生的？我们只用把原因研究清楚了，才有可能通过产品需求去迎合用户需求。我们追本溯源，用户的需求或者说是欲望究竟缘何而生？

2、马斯洛需求理论

出自经典着作《人的动机理论》的马斯洛需求理论，它阐述了人类的需求源于五类，即生理需求、安全需求、社交需求、尊重需求和自我实现需求。

人类最基本生理需求是衣食住行，若无法满足，人类无法生存。这也是我们提及最多的用户刚需，每一天都离不开，也就蕴含着巨大的市场空间，是众多创业公司和巨头一直抢占的各个山头。

随之产生的是安全需求，希望生活有所保障，避免被物理伤害。这是医疗人身保障等社会基础设施的建设，是“互联网+”正在升级的主要领域。

两个需求得到满足后个体会产生友谊、爱情、亲情等各种感情诉求，也渴望成为集体的一部分，几乎没有人希望过着孤独，不与外界产生联系的生活。这块目前最主要便是企鹅帝国的两大关系链产品。

随后希望被人尊重，得到认可和赞赏，名誉、声望和地位的尊重需求，这种需求很少得到充分满足。

自我实现是最高层次的一种需求，实现个人抱负、理想、价值的需要。

3、用户动机

用户的底层欲望就是源于这些需求，而人性产生的欲望，在不同的环境中，因不同的形式、不同的行为之下，会产生各种各样动机，想要达到某种目标，而产品需求，正是迎合用户的动机，来帮助用户更好地实现目标。

其实，用户究竟需要一匹马还是一辆车，就是需要分析用户情境之下的动机是什么？如果是赛马想获得成绩，那确实需要一匹更快的马；如果是想更快地去另一个地方，汽车就是更好地满足用户的需求。当把用户分为司机、车主、乘客，他们的本质需求又是什么呢？这时由核心需求延伸出来的窗户、座椅被洞察并满足。

在挖掘用户动机之时，可以尝试判断是伪需求还是真需求的同时，底层需求的满足有时可以在相似产品中占据优势。微信打飞机相比传统的1942，雷电飞机游戏，在匹配产品特性满足了用户好友间的一些更加底层的需求，如虚荣、攀比、嫉妒、荣耀等等，让游戏更具可玩性。

4、如何挖掘用户动机？

用户的动机会被很当时环境下的复杂因素所影响，也是会涉及很多心理学方面的积累，这是非常考验用户研究和产品经理的硬本事。但我们也可以尝试从几个关键因素来进行场景分析。

基于什么环境：地铁/办公室/室内/公共场合/走路/夜晚/户外......深入情景周围的细节中去

基于什么用户：具备什么特征，比如身份、收入、区域.....

基于什么行为：行为或操作流程，比如购物流程、操作习惯、行为认知.......

场景分析也就是需要考虑具体什么环境（时间、地点、情境）什么类型用户的什么动机，想达到什么目标，以及人与人的关系。如实地记录下来，如果偏差或缺乏信息，之后的分析就会有所偏差。