文档介绍：客户需求分析
LT
客户需求分析方法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情景分析提供明确的
分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”
经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”
分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”
经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”
    风险躲在需求的迷雾之后
以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。
    拨开需求分析的迷雾
像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：
·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的