Java软件工程与项目案例教程(三).pptxVIP

Java软件工程与项目案例教程（三）;主要内容;3.1 软件需求分析概述;3.2 软件需求分析过程;软件需求的属性包括可验证性、优先级、唯一性和定量化。 可验证性 可验证性是软件需求的基本属性。软件需求必须是可验证的，否则软件的评审和测试就没有相应的依据。 优先性 软件需求具有优先级，应该能够在有限的资源（资金、人员、技术）情况下进行取舍。 唯一性 软件需求应唯一地标识出来，以便在软件配置管理和整个软件生命周期中进行管理。 定量化 软件需求应尽可能地表述清楚，没有二义性，进行适当的量化，应避免含糊、无法测试、无法验证的需求出现。软件质量的可靠性和用户界面的友好性等非功能性需求的量化尤为重要。例如，系统应支持2000个并发用户，系统回应时间应低于10秒，这就是需求的量化。 ;3.2.2 需求过程中的角色如下图所示： ;3.2.3 需求过程迭代 软件需求分析是一个不断认识和逐步细化的过程。该过程将软件计划阶段所确定的软件范围（工作范围）逐步细化到可详细定义的程度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决办法。需求过程要适应客户和项目的环境，并作为配置项纳入配置管理。 当前的软件业面临着巨大竞争压力，要求软件企业有更低的构建成本和更短的开发周期。有些项目受环境的影响很大，有些项目是对原有项目的升级，有些项目客户要求在指定的架构下完成。在项目初期，客户不能完全确定需要什么，对计算机的能力和限制不甚了解，所以需求过程很难是一步到位的过程。随着项目的深入，需求将随时间变化而发生变化。 因此，需求过程是一个迭代的过程，每次迭代提供更高质量和更详细的软件需求。这种迭代会给项目带来一定的风险，上一次迭代的设计实现可能会因为需求不足而被推翻。但是，系统分析师应根据项目计划，在给定的资源条件下得到尽可能高质量的需求。 ;3.2.4 需求的来源 （1）系统目的 （2）行业知识 （3）软件涉众 （4）运行环境 （5）组织环境 软件涉众： 应充分考虑不同软件涉众的需求，如果只强调某一角色的需求，忽略其他角色的需求，往往将导致软件系统的失败。系统分析师应从不同涉众的角度去识别、表述他们的需求。用户的文化差异、客户的组织结构，常常会是系统难以正常实施的原因。 ;3.2.5 需求获取的方法 （1）实地参加 （2) 开调查会 （3）请专人介绍 （4）面谈 （5）设计调查表请用户填写 （6）查阅记录 ;3.2.6 软件需求的表达 如何有效地表达软件需求？我们这里建议使用用例建模技术。用例建模技术是 10 多年来最重要的需求分析技术,在保障全球各类软件的成功开发中发挥了极其重要的作用. 实践证明,用例技术是迄今为止最为深刻,准确和有效的系统功能需求描述方法. 功能需求是指系统输入到输出的映射以及它们的不同组合,任何功能必然要通过外部环境与系统之间的交互才能完成,因此,我们可以在内容和形式上把用例和系统的功能需求等同起来。 用例建模技术不同于结构化功能分解的特点有： 1）显式地表达用户的任务目标层次，突出系统行为与用户利益间的关系； 2）通过描述执行实例情节（交互行为序列、正常/非正常事件流）能够完整地反映软件系统用以支持特定功能的行为； 3）以契约（前/后置条件等）的形式突出了用户和系统之间常常被忽略的背后的关系； 4）部署约束等非功能需求与系统行为直接绑定，能够更准确地表达此类需求。 ;基于用例的需求表达体系如下图3-2所示 基于用例的需求表达体系 ;1、用例图 （1）用例图概述 用例建模技术离不开用例图。在UML中，用例图又叫做用况图，有时又称为Use Case 图。它用于定义系统的行为、展示角色（系统的外部实体，即参入者）与用例（系统执行的服务）之间的相互作用。用例图是需求和系统行为设计的高层模型，它以图形化的方式描述外部实体对系统功能的感知。用例图从用户的角度来组织需求，每个用例描述一个特定的任务，如表3-2所示。 表3-2用例图概述 ;用例模型可以在不同层次上建立，具有不同的粒度。 （2）用例层次 我们把用例划分为3个目标层次:概要层,用户目标层和子功能层,并通过引入巧妙的Why/How技术帮助分析者找到合适的目标层次,从而可以有效地把握用例的粒度(真正的用例最终应落实到用户目标层)。 值得注意的是,我们在实践中应该尤其关注用户目标层用例.引入概要层用例的主要目的是为了包含一个或多个用户目标层用例,为系统提供全局功能视图,提出子功能层用例则是为了表达用户目标层用例的具体实现步骤。 （3）用例范围 根据范围的不同，用例可分为业务用例和系统用例两种 1）业务用例 -在业务中执行的一系列动作,这些动作为业务的个体主角产生具有可见价值的