如何将用户需求转化为产品需求

Ⅰ 如何进行用户需求分析

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.需求文档
需求开发的最终成果是:客户和开发小组对将要开发的产品达成一致协议.协议综合了业务需求、用户需求和软件功能需求.就像我们早先所看到的,项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求.你必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档,包括质量属性和外部接口需求.只有以结构化和可读性方式编写这些文档,并由项目的风险承担者评审通过后,各方面人员才能确信他们所赞同的需求是可靠的.
你可以使用以下三种方法编写软件需求规格说明:
用好的结构化和自然语言编写文本型文档.
建立图形化模型,这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系.
编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求.
由于形式化规格说明具有很强的严密性和精确度,因此,所使用的形式化语言只有极少数软件开发人员才熟悉,更不用说客户了.虽然结构化的自然语言具有许多缺点,但在大多数软件工程中,它仍是编写需求文档最现实的方法.包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受.图形化分析模型通过提供另一种需求视图,增强了软件需求规格说明.

Ⅱ 用户运营如何做好用户需求的建立

首先从马斯洛需求理论中谈谈用户的需求，马斯洛需要层次主要包含：生理需求、安全需求、爱与归属的需求、尊重的需求、自我实现的需求。总结为用户需求为：基础需求、期望需求、兴奋需求。对于基础需求，主要是生理和安全的需求；期望需求主要是爱与归属的需求和尊重的需求、兴奋需求主要是自我实现的需求。

我先从大家亲身经历过的自己被用户的阶段给大家讲一下：从qq等级升级之后会有星星、月亮、太阳的现实，我想大家都经历过为了升级拼命挂号，买钻的年代。而网络会有一些我们在网络各个平台的网络积分，可以去网络积分商城换取各种网络定制的周边产品，甚至还有京东消费卡等产品，最后再给大家说说天猫的芝麻信用，现在的芝麻信用已经对我们的生活无孔不入了，从租房、贷款、办信用卡等各种与钱挂钩的场景，都会用到你的芝麻信用。这些用户等级的增长都会给予大家一些心理、生理、生活上的改变，也会促使用户来进行活跃。

再说一下我运营社群：运营社，运营社的成员分级大概分为新入群成员—经过筛选制留下来的成员—志愿工作者/内容输出者—管理人员。大概是这样的一种等级，对于心入群的成员，也是通过筛选之后加入运营社的，这些人刚进群处于学习和了解的阶段，大概一个月的时间，运营社会根据大家在社群内的活跃度来剔除一部分不活跃的用户，这样一期一期筛选留下来的用户基本上已经是对运营社忠诚度和活跃度较高的用户了，而这些忠诚度和活跃度较高的用户后来通过每次的话题和分享的活动以及各个志愿者组的招募，运营社就出现了一部分大家耳熟能详的核心成员：万能珍宝、广告达人包子、aso大神子木以及所有分享者和项目支持者，都是运营社的核心成员，最后的管理人员就是这些每个组别的负责人，例如时雨姐负责的视觉设计组，主要对运营社的活动海报、周边产品的设计，我这边负责运营社的话题组，主要是对嘉宾分享的邀请，话题主题的制定，以及这些内容输出的整理和加工。而对于用户分级的不一样那么所谓的需求也是不一样的，除了第一批进入运营社的小伙伴们是凭运气，考报名的顺序来进群的，后续的每一次招募都是有门槛，因为当你让用户的操作成本增加，用户就会更加珍惜，所以运营社一直有筛选机制，来时刻提醒所有用户时刻保持活跃，然后运营社会给予更加活跃的每个城市小分队分发运营社的徽章、还有给予话题讨论获奖者以及分享嘉宾邮寄一些走心的小礼物，一些特别定制的运营社的周边小产品，这些也都是我这边主要去制作，每一次的小礼物我都会亲自去写一封走心的明信片，给予每一个陪运营社走过的社员们一个暖心的回忆，贤哥这边也会不定期给予一些核心成员用心的挑选大家的工作必备物品，也会写上一些肺腑之言来表达与大家在运营社建立的深厚革命友谊。利用这些等级用户的维护，来营造一批核心用户会使运营社的用户关系更加稳固。

这些给予不一样等级的用户的情感运营是用户运营最需要注意的，每一个细节上的小动作最能体验出你对用户是否走心，现在互联网的发达和满目玲琅的app的诞生，你只有通过触达用户内心最需要的需求，你才能紧紧的抓住用户，并促使用户长期活跃下去。

以上观点也仅仅代表个人的建议，可能不太准确。希望大家可以添加个人微信私下交流：zhen826696371（备注：网络派）

Ⅲ 需求是如何变成产品原型的

