需求分析_ch02_客户眼中的需求.pptVIP

案例 Contoso制药公司的高级经理Gerhard正在与公司信息系统开发小组的新任经理Cynthia会谈。 Gerhard：“我们需要为公司开发一套化学品跟踪管理信息系统，这套系统应该让我们能够对库房和各实验室已有的化学容器进行跟踪管理。这样，化学家们也许可以从楼里某个同事那拿到需要的容器，而不必另外买一个新的。另外，医保部门也要向政府提交一些关于化学品使用情况的报告。再过5个月就要对规定的执行情况进行第一次审查，你们能在那之前把系统开发出来吗？” Cynthia：“我已经明白了这个系统的重要性，不过在我提出进度之前，需要收集一些需求。” Gerhard：“你指什么？我已经告诉你需求了。” Cynthia：“事实上您说的只是项目的概念和一些业务需求，这些高层的需求不能给我足够的细节让我知道开发什么样的一个软件，可能要花多少时间。需要派一个需求分析员去跟部分用户交谈，知道他们对系统的需求。之后才能知道哪些功能既能满足你的业务目标，又能满足用户要求。你也许根本不需要开发一个新的软件系统来达到省钱的目的。” Gerhard从未遇到IS人员有如此的回应。“化学家都是大忙人，他们没有时间在你们开始编程前指出每个细节，你们难道不能估计出开发什么吗？” Cynthia力图说明她的道理---为什么要从将要使用新系统的人们那里收集需求：“如果我们只是猜测用户需要什么，开发出的系统肯定不能让人满意。我们是系统开发人员，不是化学家。我们不可能真正知道化学家需要使用这个系统来做什么。我有过教训，如果我们不在编码之前花时间了解这些问题，结果不会让任何人满意。” Cynthia：“我们可没有那么多时间，我已经告诉你我的需求。请马上开始，随时向我通报进展情况。” 客户泛指直接或间接得益于产品的个人或组织。软件的客户包括那些提出软件需求，购买、定义、使用软件产品或选择接受软件功能的项目涉众。 高级管理层的客户负责定义业务需求，给出高层次的产品概念，并从业务角度说明为什么需要这样一个产品。 实际使用系统的人提出用户需求，用户能够描述出他们需要使用产品完成哪些任务，以及他们希望系统具有哪些质量特性。 用户代言人，提出业务需求，但是不是直接使用者，往往不能准确提供用户需求。 某些需求问题源于混淆了不同层次的需求（业务需求、用户需求、功能需求） 软件客户的权利 要求需求分析员使用客户的语言 要求需求分析员熟悉客户的业务，了解客户对系统的目标 要求需求分析人员把需求收集过程中客户提供的信息组织成书面的软件需求规格说明 要求需求分析员解释需求过程生成的所有工作结果 要求需求分析员和开发人员尊重客户，始终以合作和专业的态度与客户进行互动 要求需求分析人员和开发人员为需求和产品实现提供思路和备用方案 要求开发人员实现能让产品使用起来更容易、更有趣的特性 调整需求，便于重用已有的软件组件 在提出需求变更时，获得对变更的成本、影响及二者权衡关系的真实评估。 获得满足功能和质量要求的系统，这些要求必须事先告知开发人员并征得其同意。 软件客户的义务 为需求分析员和开发人员讲解业务并定义业务术语 提供需求，阐明需求，通过与开发人员的交互将需求充实完善 对系统需求的描述必须详细、准确 需要时，及时对需求做出判断 尊重开发人员对需求成本和可行性的评估 与开发人员合作，为功能需求、系统特性和用例设置优先级 审阅需求文档，评估原型 发现需要变更需求时，及时与开发人员沟通 按照开发组织的变更控制过程提出需求变更 尊重需求分析员在需求工程中使用的过程 签字存在的问题 客户代表把在需求文档上签字视为毫无意义的仪式 开发经理把签字作为冻结需求的方法 现实是不可能在项目初期就能明确所有的需求，需求肯定要随时间的推移而发生变化 签字是建立需求协议的基线 客户管理层相信项目的范围不会过度膨胀直至失控，因为客户掌握了范围变更控制权。 用户代表有信心开发团队会跟他们一同努力开发出符合需求的系统，即使他们还不能在系统构建之前想到所有的需求。 开发管理人员有信心，因为开发团队有了业务伙伴。业务伙伴能够保证项目的中心在业务目标上。 需求分析员也充满信心。因为他们可以有效的管理项目的变更，将变更引起的麻烦减至最低。 10.* ? 2007 by Prentice Hall 第2章 客户眼中的需求 需求分析 第2章：客户眼中的需求 2.1 客户 2.2 客户与开发人员的合作伙伴关系 2.3 关于“签字” 需求分析 第2章：客户眼中的需求 2.1 客户 需求分析 第2章：客户眼中的需求 2.2 客户与开发人员的合作伙伴关系 需求分析 第2章：客户眼中的需求 2.2 客户与开发人员的合作伙伴关系 需求分析 第2章：客户眼中的需求 2.3 关于“签字” 10.* ? 2007 by Prentice Hall * *