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

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