说其暧昧，是因为在很多互联网公司里面，这两个环节所做的事情是有重合的，这就意味着，他们或许也是整个流程中合作最紧密的两个环节。相对比之下，产品经理更关注的是产品的内部逻辑、操作流程、策略等；而交互设计师更关注的是产品的易用性、流畅度和操作感受。总的来看，似乎可以认为，产品经理是从一个更加宏观的角度去设计产品，而交互设计师，则是从更多的细节出发，去提升用户体验。这两种不同的视角决定了只有产品经理和交互设计师密切配合，深入沟通，才能够最高效最合理的将产品策略转化为产品原型，从而为流水线的后面环节提供精确的参考资料。下面以人人网广告平台的一些产品和交互细节为例，使用对话的形式来分享一下我个人在做交互设计过程中的一些体会和想法。入门级文章，高手请绕行。在广告平台其中一个投放系统中，有一个产品需求，是要根据广告受众所在的地区做广告的定向投放。也就是说，可以控制广告只展示给固定地域的受众。这就意味着，需要设计一个“区域选择器”，供用户选择区域。产品经理的原始需求是这样的：产品经理：“我们这次的投放系统需要设计一个区域选择器，就是让用户选择广告定向投放的区域的。可以精确到城市，可以多选。另外，‘区域’作为一个投放广告的限制条件，如果用户没有选择任何选项，那就代表用户忽略该条件，则该广告会面向全国投放。”交互设计师：“哦。”产品经理：“嗯，我能够想到的这个东西的原型，可以提供两个下拉框，让用户分别选择省和城市。当用户在第一个下拉框里面选定了省以后，第二个下拉框中会显示该省下面的地级市。我做了一个简单的框图，大家看一下。”产品经理：“大概就是这个样子。每选定一个城市，点击后面的添加按钮，可以将该城市添加到下面的列表中。同时，如果点击已经添加的城市名称后面的“删除”链接，则会将该城市从已选列表抹去。”交互设计师：“等一下，我有一个问题。按照产品的策略，如果用户一个城市都不选，那么就会默认投放全国。但是这个概念很难表达给用户，比如说，如果在“区域选择器”旁边放提示，估计没有多少人会注意到。”产品经理：“一个都没选，就是等于忽略条件啊。因为这些都是限制条件。” 交互设计师：“问题是用户很难意识到是这样。在中国人的观念中，大家都是觉得，选上的，是我要的。但是大家没有“不选就等于全要”这种思维习惯。”交互设计师：“我觉得可以这样。我们在现在的“区域选择器”上面放两个单选按钮。一个叫“全国”，另一个叫做“指定”。打开页面时，默认选中“全国”项，并隐藏“区域选择器”。只有用户选择“指定”项时，区域选择器才会出现。这样表达就很明确了，你不是“全国”就是“指定”。”产品经理：“哦~听起来不错。试试。”于是得到了下面这个版本的原型图：交互设计师：“嗯，我想，现在这个版本已经基本上从界面的层面解决了全国投放的选项问题，我想，用户应该不会因为不知道怎么选而卡在这里了。”交互设计师：“我看下一步，需要对一些关键的元素做一定的视觉设计，以便于引导用户操作。比如“添加”按钮，应该更明显些。我觉得可以请UI设计师出一个简单版本的UI了。”产品经理：“稍等一下，我看咱们还是把细节再讨论清楚一些再去找UI吧。比如，字的颜色啊什么的都没定呢。而且，我觉得选中的区域中，每个城市名称后面都跟着一个删除链接，很奇怪。”交互设计师：“嗯。的确。我的想法是这样，字的颜色，就用黑色吧，或者是深一些的灰色也行。虽然从视觉设计的角度来看，视觉设计师觉得稍浅一些的灰色比较养眼，可能黑色太‘抢’。但是咱们的系统毕竟是给人用的，灰色的话，可能会让人误认为这些选项是不可操作的。你看如何？” 产品经理：“同意。” 交互设计师：“关于已经选中的区域列表。我看可以把“删除”链接换成×，事实上，用户对于×这种符号比汉字更敏感。你看，大家不论是用Windows还是 Mac，关闭窗口的时候都是×，早就习惯了。另外，为了让所选定的城市名称看起来是一个整体，并且跟其他城市名称区分开。我看，可以给每一个城市加上背景色，每个城市一个色块，这样也一目了然。” 产品经理：“颜色呢？”交互设计师：“蓝色吧，人人网都是蓝色的风格。”产品经理：“ok”于是，配合UI设计师，得到了下面的界面：产品经理：“我看现在这个地方已经基本上成型了。咱们也已经讨论很很久了。该问问别人的意见。”———-时间分割线———-产品经理：“Hi~ 各位。我收集了一些内部测试的意见。有用户提出，搞不太清楚两个下拉菜单和“添加”按钮之间的关系。”交互设计师：“什么意思？”产品经理：“就是说，有人意识不到选完了省，选完了城市以后，还得点“添加”。他们觉得，选完了就完事了。” 交互设计师：“晕。”交互设计师：“可能是已选列表框在空着的时候长得太秀气了，大家没意识到它是用来装东西的。”交互设计师：“好吧，我有两个方案。1、把“添加”按钮上面加一个向下的箭头。指向已选列表框。2、在已选列表空着的时候，添加一条提示语，来提示用户他并没有完成区域选择操作。”产品经理：“提示语那个，你的意思是说，当用户添加了城市以后，会自动消失是吧？”交互设计师：“是的。”产品经理：“我觉得加提示吧。感觉放箭头有点儿傻。”交互设计师：“嗯，而且，可能放了箭头以后，用户依然不知所云。”产品经理：“那提示语怎么说呢？您尚未添加任何区域，请选定城市后，点击上面的“添加”按钮，该城市会被添加到…”交互设计师：“停！太长了，大部分人不会认真看完的。”产品经理：“的确…”交互设计师：“我看就一句话就可以。写‘您尚未添加任何区域。’”交互设计师：“你看。下拉列表后面的按钮叫“添加”。提示中又明确的传达出了尚未“添加”的状态。这样既说明了这个框框是用来放东西的，又可以告诉用户，这个东西是可以选多个的。因为“添加”的概念就是一个一个往里面放。如果只能放一个，那应该叫“选择”。”产品经理：“顶。” 交互设计师：“而且，我觉得这个控件最初的原型你设计的不错。嗯，用户只要成功的进行一次操作，以后就可以非常高效的进行操作了。这个东西的学习成本和认知成本都比较低。”产品经理：“oh,yeah~”那么，现在的UI是这样的：产品经理：“哎，对了。话说，我最开始的策略是，用户如果不选，相当于全选，要全国投放的。你说如果用户选了“指定”，但是并没有添加具体的城市，直接提交表单，怎么办？系统是应该直接把用户的广告设置成全国投放，还是报错，阻止用户继续？”交互设计师：“我看啊，报错吧。因为现在“全国”和“指定”这两项，已经明确的把整体和局部给分开了。我觉得你那个策略没必要再应用了，因为现在这种已经达到了你最初的目的，而且还好理解。再有就是，咱们的平台是涉及到钱的，是要让用户花钱的，如果让用户不明不白花了冤枉钱，本来想投北京的投了全国，那我们会被用户骂死的。虽然感觉上报错会让用户有挫败感，但是在这种细节上，还是用户利益应该放在第一位，用户体验，可以稍微往后放一放了。”产品经理：“好吧。”交互设计师：“呵呵，你看，这个故事告诉我们，不能每件事情都听产品的。产品提的只是需求，但是如何实现需求，还是得从多个角度来讨论。”产品经理：“好吧。那么，技术兄弟们，下面的工作就拜托你们了。”个人观点：1、产品经理和交互设计师需要时刻密切配合，深入沟通。2、有时候，产品策略和用户体验会发生冲突，这时应该从多种角度去考虑和探讨最终解决方案，不应该有谁一定比谁重要的说法。3、优秀的产品经理，相当于半个交互。同样，优秀的交互设计师，相当于半个产品。二者虽然职位不同，但是应该在一定程度上考虑对方的工作内容。4、产品提出的只是策略和需求，并不是一定要按照产品人员所描述的细节去设计具体的产品细节。交互设计师以及团队中其他所有成员，有义务有权利对产品需求提出自己的见解和更好的设计方案。有不同意见可以讨论，但是最终决定权，应该依然属于产品经理。5、产品经理之所以叫经理，是因为，他们除了设计产品，还需要时刻把握整个流程。比如，当细节没讨论清楚的时候，不要去找UI做设计。更多打印 | 类别：信息和交互 | 源地址

