表2用例描述格式.PPTVIP

第4章 建立用例模型 4.1 需求获取 4.2 分析需求 4.3 用例在需求分析中的使用 4.4 识别参与者 4.5 确定用例 4.6 用例的粒度 4.7 用例间的关系 4.8 用例描述 4.9 用例建模 需求分析就是分析软件用户的需求是什么。 需求分析之所以重要，就因为他具有决策性、方向性和策略性的作用，它在软件开发过程中具有举足轻重的地位，在一个大型软件系统的开发中，他的作用要远远大于程序设计。 需求分析的任务就是解决“做什么”的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。 整个软件需求工程研究领域划分为需求开发和需求管理两部分。 4.1 需求获取 需求是客户在项目立项时就有的一个远景。客户需求将决定在整个项目中需要承办方具体做些什么，即承办方的任务。承办方在明确了需求后，就会开始后期的设计、开发、测试、部署等工作。 4.1 需求获取 需求获取在软件工程中非常重要，因为后续的设计、开发等都基于需求。如果需求获取不正确或在需求开发过程中很多功能没有挖掘出来，那么在后期选择弥补时，将会造成项目延期以及成本大幅度增加的严重后果。 如何获取需求是摆在承办方面前的首要任务。 4.1 需求获取 需求获取的目的是通过各种途径获取用户的需求信息，由于在实际工作中，大部分客户无法完整地讲述其需求，因此需求获取是一件看似简单，做起来却很难的一件事情。 在需求获取过程中，主要需要弄清楚3个问题，即： 明确需要获取的信息（What） 明确所获取信息的来源和渠道（Where） 怎样获取需求（How）。 4.1 需求获取 (1) 明确需要获取的信息（What） 需求分析师应在需求获取前明确需要获取的信息，以确保在实施需求获取时有的放矢。通常需求获取需要获取的信息包括三大类： a. 与问题域相关的背景信息（如业务资料、组织结构图和业务处理流程等）； b. 与要求解决的问题直接相关的信息； c. 用户对系统的特别期望与施加的任何约束信息。 4.1 需求获取 (2) 明确所获取信息的来源和渠道（Where） 需求分析师还应确定获取需求信息的来源与渠道，以提高需求分析师在需求获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。 需求信息的来源通常包括： a. 来自客户的需求； b. 竞争对手的产品优势与不足； c. 国家政策、业务规则以及相关行业标准； d. 实施产品设计所需满足的需求； e. 执行测试验证工作所需满足的需求； f. 实施系统安装、维护所需满足的需求。 4.1 需求获取 获取需求信息的渠道包括： a. 用户或客户 b. 公司研发管理部门 c. 公司技术管理部门 d. 项目实施部门 e. 营销管理部门 f. 旧有系统的研发项目组 g. 来自项目组内 4.1 需求获取 (3) 怎样获取需求（How） 需求分析师应选择至少一种需求获取技术获取相关的需求，作为需求分析的依据。需求获取技术包括但不限于： a. 用户访谈 b. 用户调查 c. 现场观摩用户的工作流程，观察用户的实际操作 d. 从行业标准、规范中提取需求 e. 文档挖掘 f. 需求讨论会 g. 原型法 4.2 分析需求 通过需求获取，总结出客户服务系统主要功能需求包括以下几个方面： (1) 客户可以通过不同的方式（如电话，互联网）对软件产品或项目提出使用中的BUG或疑难问题以及投诉建议等内容。 (2) 客户服务人员应当能保存客户资料，保存客户历次来电内容，并对客户提出的问题及时给予解答，不能在电话中处理的应当交由相关技术工程师继续跟进处理。 (3) 对需要安排上门维护的申请应能及时反映给相关部门领导，并由其作出派工处理。 (4) 应能及时反馈有派工任务的消息给相关技术工程师，并能保存其处理结果。 (5) 各部门领导应能对投诉的申请给予及时处理，并能保存处理结果。 (6) 公司领导和部门领导应能及时查询客户的来电内容，了解产品使用情况及客户服务人员的售后服务质量等相关业务的综合统计信息。 以上需求信息需要进行详细的分析、归纳。 4.2 分析需求 经过分析，为满足上述需求的客户服务系统应包括以下几个模块： (1) 基础资料维护模块。包括客户基础资料录入修改，客户服务系统用户信息的添加、删除和修改，软件产品的基础资料维护，已上线项目的基础资料维护以及FAQ经验库的数据维护。 (2) 客户服务业务处理模块。包括客户咨询服务处理，故障申报处理，投诉处理，客户服务人员回访处理，维护人员上门处理，部门领导派工处理。 (3) 信息查询统计模块。包括基础资料查询统计，客户咨询的查询与统计，派工单完成情况，回访情况，维护报告查询统计以及相关报表的查询。 4.2 分析需求 软件系统的需求分析可以由产品工程师或系统分析师或两者分阶段合作完成全部的需求分析工作。其主要任务是逐