第8章聆听客户的需求.PDFVIP

下载 第8章 聆听客户的需求 需求获取(requirement elicitation) 是需求工程的主体。对于所建议的软件产品，获取需求 是一个确定和理解不同用户类的需要和限制的过程。获取用户需求位于软件需求三层结构的 中间一层。来自项目视图和范围文档的业务需求决定用户需求，它描述了用户利用系统需要 完成的任务。从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些 系统活动有助于用户执行他们的任务。本章将介绍需求获取原理，并把重点放在“使用实例” 方法的应用，这种方法是用于获取产品的用户需求。 需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少 的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就 能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开 始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在 用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成 的失误。 需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、 增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需 求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求 同可能的软件需求相联系（分析）。然后，你可以使客户信息结构化，并编写成文档和示意图 （说明）。下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。这四个过程贯穿着 需求开发的整个阶段。 由于软件开发项目和组织文化的不同，对于需求开发没有一个简单的、公式化的途径。 下面列出了 1 4个步骤，你可以利用它们指导你的需求开发活动。对于需求的任何子集，一旦 你完成了第十三步，那么你就可以很有信心地继续进行系统的每一部分的设计、构造，因为 你将开发出一个好的产品。 8.1 需求获取的指导方针 需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取 只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨 的环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出重要的小组，而不是 假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这种技术 不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。确定用户已经理解：对于某 些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级， 以避免一个不能带来任何益处的无限大的项目。 需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单誊本。作为一个 分析者，你必须透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充（ o p e n - e n d e d ）的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们 第8章 聆听客户的需求 61 下载 的工作。调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。想像你自 己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发 和利用。 还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映，用户 是如何想的？询问问题时，以“还有什么能……” , ”当……时，将会发生什么”“你有没有 曾经想过……”, “有没有人曾经……”为开头。记下每一个需求的来源，这样向下跟踪直到 发现特定的客户。 建议需求开发过程 1. 定义项目的视图和范围 2. 确定用户类 3. 在每个用户类中确定适当的代表 4. 确定需求决策者和他们的决策过程 5. 选择你所用的需求获取技术 6. 运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级 7. 从用户那里收集质量属性的信息和其它非功能需求 8. 详细拟订使用实例使其融合到必要的功能需求中 9. 评审使