Ⅳ 如何将用户需求转换为产品功能特性需求

客户需求、市场需求、产品需求、设计需求、业务需求、内部需求、外部需求、特性、规格、功能需求 --- 需求工程的基本术语说明
需求分析和管理对产品开发成败至关重要，这一点大家都非常清楚，正因如此，相关的管理体系都对需求进行详细定义和描述，不同体系不同的定义，导致需求术语混乱，笔者结合10多年的需求工程经验，详细分析不同术语区别如下：
客户/用户需求：基于客户认知，更多是客户的直观要求，体现了用户个体的诉求，往往是理想状态，例如：“需要一个功能强大的手机，同时价格要相对便宜”、“我想要的汽车要外观时尚，性能卓越。”，用户需求往往无法直接开发实现，同时用户对自己的需求往往也是模糊的，实际开发中就需要借助类似原型（demo）、参照物等方法，使客户需求具体化。
市场需求：很多人理解的市场需求就是客户需求，个人认为市场需求和客户需求还是有很大差别的，客户需求更多描述客户的诉求，而市场需求不但要描述目标客户的诉求，更需要描述竞争对手针对此需求的反应，例如，竞争对手是如何实现的？如果我们不实现被竞争对手替代的可能性有多大？如果实现我们是否如何做才能超越竞争对手？所以可以理解市场需求是经过产品经理分析后的客户需求，体现了客户和竞争的情况。
产品需求：针对产品需求，个人认为IPD的定义是合理的，IPD把产品需求定义为“产品包需求”，之所以叫“产品包需求”是因为我们给客户交付的不是孤立的产品，而是一个解决方案，同时客户是否购买一个产品不仅仅看产品本身，还会关注品牌、服务、渠道等因素，产品需求要广而不深，需要把产品相关的方方面面都考虑清楚，而不是要针对一点定义的多么精细，需要更多从客户购买决定的全过程来思考，所以一般就会涉及：价格、渠道、包装、性能、易用性、保证、服务、社会接受程度、品牌等；另根据需求理论一般产品需求会在25~99条之间，实际研发项目时，产品需求会直接让领导层来判断该产品的价值、竞争地位等，最终判断该产品是否值得继续做下去。
设计需求：设计需求故名词意就是 设计 + 需求，经常遇到研发人员说设计与需求有时候很难区分开来，其实到了设计需求阶段，设计和需求已经融合在一起了，同时也正是融合在一起，需求才能落实为设计，设计也才能承载需求;对比产品需求，设计需求定义时一定要在深度上下功夫，细化到能够通过设计来实现，并且能落实到具体的物理模块来承载。那么设计需求怎么来的呢？根据需求工程理论设计需求是通过产品需求分解而来，业界常用HD（层次分析法）来分解产品需求，关键问题是大家一定要掌握，一个产品需求需要从哪些方面来分解，从而保证分解的完整性，根据IPD需求工程定义，一个产品需求通常需要从如下：功能、环境、性能、强健性（鲁棒性）、可靠性、可维护性、可用性、安全性、重量、电源、尺寸大小、可运输性/可移动性、灵活性等方面进行分解，当然并不是每个产品需求都要一定分解为这些方面，分解后就形成了与此产品需求相对应的设计需求清单。
规格：我们经常讲：产品需求规格说明书，说明需求和规格本来就是一体化的，规格就是需求的具体说明，例如：“OA要支持IE浏览器” 是需求，那么如果具体定义：“需要具体支持Ie6、Ie7、Ie8”，那么就叫规格；“声音要达到120分贝~190分贝”，这本身就需求 + 规格。
特性：软件行业和军工标准中，经常提到特性这个词语，例如国军标中定义：“特性 --- 识别和区分各类产品或服务的属性，这种属性包含物理、化学、功能或其他可识别的性质。”；所以模糊来讲特性就是产品需求，如果更精确来讲，特性是产品需求中的与其他产品有明显差异的个性化需求，通常我们把产品需求划分为3类：BSA（Basic、Satisfied、Attractive），分别为基本需求、最好满足的需求、更具有吸引力的需求；所以可以理解特性为：A的需求。
测试需求：什么叫测试需求，很多人认为测试需求是基于对产品需求的分析，测试人员提炼出来的需要重点测试的点，故名词意：测试需求。不管别人怎么认为，本人认为测试需求是本身是个变态和错误的做法，只所以有测试需求，原因是实际研发中产品需求、设计需求定义不清晰，开发人员就糊里糊涂地进行设计和开发了，但测试人员无法基于需求提炼出来测试点，迫于无奈，不得不给需求定义人员擦屁股，将需求细化到能够提炼到测试点的级别。正规做法应该如此：需求定义人员详细定义产品需求和设计需求，而同时测试设计人员直接针对此需求分析该需求如何测试，重点测试哪些内容，所以测试需求，本身应该叫：需求的可测试性分析，其实是需求的属性之一，这样做的好处是：可以直接判断需求定义是否具体，是否可验证，凡是不能验证的需求都是错误的需求；后续测试用例开发人员针对需求的可测试性分析，直接编写对应的测试用例。
内部需求：实际产品需求定义时，我们更关注的是外部客户的需求，因为外部客户直接给我们钱，但其实产品也有内部客户，也需要关注内部客户的需求，谁是内部客户呢？例如制造、客服就是内部客户，如果设计时，没有考虑到制造的要求，直接导致制造效率低下、良品率低，最终影响产品的市场表现；制造部门的需求、客服部门的需求，也需要在产品开发前期就识别，成为产品需求和设计需求的一部分，并在设计开发中实现。
外部需求：对照内部需求，外部需求是客户、渠道、合作商、用户等，外部关联单位的需求，具体分析时就需要通过销售过程分析，详细分析产品从生产线下来，到最终客户手里需要经过哪些环节，而这些所有环节的需求统称外部需求，所有外部需求都是我们需要重点关注的，一个环节不满足，产品可能就到不了最终客户手里，就无法转化为实实在在的商业利益。
业务需求：针对业务需求业界缺少标准一致清晰的定义，个人认为业务需求更多是从客户的业务发展、财务、战略出发，更多体现了客户高层的要求，涉及产品整体宏观上的要求；例如针对ERP，“库存周转率提高50%”，针对电信设备，“能够无缝升级到下一代网络，从而节约投资成本”，针对银行系统，“提高客户的资金周转效率30%”；针对网络游戏，“使单个用户的费用贡献提高50%”，等等，这些业务需求更多体现客户经营的需要，具体业务需求需要通过产品需求、设计需求去细化和实现；例如ERP，为了是实现“库存周转率提高50%”，就要求ERP系统实现：相应的报表统计功能、告警通知能力、订单预期功能等，这些可以成为产品需求或设计需求。
功能需求：功能需求其实是设计需求的一个类别，为什么这么有名呢？核心原因还是软件行业鼓吹、宣传的原因，因为软件行业基本都是功能需求，就是第一步干什么，下一步做什么，然后再做什么的场景描述，所以功能需求就这样出名了，功能需求与其他设计需求定义时，核心不同点是，功能需求需要详细定义场景描述，其中包含正常场景、异常场景，业界通用定义方法是Usecase法。
-----------
（作者： Tiger.dong

