第3章需求分析

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

事件表达式的语法如下: 事件表达式的语法如下: 事件说明[守卫条件]/ 动作表达式 其中事件说明语法为:事件名(参数表) 守卫条件是一个布尔表达式,如果同时使用事 件说明和守卫条件,则当且仅当事件说明和守 卫条件为真时,状态转换才发生。如果只有守 卫条件没有事件说明,则只当守卫条件为真时, 状态转换才发生。
3.4 实体-联系图 为了把用户的数据要求清楚、准确地描述出 来,系统分析员通常建立一个概念数据模型 (也称为信息模型)。概念性数据模型是一种 面向问题的数据模型,是按照用户的观点对 数据建立的模型。它描述了从用户角度看到 的数据,它反映了用户的现实环境。 数据模型中包含3种相互关联的信息:数据 对象、数据对象的属性及数据对象间的联系。
活动表的语法格式如下: 活动表的语法格式如下: 事件名(参数表) 事件名(参数表)/动作表达式 其中,事迹名可以是任何事件的名称, 其中,事迹名可以是任何事件的名称,在活动 表中常使用3种标准事件 种标准事件: 表中常使用 种标准事件:entry\exit\do,而entry 而 事件表示进入该状态的动作, exit事件表示退出 事件表示进入该状态的动作, exit事件表示退出 该状态的动作, 事件表示在该状态下的动作 事件表示在该状态下的动作, 该状态的动作,do事件表示在该状态下的动作, 需要时可以为事迹指定参数表, 需要时可以为事迹指定参数表,活动表中的动 作表达式描述做的具体动作。 作表达式描述做的具体动作。它是一个过程表 达式,当状态转换开始时执行该表达式。 达式,当状态转换开始时执行该表达式。
3.2与用户沟通获取需求的方法 3.2与用户沟通获取需求的方法
1.客户访谈 访谈是最早开始使用的获取用户需求的一种方法,也 是最常用的一种方法。 访谈有两种基本形式,分别是正式和非正式的访谈。 当需要调查大量人员的意见时,请被调查人填写调查 表是十分有效的做法。 在访问用户的过程中使用情景分析技术往往非常有效, 所谓情景分析就是对用户将来使用目标系统解决某个 具体问题的方法和结果进行分析,系统分析员利用情 景分析技术,往往能够获知用户的具体需求。
3.6 状态转换图
状态转换图(状态图)通过描绘系统的状态及 系统的状态转换的事件,来表示系统的行为。 因此状态转换图建立系统的行为模型。 状态:状态是可以被观察到的系统行为模式, 状态 一个状态代表系统的一种行为模式。状态规定 了系统对事件的响应方式。 状态主要有处态 终态 处态、终态 中间状态。在一张 处态 终态、和中间状态 中间状态 图中只能有一个处态,而终态则可以有0至多 个。
2.面向数据流自顶向下求精 结构化分析方法就是面向数据流自顶向下逐步 分解求精,在可行性研究阶段描绘出了目标系 统的高层数据流图,但对数据考虑的不详,在这 个阶段必须细化。通常把分析过程中得到的数 据元素的信息记录在数据字典中,把对算法的 简明描述记录在IPO图中。 最后,分析员要对分析得出的结果即数据流图 请用户进行仔细复查。
系统性能要求—应就具体系统而定 , 系统性能要求 应就具体系统而定, 例如 应就具体系统而定 可靠性、联机系统的响应时间、存储容量、 可靠性、联机系统的响应时间、存储容量、安 全性能等。 全性能等。 系统可靠性和可用性要求—可靠性需求是 系统可靠性和可用性要求 可靠性需求是 定量地指定系统的可靠性。 定量地指定系统的可靠性。可用性和可靠性密 切相关,它量化了用户使用系统的程度。 切相关,它量化了用户使用系统的程度。 出错处理要求—这类需求说明系统对环境 出错处理要求 这类需求说明系统对环境 错误应该如何响应。 错误应该如何响应。 接口需求—接口需求描述系统与环境通信 2 接口需求 接口需求描述系统与环境通信 的格式,常见的接口有:用户接口需求、 的格式,常见的接口有:用户接口需求、硬件 接口需求、软件接口需求、通信接口需求。 接口需求、软件接口需求、通信接口需求。
产 品
硬 件
软 件
服 务
处 理机
存 储器
外部 设备
系统 软件
应用 软件
软件 服务
硬件 维修
培训
操作 系统
编译 程序
软件 工具
层次方框图的一个例子 注意:层次方框图即可以表示数据的层次结构, 注意:层次方框图即可以表示数据的层次结构,也可以表 示程序的层次结构
3.7.2Warnier 图
Warnier 图用树形结构描绘数据的层次结构。 它可以清楚地描绘信息的逻辑结构,可以表明 一个或一类信息元素是重复出现的,也可以是 特定信息在某一类信息中有条件出现的。因为 重复和条件约束是软件处理过程的基础,所以 很容易把Warnier 图转换成软件设计的工具。 例子:用 图描绘一类软件产品, 例子 用Warnier图描绘一类软件产品,它说明 图描绘一类软件产品 了这种图形工具的用法。 了这种图形工具的用法。
性别
职务 职务 教师 学号
姓名
性别

