1 / 34
文档名称:

客户需求分析.doc

格式:doc   大小:2,398KB   页数:34页
下载后只包含 1 个 DOC 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

客户需求分析.doc

上传人:lu2yuwb 2021/6/2 文件大小:2.34 MB

下载得到文件列表

客户需求分析.doc

相关文档

文档介绍

文档介绍:客户需求分析
客户需求分析方法1 目录 了解用于客户情景分析和语言表达需求的KJ分析方法的重要组成部分 分组 联系 区别 排序 找出NUD客户需求 指出KJ方法怎样用于开发客户需求 指出怎样创立一项客户调查来检验和获得客户需求的排序数据 找出和确认客户NUD需求 Taguchi流失功能需求数据 KJ方法适用于 I-D-O-V的第一阶段 产品商业化过程 KJ方法的位置… KJ 方法是协助发现NUD需求的工具 新: 一种新的需求,客户从来没有提出, 独特: 一种已经被竞争对手或替代产品满足的产品或服务需求,但你公司还没有类似产品 有一定难度: 一种很难去实现的要求 如果不是NUD,怎么办 那么这种需求就是 “ECO”… 容易…对我们来说可以很容易地去实现 普通…我们曾经满足过这种需求,它不是独特的 有历史的…它不是新的需求,我们有丰富经验来满足这种需求 回顾获得和处理客户需求的过程 DFSS 工具: 情景 KJ 分析 DFSS 工具: 情景转化 DFSS 工具: 需求 KJ 分析 DFSS 工具: 客户需求排序调查 进行情景和需求KJ分析需要的信息… 客户采访中得到情景需求和客户语言表达的需求 处理KJ情景数据
需要的资金和资源 概念设计的三个步骤 哦,我获得了很好的数据…但我应该怎样处理数据来确认我创建的是正确的产品要求呢? KJ 方法 Jiro Kawakita, 一位日本人文学家改造了这些方法,用于实施语言分析处理 KJ方法有三个主要步骤: 1. 情景KJ分析 2. 将情景和语言表达数据转化 为需求 3. 需求 KJ 分析 KJ 方法 从原始的语言和文字说明开始 把相似内容的数据分在同一组 把分组数据用结构化的“提炼阶梯”处理,输入的数据形成一个说明的逻辑树 内部数据结构按重要性进行排序,以满足研究的需要 情景KJ: 建立客户工作环境的普通情景 共有两类情景…. 采访过程中在采访者脑海里形成的一幅动态或静态画面 采访者实际看到的有关工作环境的动态或静态画面. 这些情景被用生动的语言在易事贴上记录下来…这是你们团队所看到的记录. 情景KJ: 建立客户工作环境的普通情景 这些情景往往是协助开发潜在需求的难得数据 有些需求并没有被客户表达出来 通过脑海中的情景,你发现的新的机会 看到的而不是听到的机会 建立情景 KJ 图的步骤 步骤 1: 为VOC情景分析提供明确的
对商业用户来说,他们后面是成百上千个供应商,前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客,如何做好精细到一个小小调料包的进、销、调、存的商品流通工作,这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目,正是软件开发成功的关键所在。
  经理:“我们要建立一套完整的商业管理软件系统,包括商品的进、销、调、存管理,是总部-门店的连锁经营模式。通过通信手段门店自动订货,供应商自动结算,卖场通过扫条码实现销售,管理人员能够随时查询门店商品销售和库存情况。另外,我们也得为政府部门提供关于商品营运的报告。”
  分析员:“我已经明白这个项目的大体结构框架,这非常重要,但在制定计划之前,我们必须收集一些需求。”
  经理觉得奇怪:“我不是刚告诉你我的需求了吗?”
  分析员:“实际上,您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论,然后才能真正明白达到业务目标所需功能和用户要求,了解清楚后,才可以发现哪些是现有组件即可实现的,哪些是需要开发的,这样可节省很多时间。”
  经理:“业务人员都在招商。他们非常忙,没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统?”
  分析员尽量解释从用户处收集需求的合理性:“如果我们只是凭空猜想用户的要求,结果不会令人满意。我们只是软件开发人员,而不是采购专家、营运专家或是财务专家,我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过,未真正明白这些问题就开始编码,结果没有人对产品满意。”
  经理坚持道:“行了,行了,我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发,并随时将你们的进展情况告诉我。”
    风险躲在需求的迷雾之后
  以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中,所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户,开发方面的需求分析人员和项目管理者。这部分工作做得到位,能开发出很优秀的软件产品,同时也会令客户满意。若处理不好,则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见