Ⅳ 如何将用户需求转化为产品功能特性需求

客户需求、市场需求、产品需求、设计需求、业务需求、内部需求、外部需求、特性、规格、功能需求 --- 需求工程的基本术语说明
需求分析和管理对产品开发成败至关重要，这一点大家都非常清楚，正因如此，相关的管理体系都对需求进行详细定义和描述，不同体系不同的定义，导致需求术语混乱，笔者结合10多年的需求工程经验，详细分析不同术语区别如下：
客户/用户需求：基于客户认知，更多是客户的直观要求，体现了用户个体的诉求，往往是理想状态，例如：“需要一个功能强大的手机，同时价格要相对便宜”、“我想要的汽车要外观时尚，性能卓越。”，用户需求往往无法直接开发实现，同时用户对自己的需求往往也是模糊的，实际开发中就需要借助类似原型（demo）、参照物等方法，使客户需求具体化。
市场需求：很多人理解的市场需求就是客户需求，个人认为市场需求和客户需求还是有很大差别的，客户需求更多描述客户的诉求，而市场需求不但要描述目标客户的诉求，更需要描述竞争对手针对此需求的反应，例如，竞争对手是如何实现的？如果我们不实现被竞争对手替代的可能性有多大？如果实现我们是否如何做才能超越竞争对手？所以可以理解市场需求是经过产品经理分析后的客户需求，体现了客户和竞争的情况。
产品需求：针对产品需求，个人认为IPD的定义是合理的，IPD把产品需求定义为“产品包需求”，之所以叫“产品包需求”是因为我们给客户交付的不是孤立的产品，而是一个解决方案，同时客户是否购买一个产品不仅仅看产品本身，还会关注品牌、服务、渠道等因素，产品需求要广而不深，需要把产品相关的方方面面都考虑清楚，而不是要针对一点定义的多么精细，需要更多从客户购买决定的全过程来思考，所以一般就会涉及：价格、渠道、包装、性能、易用性、保证、服务、社会接受程度、品牌等；另根据需求理论一般产品需求会在25~99条之间，实际研发项目时，产品需求会直接让领导层来判断该产品的价值、竞争地位等，最终判断该产品是否值得继续做下去。
设计需求：设计需求故名词意就是 设计 + 需求，经常遇到研发人员说设计与需求有时候很难区分开来，其实到了设计需求阶段，设计和需求已经融合在一起了，同时也正是融合在一起，需求才能落实为设计，设计也才能承载需求;对比产品需求，设计需求定义时一定要在深度上下功夫，细化到能够通过设计来实现，并且能落实到具体的物理模块来承载。那么设计需求怎么来的呢？根据需求工程理论设计需求是通过产品需求分解而来，业界常用HD（层次分析法）来分解产品需求，关键问题是大家一定要掌握，一个产品需求需要从哪些方面来分解，从而保证分解的完整性，根据IPD需求工程定义，一个产品需求通常需要从如下：功能、环境、性能、强健性（鲁棒性）、可靠性、可维护性、可用性、安全性、重量、电源、尺寸大小、可运输性/可移动性、灵活性等方面进行分解，当然并不是每个产品需求都要一定分解为这些方面，分解后就形成了与此产品需求相对应的设计需求清单。
规格：我们经常讲：产品需求规格说明书，说明需求和规格本来就是一体化的，规格就是需求的具体说明，例如：“OA要支持IE浏览器” 是需求，那么如果具体定义：“需要具体支持Ie6、Ie7、Ie8”，那么就叫规格；“声音要达到120分贝~190分贝”，这本身就需求 + 规格。
特性：软件行业和军工标准中，经常提到特性这个词语，例如国军标中定义：“特性 --- 识别和区分各类产品或服务的属性，这种属性包含物理、化学、功能或其他可识别的性质。”；所以模糊来讲特性就是产品需求，如果更精确来讲，特性是产品需求中的与其他产品有明显差异的个性化需求，通常我们把产品需求划分为3类：BSA（Basic、Satisfied、Attractive），分别为基本需求、最好满足的需求、更具有吸引力的需求；所以可以理解特性为：A的需求。
测试需求：什么叫测试需求，很多人认为测试需求是基于对产品需求的分析，测试人员提炼出来的需要重点测试的点，故名词意：测试需求。不管别人怎么认为，本人认为测试需求是本身是个变态和错误的做法，只所以有测试需求，原因是实际研发中产品需求、设计需求定义不清晰，开发人员就糊里糊涂地进行设计和开发了，但测试人员无法基于需求提炼出来测试点，迫于无奈，不得不给需求定义人员擦屁股，将需求细化到能够提炼到测试点的级别。正规做法应该如此：需求定义人员详细定义产品需求和设计需求，而同时测试设计人员直接针对此需求分析该需求如何测试，重点测试哪些内容，所以测试需求，本身应该叫：需求的可测试性分析，其实是需求的属性之一，这样做的好处是：可以直接判断需求定义是否具体，是否可验证，凡是不能验证的需求都是错误的需求；后续测试用例开发人员针对需求的可测试性分析，直接编写对应的测试用例。
内部需求：实际产品需求定义时，我们更关注的是外部客户的需求，因为外部客户直接给我们钱，但其实产品也有内部客户，也需要关注内部客户的需求，谁是内部客户呢？例如制造、客服就是内部客户，如果设计时，没有考虑到制造的要求，直接导致制造效率低下、良品率低，最终影响产品的市场表现；制造部门的需求、客服部门的需求，也需要在产品开发前期就识别，成为产品需求和设计需求的一部分，并在设计开发中实现。
外部需求：对照内部需求，外部需求是客户、渠道、合作商、用户等，外部关联单位的需求，具体分析时就需要通过销售过程分析，详细分析产品从生产线下来，到最终客户手里需要经过哪些环节，而这些所有环节的需求统称外部需求，所有外部需求都是我们需要重点关注的，一个环节不满足，产品可能就到不了最终客户手里，就无法转化为实实在在的商业利益。
业务需求：针对业务需求业界缺少标准一致清晰的定义，个人认为业务需求更多是从客户的业务发展、财务、战略出发，更多体现了客户高层的要求，涉及产品整体宏观上的要求；例如针对ERP，“库存周转率提高50%”，针对电信设备，“能够无缝升级到下一代网络，从而节约投资成本”，针对银行系统，“提高客户的资金周转效率30%”；针对网络游戏，“使单个用户的费用贡献提高50%”，等等

