系统需求建模.ppt

第四章系统需求建模 4.1调查系统需求 调查系统需求是系统分析的一个重要组成部分，包括明确功能需求和技术需求，访问系统相关者，建立原型并对调查结果和原型进行结构化遍历以及业务流程重组几个部分。 4.1.1 功能需求和技术需求 功能需求是系统必须完成的活动，也就是系统将要投入的业务应用。功能需求直接来自系统规划阶段确定的系统功能。 技术需求是指和企业的环境、硬件和软件有关的所有可操作目标。 对于新系统的完整定义，这两种类型的系统需求都是必不可少的，也都要包含在系统需求调查中。功能需求通常记载在已建立的分析模型中，而技术需求则通常记载在技术需求的叙述性描述里。 4.1.2 系统相关者 系统相关者可以分为四类： 1.用户，那些实际使用系统处理日常事务的人； 2.客户，即那些购买和拥有系统的人； 3.技术人员，确保系统运行在公司的计算机环境下的人； 4.外部实体，例如公司的顾客。 下图显示了对新系统感兴趣的各种系统相关者。 4.1.3 建立系统需求原型 传统的系统需求开发过程由四个步骤组成： 1.确定现有系统的物理过程和活动； 2.从现有物理过程中提取出业务逻辑功能； 3.为将在新系统中使用的方法开发出业务逻辑功能； 4.定义新系统的物理处理需求。 4.1.4 结构化遍历 所谓结构化遍历，简称遍历，是指对调查结果和根据这些结果建立的原型进行复查，这种遍历方法按过程进行，因此也称结构化遍历。 结构化遍历的目标是发现错误和问题，其基本思想是在理解系统基本需求的过程中建立需求文档，然后检查其中是否存在错漏之处。 4.1.5 业务流程重组 业务流程重组（Business Process Reengineering, BPR）是一种根本的战略思想，它将企业内部的处理过程流线化，并使之尽可能地高效运转，这种思想的主旨是：对基本方法提出质疑，从而发现一种能带来巨大和深刻的提高的全新方法。 4.2 模型 在系统分析阶段，系统分析员使用一组模型来充分描述管理信息系统的需求。一般来说，一个模型代表了当前系统的某些方面。不同类型的模型在不同层次上表现系统。 4.2.1 模型的作用及类型 在系统分析阶段进行系统建模主要具有以下作用： 1.有助于提取系统需求信息。由于系统本身的复杂性，使用模型可以在不同细节层次上来描述系统。 2.有助于系统分析员整理思路。建立模型的过程能帮助系统分析员澄清思路和改良设计。建模过程本身对系统分析员有直接的帮助。 3.有助于系统的分解和集成。管理信息系统往往是复杂的，在系统分析阶段对系统需求建模有助于问题的简化，并能够使系统分析员的精力一次只集中在系统的几个方面上。 4.有助于记忆和把握相关细节。系统分析需要收集和处理数量庞大的信息，规范通用的模型成为有效的帮助记忆的工具。 5.有助于系统开发小组以及小组成员之间进行交流。通用规范的模型是项目小组成员之间进行交流和协作的有效工具。 6、为未来的维护和升级提供文档参考。系统分析员建立的需求模型可以作为以后的开发小组在维护和升级系统时的文档，使以后的开发者能够继续使用。 模型分为三种类型： 数学模型 描述模型 图形模型 4.2.2逻辑模型和物理模型 逻辑模型：在系统分析阶段所建立的模型，详细定义了系统需求但并没有局限于某一具体技术。 物理模型：在系统设计阶段建立的一些模型，这些模型显示了如何使用具体技术来实现系统的某些方面。 常用的一些逻辑模型： 事件列表 数据流图 实体－联系图 数据流定义 数据元素定义 过程描述/结构化英语 类图 用例图 顺序图 协作图 状态图 常用的一些物理模型： 界面设计 报表设计 系统流程图 结构图 数据库设计 网络图 分布图 4.3 事件 所有的系统开发方法，不论是结构化方法还是面向对象方法，都是基于事件进行建模的。 4.3.1 事件的概念和类型 对于管理信息系统来说，事件是指与系统行为相关的，可以描述、值得记录的在某一特定时间和地点发生的事情。 系统分析中需要考虑的事件有三种类型： 外部事件 临时事件 状态事件 1.外部事件：外部事件是系统之外发生的事件，通常都是由外部实体或动作参与者触发的。外部实体或动作参与者可以是一个人或组织单位，它为系统提供数据或从系统获取数据。 2.临时事件：由于达到系统设定的某一时刻所发生的事件。和外部事件不同，临时事件是系统自动执行的，不需要外部实体或动作参与者的触发。 3.状态事件：当系统内部发生了需要处理的情况时所引发的事件。通常状态事件作为外部事件的结果而发生。有时，状态事件和临时事件相似，惟一不同的地方在于，状态事件无法定义事件发生的时刻。 4.3.2 定义事件 1.区分事件和触发事件的条件以及系统响应。 2.跟踪事务处理的生命