3.2.2.1 工作内容

＊ 聆听用户的需求
　　分析人员应该与各种层次的客户进行充分的交流和沟通，包括决策领导、使用部门的领导、具体使用人员、系统维护人员等，尽量清楚地理解用户的问题和要求。
＊ 分析和整理所获取的信息
　　对于用户提供的各种问题和要求，分析人员需要对其进行归纳和整理，借助一些工具和方法，从用户一般性的陈述里面提取用户的真正需求，并由此确定软件的功能、性能、接口关系、约束条件等。
＊ 形成文档化的描述
　　不论是用户的提出问题，还是最终获取的需求，都应该形成文档化的描述，这种描述需要各种人员的一致理解和认同。

3.2.2.2 基于用例的方法
　　随着面向对象技术的发展，基于用例的方法在需求获取和建模方面应用得越来越普遍。这种方法是以任务为中心和以用户为中心的，比起使用以功能为中心的方法，它可以使用户更清楚地认识到新系统允许他们做什么。另外，用例有助于分析者和开发者理解用户的业务和应用领域，开发者还可以运用面向对象的设计方法将用例转化为对象模型。
　　在用例模型中，我们只是关心系统所应实现的功能，而不关心内部的具体实现细节。一般来说，用例模型的建立是由开发者和客户共同协商完成的，通过反复讨论需求的规格说明达成共识，明确系统的基本功能，为后续阶段的工作打下基础。
＊ 确定角色
　　角色代表着与系统交互的人或事。通过确认系统功能使用者和维护者以及与系统接口的其他系统或硬件设备等，可以有效地识别出系统角色。
＊ 确定用例
　　一个完整的系统包含若干个用例，每个用例具体说明应完成的功能。识别用例首先要确定系统所能反映的外部事件，并把这些事件与参与的执行者和特定的使用实例联系起来，最终绘制出用例图。
＊ 描述用例
　　单纯地使用用例图不能提供用例所具有的全部信息，因此，需要使用文字描述那些不能反映在图形上的信息。用例描述实际上是关于角色与系统如何交互的规格说明，要求清晰明确，没有二义性。

　　需求获取的关键是通过与用户的沟通和交流，收集和理解用户的各项要求。在需求获取的过程中，软件人员与用户之间最常见的交流方式就是会议和访谈，由于双方的领域知识不同，经常会遇到误解、交流障碍、需求不全、意见冲突等情况。解决这些问题应该从两方面入手，一是提高分析人员的知识技能，使其不仅具备较高的技术水平和丰富的实践经验，还要具备一定的业务基础知识和较强的人际交往能力；二是开展大量的调查研究工作，包括用户访谈、现场考察、专家咨询、会议讨论等，并对大量的一手资料进行分析和整理，从而清楚地理解用户需求。
　　建立用例模型是一种需求获取的有效方法，其简洁清晰的描述方式容易被软件人员和用户共同理解和接受。这种方法已经在许多大型系统的开发中取得成效，实践证明它能有效地解决用户参与的问题。用例模型以用户和任务为中心，将整个工作的焦点集中在从用户的角度说明系统能够干什么，完全不考虑具体的实现细节，从而达到准确地理解客户需求的目的。在用例模型中，角色和用例是两个基本概念，分别代表着系统外部的执行者和系统应包含的功能，因此，建立用例模型的主要工作是确定角色、确定用例和描述用例。