Ⅵ 对交互设计的看法，怎样把用户需求转化为实际产品

1、分析阶段
需求分析、用户场景模拟、竞品分析（聆听用户心声）。
需求分析：对于一个产品来说，必然有对用户需求的分析内容，更多的是从MRD与PRD获得，或者从产品需求评审会议上得到需求分析的内容，当然可以直接与产品经理交流获得相关产品需求。如果说设计原则是所有设计的出发点的话，那么用户需求就是本次设计的出发点。
用户场景模拟：好的设计建立在对用户深刻了解之上。因此用户使用场景分析就很重要，了解产品的现有交互以及用户使用产品习惯等，但是设计人员在分析的时候一定要站在用户角度思考：如果我是用户，这里我会需要什么。
竞品分析（聆听用户心声）：竞争产品能够上市并且被UI设计者知道，必然有其长处。这就是所谓三人行必有我师的意思。每个设计者的思维都有局限性，看到别人的设计会有触类旁通的好处。当市场上存在竞品时，去听听用户的评论，哪怕是骂声都好，别沉迷于自己的设计中，让真正的用户说话。
输入物：MRD、PRD、市场调查报告、竞品分析文档（或其一或全部）
输出物：设计初稿（或许只是几个简单的界面）
2、设计阶段
设计方法采用面向场景、面向事件驱动和面向对象的设计方法。面向场景是针对该产品使用场所等模拟，模拟用户在多种情况下产品使用的模拟。面向事件驱动则是对产品响应与触发事件的设计，一个提示框，一个提交按钮……这类都是对事件驱动的设计。面向对象，产品面向的用户不同对于产品的设计要求不同，不同年龄层的用户对于产品的要求不同，产品的用户定位将对UI设计师影响因素。
输入物：交互文档（高保真原型）
输出物：设计终稿（所有的设计稿）
3、配合
UI设计师交出产品设计图时，更多的配合开发人员、测试人员进行截图配合。配合开发人员对于PSD格式的图片切图操作，对于不同的开发人员的要求，切图方式也有不同，UI设计师需配合相关的开发人员进行最适合的切图配合。
输入物：设计终稿
输出物：设计修改稿（设计稿切片）
4、验证
产品出来后，UI设计师需对产品的效果进行验证，与当初设计产品时的想法是否一致，是否可用，用户是否接受，以及与需求是否一致。都需要UI设计师验证，UI设计师是将产品需求用图片展现给用户最直接的经手人，对于产品的理解会更加深刻。
输入物：产品
输出物：产品（面向用户最终版本）
产品UI设计中夹杂着许多设计原则要求，统一公司UI设计流程，使UI设计师参与到产品设计整个环节中来，对产品的易用性进行全流程负责，使UI设计的流程规范化，保证UI设计流程的可操作性。UI设计师应该分析公司产品的特点，制定符合产品生命周期的UI设计流程。每个产品的生命周期中，UI设计师应该严格按照流程，完成每个环节的职责，确保流程准确有效的得到执行，从而提高产品的可用性，提升产品质量。