姓名
学生
年级
教 工 号 教
1 N
课程
N

成绩
M
课 程 号
课名
学时
学分
教师、学生及课程三者之间的ER图
3.5 数据规范化
规范化理论是数据库逻辑设计的指南和工具,那 么在概念设计阶段,也要用规范化理论为工具消 除E-R图中冗余的联系。数据库中用“范式”来 定义消除数据冗余的程度。分为5个范式。第一 范式数据冗余程度最大,第五范式数据冗余程度 最小,但是范式级别越高,存储自身的过程的越 复杂。第二,随着范式级别的提高,数据的存储 结构与基于问题域的结构间匹配程度也随之下降, 所以当需求发生变化时数据的稳定性就差。第三, 范式级别越高需要访问的数据表越多,访问速度 就越低。从实用来说,一般选用第三范式比较恰 当。
状态图既可以表示系统的循环运行过程,也可 以是系统的单程生命期 。 事件: 事件:在特定时刻发生的事情,它是对引起系 统做动作或从一个状态转换到另一个状态的外 界事迹的抽象。 状态图中符号 在状态图中,处态用实心圆表示,终态用同心圆 (内圆用实心圆)表示,中间状态用圆角矩形表 示,可以用两条水平横线把它分成上、中、下3 个部分,分别放置状态名、状态变量的名字和值 和活动表。其中,状态变量和活动表是可选的。
3、导出系统的逻辑模型 通常系统的逻辑模型 导出系统的逻辑模型—通常系统的逻辑模型 DFD图来描述 图来描述。 用DFD图来描述。 4、修正系统的开发计划 通过需求对系统的成 修正系统的开发计划—通过需求对系统的成 本及进度有了更精确的估算, 本及进度有了更精确的估算,可进一步修改开 发计划。 发计划。
2、分析系统的数据要求 软件系统本质上是信息处理系统,因此, 软件系统本质上是信息处理系统,因此, 必须分析系统的数据要求, 必须分析系统的数据要求,这是软件需求分析的 一个重要任务。 一个重要任务。分析系统的数据要求通常采用建 立数据模型的方法。必须考虑: 立数据模型的方法。必须考虑: 数据 (需要哪些数据、数据间联系、数据性 需要哪些数据、数据间联系、 结构) 质、结构) 处理的类型、处理的逻辑功能) 数据处理 (处理的类型、处理的逻辑功能)
第三 章
软件需求分析
软件需求分析是软件生命期中重要的一步, 软件需求分析是软件生命期中重要的一步 , 也 是决定性的一步。 是决定性的一步 。 它的基本任务是准确地回答 “系统必须做什么?”。 系统必须做什么?
软件需求分析是在可行性的基础上进行的更细致 的分析工作, 的分析工作,是对软件计划阶段所确定的系统目 标和功能做进一步的求精和细化。 标和功能做进一步的求精和细化。对目标系统提 出完整、准确、清晰、具体的要求。 出完整、准确、清晰、具体的要求。在可行性阶 段的文档是系统需求分析的出发点。 段的文档是系统需求分析的出发点。在需求分析 阶段分析员必须仔细研究这些文档并将它们细化。 阶段分析员必须仔细研究这些文档并将它们细化。
约束—描述在设计或实现应用系统时应遵守的 约束 描述在设计或实现应用系统时应遵守的 限制条件, 限制条件,常见的约束有精度 、工具和语言约 使用的标准、使用的硬件平台。 束、使用的标准、使用的硬件平台。 逆向需求—逆向需求说明软件系统不应该做什么 逆向需求 逆向需求说明软件系统不应该做什么 需求。 需求。 将来可能提出的要求—对将来可能提出的扩充及 将来可能提出的要求 对将来可能提出的扩充及 修改作预准备。 修改作预准备。
图3.1 面向数据流自顶向下求精过程
简易的应用规格说明技术( 3. 简易的应用规格说明技术 ( 面向团队的需求 收集法) 收集法) 使用前两种方法定义需求时并不理想。因此,人 们提出一种简易的应用规格说明技术,它是一 种面向团对的需求收集间技术。这种方法提倡 用户与开发者密切合作,共同标识问题,提出 解决方案,商讨不同的方案并指定基本需求, 目前,这种技术已经成为信息系统领域使用的 主流技术
•数据对象(实体): 客观世界中存在的且可区 数据对象(实体) 数据对象 分的事物。 • 联系 客观事物之间的联系(三类--1:1,1: 联系: N,M:N) • 属性: 实体或联系所具有的性质。 属性
实体实体-联系图的符号 用矩形框代表实体,用连接相关实体的菱形框 表示关系,用椭圆形或圆角矩形表示实体的属 性。并直线把实体或联系与其属性连接起来。
3.3.2 软件需求规格说明
通过需求分析除了创建分析模型之外,还应该 写出软件需求规格说明书,它是需求分析阶段 得出的最主要的文档。 通常用自然语言完整、准确、具体地描述系统 的数据要求、功能需求、性能需求、可靠性和 可用性要求、出错处理需求、接口需求、约束、 逆向需求以及将来可能提出的要求。自然语言 的规格说明具有容易书写、容易理解的优点, 为大多数人所欢迎和采用。
4.快速建立软件原型 快速原型就是快速建立起旨在演示目标系统主 要功能的可运行程序。它是最准确、最有效、 最强大的需求分析技术。 构建软件原型的要点是,应该实现用户看得见 的功能,省略目标系统的隐含功能。 快速软件原型的特点应该是:一是快速,二是 容易修改。
3.3 分析建模与规格说明 3.3.1 分析建模 结构化分析实质上是一种创建模型的活动。 为了开发出复杂的软件系统,系统分析员应 该从不同角度抽象出目标系统的特性,使用 精确的表示方法构造系统的模型,验证模型 是否满足用户对目标系统的需求,并在设计 过程中逐渐把和实现有关的细节加进模型中, 直至最终用程序实现模型。 根据本章开头讲述的结构化分析准则,需求 分析过程应该建立3种模型,它们分别是数 据模型、功能模型和行为模型。
下图给出了状态图中使用的主要符号
实例: 实例:
为了具体说明怎样用状态图建立系统的行为模 型,下面举一个人们非常熟悉的电话系统的状 态图例子。见书57页图 页图3.4 态图例子。见书 页图
• 状态图中使用的主要符号
3.7其它图形工具 3.7其它图形工具 3.7.1层次方框图: 层次方框图: 层次方框图 层次方框图是用树形结构的一系列多层次的矩 形框描绘数据的层次结构。数形结构的顶层是 一个单独的矩形框,它代表一个完整的数据结 构,下面各层矩形框代表这个数据的组成部分, 最低层的各个框代表组成这个数据的实际数据 元素。 例如:描绘一个计算机公司全部产品的数据结 构可以用下图表示:
3.1 需求分析的任务 需求分析阶段的任务:在可行性分析的基础上, 需求分析阶段的任务:在可行性分析的基础上, 进一步了解确定用户需求。 进一步了解确定用户需求。准确地回答 “系统必 须做什么? 的问题。 须做什么?” 的问题。对目标系统提出完整、准 确、清晰、具体的要求。获得需求规格说明书。 获得需求规格说明书 获得需求规格说明书。 需求分析的具体任务: 需求分析的具体任务: 1、确定系统的综合要求 系统功能要求—这是最主要的需求, 系统功能要求 这是最主要的需求,确定系 这是最主要的需求 统必须完成的所有功能。 统必须完成的所有功能。
需求分析的原则: •1.必须能够理解和表达问题的数据域,根据这 条准则应该建立数据模型 数据模型。 数据模型 •2.必须定义软件应该完成的功能根据这条准则 功能模型。 应该建Leabharlann Baidu功能模型 功能模型 3.必须描述作为外部事件结果的软件行为,根 据这条准则应该建行为模型 行为模型。 行为模型 4.必须对数据、功能和行为的模型进行分解和 不断细化,建立问题的层次结构 。 层次结构
相关文档
最新文档