需求分析_ch06_收集客户的需求.pptVIP

要收集客户的需求，应采取以下步骤 确定产品的不同用户类型 确定用户需求的来源 挑选出每一类用户和其他涉众的代表并与他们一起工作 商定谁是项目需求的决策者 开发人员开发的产品和用户期望获得的产品之间常常存在较大差距，即所谓的期望鸿沟。客户参与是避免期望鸿沟的唯一途径。 用户说他们想要的功能并一定等同于产品进行工作时需要的功能。要想更准确地把握用户的需求，需求分析员必须收集用户的意见并进行分析和阐明，决定开发什么样的产品从而使用户完成他们的工作。 与潜在用户进行交谈和讨论 描述现有产品或竞争产品的文档 系统需求规格说明 现有系统的问题报告和改进要求 市场调查和用户问卷调查 观测用户如何工作 用户工作的情景分析 事件和响应 产品的不同用户之间在很多方面存在差异，可以根据这些差异将用户分成若干不同的用户类 常常喜欢根据用户的地理位置、所在公司的类型或所担任的工作来划分他们的类别，而不根据他们与系统的交互方式 用户类未必都是人，与系统打交道的其他应用程序或硬件均可被看作额外的用户类 如果要使用户类的描述更生动具体，可以为每个用户类创造一个任务角色 化学品跟踪管理系统的用户类 用户类角色实例 化学家Fred今年41岁，自从14年前获得博士学位后，便一直在Contoso制药公司工作。Fred对计算机的耐心有限，他通常同时开展相关领域的两个项目。 他的实验室中大约有400瓶化学品，还有化学气体容器。他平均每天从仓库领4种新化学品，其中两种可从仓库中得到，一种向厂商购买，另一种则是Contoso公司拥有专利的化学品样本。 Fred有时会用到一些危险的化学药品，之前需要专门培训以了解如何安全使用这些化学品。当他第一次使用某种化学品时，Fred要求系统自动将它的具体安全数据通过电子邮件发给他。Fred每年都会研制出大约10种新的专利药品送到仓库。 Fred希望系统能够自动生成他上月使用化学品的报告，并且通过电子邮件发给他，这样他能监控自己对化学品的使用情况，以了解化学品可能对他的伤害。 每一类用户都应该有自己的代表。用户代表应当自始至终参与项目的开发过程，而不是仅参与最初的需求阶段 研究显示，与不太成功的项目相比，在那些成功的项目中，客户与开发人员的沟通途径种类更多、更直接。 然而，某些中间层却是有益的，例如熟练的需求分析员。 项目代言人(或称项目协调人)为几位用户类的关键成员，负责提供需求，是所属用户类的成员与项目的需求人员之间的主要联系人。 优秀的项目代言人应具备对新系统的清晰认识，并对其充满热情，并且善于沟通且受同事的尊重。 如何让人接受项目代言人的概念 如果遇到阻力，应该向反对者指出用户参与不足已被证明是软件项目失败最主要的原因之一。 因为没有人理解系统而导致交付的系统达不到标准 对项目代言人的要求 设置多位项目代言人 用户代言人成功的条件 理解并履行他的职责 被赋予用户需求级别的决策权 有足够的工作时间 用户代言人应避免的陷阱 一个合格的用户代言人根据授权做出的决定却被经理推翻 用户代言人如果忘了自己应代表其他客户，而只表达自己的需求，工作肯定做不好 缺乏对新系统的充分理解，可能在重要问题上听从需求分析员的决定 资深用户可能因为自己没有时间而推荐缺少经验的用户担任代言人。这可能导致“幕后操作”问题，资深用户还是想对项目方向施加强大的影响。 谨防用户试图代表他们不属于的用户类发表意见 应该尽可能在公司的层次结构的底层，由那些贴近和了解问题的人来做决策。 如果是个别用户之间的分歧，则由用户代言人来裁决。 如果不同的用户类或客户提出的需求发生冲突时，应支持最重要的用户类、或对产品的商业前景影响最大的客户群提出的问题。 不同的企业客户都可能要求按他们自己的喜好设计产品。解决办法还是依据项目的业务目标来确定哪些客户对项目的成败影响最大。 用户经理表述的需求有时会和其部门中实际用户的需求相矛盾，但不属于用户类的经理应该服从于项目代言人，因为后者是用户的代表。 当开发人员对产品的想法与客户的要求不一致时，通常由客户作出决定。 10.* ? 2007 by Prentice Hall 第6章 收集客户的需求 需求分析 第6章：收集客户的需求 6.1 收集客户需求的步骤 6.2 需求的来源 6.3 用户类 6.4 寻找用户代表 6.5 用户代言人 6.6 谁来做出决策 需求分析 第6章：收集客户的需求 6.1 收集客户需求的步骤 需求分析 第6章：收集客户的需求 6.2 需求的来源 需求分析 第6章：收集客户的需求 6.3 用户类 需求分析 第6章：收集客户的需求 6.3 用户类 医保部门人员使用系统只是为了生成(预先指定的)季度报告，这些报告需符合联邦和州政府关于化学品使用和处理的规定。医保部门的理每年很可能会根据政府条例的变化对报告提出