Ⅶ 如何发现用户需求如何分析转化产品需求如何判断需求优先级

1）用户调研，挖掘本质；
2）需求与产品定位和核心功能的契合度，带来的价值，进行灰度测试；
3）性价比=价值/成本；不同阶段需求优先级排期不同。
传智播客官网视频库里面忘记是哪个基础视频讲过，我都会偶尔去那逛逛，找找资源。

Ⅷ 如何将顾客需求转化为产品特性

如何将顾客需求转化为产品特性
3、顾客需求转化为产品需求的方法——QFD（质量功能展开）
作为一种面向顾客需求的产品开发思想和方法论的质量功能展开（QFD），在将顾客需求转化为产品特性的过程中，它提供了有力的理论指导和操作方法，并已经得到实践的检验。QFD借助质量屋，量化分析顾客需求与工程措施之间的关系，通过对顾客需求进行多次展开，转化为产品的设计要求、零部件特性、工艺要求和生产要求，已经指导产品设计和质量保证，充分体现了以市场为导向的产品开发指导思想。
QFD是一种顾客驱动的产品开发系统化方法，采用系统化、规范化的方法调查和分析顾客需求，并以矩阵或图表的形式将顾客需求转化成产品开发阶段的工程特征、零部件特征、工艺特征和质量控制参数和方法等产品特性信息，以使产品能真正全面的满足顾客需求。
QFD包括两个基本过程：顾客需求的提取和顾客需求的瀑布式分解过程。顾客需求的提取时通过各种市场调查和各种渠道收集原始的顾客需求，然后进行分类和整理，并用加权表示顾客需求的相对重要度。顾客需求的提取是QFD中最关键的一步，他直接关系到QFD的成功与否。顾客需求的瀑布式分解过程由产品规划、零件规划、工艺规划和生产规划四个阶段组成。通过四个过程，顾客需求逐步展开为设计要求、零件特性、工艺特性和生产要求等一系列可测量的、可操作的活动或指标。在展开过程中，上一步的输出就是下一步的输入，构成瀑布式分解的过程。
在顾客需求逐步展开过程中，QFD采用了质量屋（HOQ）.质量屋是实现QFD思想的一种工具，是QFD基本原理的核心组成部分，质量屋提供了将顾客需求转换为产品技术需求和零部件特性并配置到整个研发过程的结构。
现以产品规划过程来说明质量屋的构成，在这一阶段的质量屋中，顾客需求被展开为设计要求。
产品规划矩阵用于将顾客需求转换成技术需求，并分别从顾客角度和技术要求对市场上的同类产品进行评估，在分析举证的各部分信息的基础上，确定各个技术需求的目标价值以及在零件配置阶段需要的技术需求 。对上图各部分的解释说明：
1）顾客需求及权重是矩阵最基本的输入，他们是通过广泛的市场调查得到的，在确定顾客需求是应避免主观想象，注意真实性和全面性。在图中（1）是顾客需求栏。
2）根据市场调查得到的顾客需求，确定最终产品所应具有的技术需求，他们直接与顾客有关，并将有重点的配置到设计、工艺、制造中去。在图中（2）为技术需求栏。
3）通常用一组符号或数字来表示顾客需求和技术需求之间的相关程度。如用5表示技术需求与满足其对应的顾客需求强相关程度；3表示中等程度相关；1表示弱相关。如果关系矩阵中相关符号很大部分是弱相关，则表示技术需求没有足够的满足顾客需求，应对应进行修正。图中（3）为顾客需求和技术需求的关系矩阵栏。
4）顾客竞争性评估，是指从顾客的角度对本公司产品和竞争者产品在满足顾客需求方面的评估。他反映了现有产品的优势和弱点以及产品需要改进的地方。评估数据一般通过顾客调查获得。图中（4）为顾客竞争性评估栏。
5）技术性竞争评估，与顾客竞争性评估不同，是从技术角度对产品的竞争力进行评估。在图中（5）是技术竞争性评估栏。
6）技术需求之间常常是相互影响的，改善其中的某一项技术需求的措施可能有助于改善另外一个技术需求，或者将对另外一个技术需求产生负影响。有助于改善的叫正相关，影响另一技术需求的叫负相关。如图（6）中为技术需求相互关系栏。
7）技术需求目标值，根据顾客需求及权重、顾客需求与技术需求的关系矩阵以及产品的优势和弱点，确定技术需求的目标值。在图中（7）为技术需求目标值栏。
基于下道工序就是上道工序的顾客的思想，QDF还包括其他矩阵，如零件配置举证，工艺规划矩阵和质量控制规划矩阵等，以进一步把顾客需求展开到产品的全过程。
零配件配置矩阵从产品规划中获得技术需求，并作为零件配置矩阵的输入。包括：技术需求、关键性零件特性、技术需求与关键性零件特性关系矩阵、关键性零件特性目标值等，其质量屋的构成与产品规划相似。
工艺规划矩阵和林间配置矩阵相似，他从零件规划中获取去零件特性作为输入。主要包括关键零件特性、关键工艺特性、关键零件特性和工艺特性关系矩阵，工艺规范等。
质量控制规划矩阵以工艺规划矩阵输出的关键工艺特性作为输入，将其转化为相应的质量控制要求和具体控制办法。

