《软件工程 需求工程ppt课件》由会员分享，可在线阅读，更多相关《软件工程 需求工程ppt课件（62页珍藏版）》请在金锄头文库上搜索。
1、需求工程 Requirement Engineering结构化方法自顶向下、逐层分解示意图S S1 12 23 32.12.12.22.22.32.33.13.13.23.23.33.33.43.4工资 发放工资 汇总工资 计算取款工资 分配职 工总 务人 事工资费用 分配表工资条现金现金工资条工资发放表工资册工资汇总表统筹医疗费 房租费 水电费 托儿费工资调整表 调入人员工资单 调出人员调出单 病事假扣款单开户银行工资处理数据流程图需求分析的任务 确定对系统的综合要求 分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划 需求分析是软件生存周期中计划阶段的最后一 个步骤软 件 计 划需
2、求 分 析费用、进度、资 源软件范围技术规格系 统 定 义硬件功能软件功能事业需要 确定对系统的综合要求 1. 功能需求 指定系统必须提供的服务。需求分析应该划分出 系统必须完成的所有功能。 2. 性能需求 性能需求指定系统必须满足的定时约束或容量约 束，通常包括速度(响应时间)、信息量速率、主 存容量、磁盘容量、安全性等方面的需求。 3. 可靠性和可用性需求 可靠性需求定量地指定系统的可靠性。 可用性与可靠性密切相关，它量化了用户可以使 用系统的程度。 4. 出错处理需求 说明系统对环境错误应该怎样响应。 5. 接口需求 接口需求描述应用系统与它的环境通信的格式。 常见的接口需求有：用户接口
3、需求；硬件接口需 求；软件接口需求；通信接口需求。 6. 约束 设计约束或实现约束描述在设计或实现应用系统 时应遵守的限制条件。 常见的约束有：精度；工具和语言约束；设计约 束；应该使用的标准；应该使用的硬件平台。 7. 逆向需求 逆向需求说明软件系统不应该做什么。 8. 将来可能提出的要求 应该明确地列出那些虽然不属于当前系统开发范 畴，但是据分析将来很可能会提出来的要求。 分析系统的数据要求 任何一个软件系统本质上都是信息处理系统 分析系统的数据要求通常采用建立数据模型 的方法 复杂的数据由许多基本的数据元素组成，数 据结构表示数据元素之间的逻辑关系。 利用图形工具辅助描绘数据结构，常用的
4、图 形工具有层次方框图和Warnier图 数据结构规范化 导出系统的逻辑模型 综合上述两项分析的结果可以导出系统的详 细的逻辑模型，通常用数据流图、实体-联 系图、状态转换图、数据字典和主要的处理 算法描述这个逻辑模型。 修正系统开发计划 根据在分析过程中获得的对系统的更深入更 具体的了解，可以比较准确地估计系统的成 本和进度，修正以前制定的开发计划。与用户沟通获取需求的方法 访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型 问问题的人是五分钟傻瓜，而不问问题 的人将永远是傻瓜。 事实不会因为被忽略而停止存在。 访谈 正式访谈时，系统分析员将提出一些事先准备好的 具体问题
5、。 在非正式访谈中，分析员将提出一些用户可以自由 回答的开放性问题，以鼓励被访问人员说出自己的 想法。 当需要调查大量人员的意见时，向被调查人分发调 查表是一个十分有效的做法。分析员仔细阅读收回 的调查表，然后再有针对性地访问一些用户，以便 向他们询问在分析调查表时发现的新问题。 在访问用户的过程中使用情景分析技术往往非常有 效。所谓情景分析就是对用户将来使用目标系统解 决某个具体问题的方法和结果进行分析。 情景分析技术的用处主要体现在下述两 个方面： (1) 它能在某种程度上演示目标系统的行为 ，从而便于用户理解，而且还可能进一步揭 示出一些分析员目前还不知道的需求。 (2) 由于情景分析较
6、易为用户所理解，使用 这种技术能保证用户在需求分析过程中始终 扮演一个积极主动的角色。 面向数据流自顶向下求精 软件系统本质上是信息处理系统，而任何信 息处理系统的基本功能都是把输入数据转变 成需要的输出信息。数据决定了需要的处理 和算法。 结构化分析方法就是面向数据流自顶向下逐 步求精进行需求分析的方法。通过可行性研 究已经得出了目标系统的高层数据流图，需 求分析的目标之一就是把数据流和数据存储 定义到元素级。 必须请用户对上述分析过程中得出的结 果仔细地复查，数据流图是帮助复查的 极好工具。 从输入端开始，分析员借助数据流图、数据 字典和IPO图向用户解释输入数据是怎样一 步一步地转变成输
7、出数据的。 反复进行上述分析过程，分析员越来越深入地 定义了系统中的数据和系统应该完成的功能。 为了追踪更详细的数据流，分析员应该把数据 流图扩展到更低的层次。通过功能分解可以完 成数据流图的细化。 随着分析过程的进展，经过问题和解答的反复 循环，分析员越来越深入具体地定义了目标系 统，最终得到对系统数据和功能要求的满意了 解。图3.1粗略地概括了上述分析过程。图3.1 面向数据流自顶向下求精过程简易的应用规格说明技术 使用传统的访谈或面向数据流自顶向下 求精方法定义需求时，用户处于被动地 位而且往往有意无意地与开发者区分“彼 此”。 简易的应用规格说明技术提倡用户与开 发者密切合作，共同标识
8、问题，提出解 决方案要素，商讨不同方案并指定基本 需求。 今天，简易的应用规格说明技术已经成 为信息系统领域使用的主流技术。必要的会议 会议开始后，讨论的第一个问题是，是 否需要这个新产品，一旦大家都同意确 实需要这个新产品，每位与会者就应该 把他们在会前准备好的列表展示出来供 大家讨论。 可以把这些列表抄写在大纸上钉在墙上 ，或者写在白板上挂在墙上。理想的情 况是，表中每一项都能单独移动，这样 就能方便地删除或增添表项，或组合不 同的列表。快速建立软件原型 快速建立软件原型是最准确、最有效、最强大 的需求分析技术。 快速原型就是快速建立起来的旨在演示目标系 统主要功能的可运行的程序。 构建原
9、型的要点是，它应该实现用户看得见的 功能(例如，屏幕显示或打印报表)，省略目标 系统的“隐含”功能(例如，修改文件)。 快速原型应该具备的第一个特性是“快速”。 快速原型应该具备的第二个特性是“容易修改” 。 在实际开发软件产品时，原型的“修改试用 反馈”过程可能重复多遍 为了快速地构建和修改原型，通常使用下述3 种方法和工具： (1) 第四代技术 第四代技术包括众多数据库查询和报表语言、程序和应用 系统生成器以及其他非常高级的非过程语言。 (2) 可重用的软件构件 另外一种快速构建原型的方法，是使用一组已有的软件构 件(也称为组件)来装配(而不是从头构造)原型。 (3)形式化规格说明和原型环
10、境 形式化语言的倡导者正在开发交互式环境，以便可以调用 自动工具把基于形式语言的规格说明翻译成可执行的程序 代码，用户能够使用可执行的原型代码去进一步精化形式 化的规格说明。分析建模与规格说明 分析建模 软件需求规格说明 分析建模 模型，就是为了理解事物而对事物做出的一 种抽象，是对事物的一种无歧义的书面描述 。通常，模型由一组图形符号和组织这些符 号的规则组成。 结构化分析实质上是一种创建模型的活动。 需求分析过程应该建立3种模型，它们分别 是数据模型、功能模型和行为模型。 实体-联系图，描绘数据对象及数据对象之间的 关系，是用于建立数据模型的图形。 数据流图，描绘当数据在软件系统中移动时被
11、 变换的逻辑过程，指明系统具有的变换数据的 功能，因此，数据流图是建立功能模型的基础 。 状态转换图(简称为状态图)，指明了作为外部 事件结果的系统行为。为此，状态转换图描绘 了系统的各种行为模式(称为“状态”)和在不同 状态间转换的方式。状态转换图是行为建模的 基础。 软件需求规格说明(SRS,Software Requirement Specification) 通过需求分析除了创建分析模型之外，还应该写出 软件需求规格说明书，它是需求分析阶段得出的最 主要的文档。 通常用自然语言完整、准确、具体地描述系统的数 据要求、功能需求、性能需求、可靠性和可用性要 求、出错处理需求、接口需求、约束
12、、逆向需求以 及将来可能提出的要求。 为了消除用自然语言书写的软件需求规格说明书中 可能存在的不一致、歧义、含糊、不完整及抽象层 次混乱等问题，有些人主张用形式化方法描述用户 对软件系统的需求。3.4实体-联系图 概念性数据模型是一种面向问题的数据模型， 是按照用户的观点对数据建立的模型。 它描述了从用户角度看到的数据，它反映了用 户的现实环境，而且与在软件系统中的实现方 法无关。 数据模型中包含3种相互关联的信息： 数据对象 数据对象的属性 数据对象彼此间相互连接的关系 数据对象 数据对象是对软件必须理解的复合信息的抽象。 所谓复合信息是指具有一系列不同性质或属性的事物，仅 有单个值的事物(
13、例如，宽度)不是数据对象。 数据对象可以是外部实体(例如，产生或使用信息的 任何事物)、事物(例如，报表)、行为(例如，打电话 )、事件(例如，响警报)、角色(例如，教师、学生) 、单位(例如，会计科)、地点(例如，仓库)或结构( 例如，文件)等。 总之，可以由一组属性来定义的实体都可以被认为 是数据对象。 数据对象彼此间是有关联的 数据对象只封装了数据而没有对施加于数据上的操 作的引用 属性 属性定义了数据对象的性质。 必须把一个或多个属性定义为“标识符” 应该根据对所要解决的问题的理解，来确定 特定数据对象的一组合适的属性。 联系 联系可分为以下3种类型： (1) 一对一联系(11) (2
14、) 一对多联系(1N) (3)多对多联系(N:N)图3.2 某校教学管理ER图 实体-联系图的符号 矩形框代表实体 用连接相关实体的菱形框表示关系 用椭圆形或圆角矩形表示实体(或关系)的属 性 并用直线把实体(或关系)与其属性连接起来 。3.5数据规范化 为减少数据冗余，避免出现插入异常或删除异常，简 化修改数据的过程，通常需要把数据结构规范化。 通常用“范式(normal forms)”定义消除数据冗余的程度 。 第一范式(1 NF)数据冗余程度最大，第五范式(5 NF)数 据冗余程度最小。 范式级别越高，存储同样数据就需要分解成更多张表 ，因此，“存储自身”的过程也就越复杂。 第二，随着范
15、式级别的提高，数据的存储结构与基于 问题域的结构间的匹配程度也随之下降，因此，在需 求变化时数据的稳定性较差。 第三，范式级别提高则需要访问的表增多，因此性能( 速度)将下降。从实用角度看来，在大多数场合选用第 三范式都比较恰当。范式 通常按照属性间的依赖情况区分规范化的程度 。属性间依赖情况满足不同程度要求的为不同 范式，满足最低要求的是第一范式，在第一范 式中再进一步满足一些要求的为第二范式，其 余依此类推。 (1) 第一范式每个属性值都必须是原子值，即 仅仅是一个简单值而不含内部结构。 (2) 第二范式满足第一范式条件，而且每个非 关键字属性都由整个关键字决定(而不是由关键 字的一部分来决定)。 (3) 第三范式符合第二范式的条件，每个 非关键字属性都仅由关键字决定，而且 一个非关键字属性不能仅仅是对另一个 非关键字属性的进一步描述(即一个非关 键字属性值不依赖于另一个非关键字属 性值)。状态转换图 状态转换图(简称为状态图)通过描绘系统 的状态及引起系统状态转换的事件，来 表示系统的行为。 状态图还指明了作为特定事件的结果系 统将做哪些动作(例如，处理数据)。 状态图提供了行为建模机制，可以满足 第3条分析准则的要求。 状态转换图包含： 状态 事件 符号表示 状态 状态是任何可以被观察到的系统行为模式，一个状 态代表系统的一种行为模式