Ⅸ 如何取得用户需求

你好：
● 数据分析
通过一些客观数据，例如，流量、检索量等，能很好的说明问题； 数据分析依赖人员，同样的数据被不同的人解读结果完全不同； 以数据说话，是产品管理人员的基本素质之一； 数据分析的结论，往往是最可信、最可靠的结论。
● 邀请用户进行访谈，观察或者让用户说出自己的需求与偏好。
这样的方法能够与用户面对面的交流，也能够在旁边静静地观察用户的使用习惯； 但是，由于用户是明确知道了此次访谈的目的，因此，用户在思考问题和使用方面会受到心里影响的偏差，导致结果的不可信；
其次，有很多产品，无法准确的获取用户的信息，导致，被邀请的用户，往往不是产品的核心用户，或者说，用户并不是经常使用这个产品；
不经意之间与朋友之间的聊天会比邀请用户来访谈效果好很多。
● 用户反馈
1）在网站上提供让明显的让用户给网站提意见的链接或者邮箱地址；
2）认真对待每一个用户的反馈，因为大部分情况来说，有时间填写用户反馈的用户（也就是会抱怨的用户），今后往往可能成为忠诚的用户； 3）从用户反馈中发现产品的不足、发现用户的需求；
4）不是每一个用户反馈的需求都需要满足，根据反馈的程度制定优先级。 ● 搜索
这是产品管理人员一种主动收集信息的方式，通过各种搜索引擎，如博客搜索 、网页搜索 、博客空间 等渠道获得用户的评论；
要能够自主的区分何为“普通用户”的反馈、何为“评测人员”的试用报告； 搜索出来的原始内容相对于数据分析来说，更加依赖于人的分析与理解； 这种方法依赖于长期的观察与收集，短期的内容没有足够的说服力。

Ⅹ 工作中，该如何做需求分析

需求分析的过程

（1）用户分析通过用户生活形态分群的方法，按照用户的价值观和生活形态特征，对用户进行分群，形成具有典型性的细分群组，并且总结提炼出该群组用户的一般特征，清晰定位目标市场与目标用户群体，指导产品开发和创新。主要解决目标用户是谁，市场预期容量有多大的问题。

（2）需求挖掘根据上一阶段选定的目标用户群，进行抽样研究，通过记录某一特定类型用户的生活场景或业务使用体验，洞察用户的典型行为或生活习惯，了解他们在特定场景下的需求，结合企业自身的能力，拓展业务创新的空间。

（3）需求验证在定性挖掘用户需求碎片的基础上，要通过定量的调查从两个方面对需求进行验证：首先，要验证需求的普遍性，目标用户群中是否大部分用户都有类似的需求；其次，要验证需求的迫切性，目标用户群中大部分用户对需求的排列顺序。经过验证排序后的需求，就可以作为用户需求的最后输入。当然，要最终成为产品需求并且转化成产品功能，还需要从其他几个方面进行分析和筛选，在此就不详细介绍