软件工程导论课件之第3章-需求分析(第五版)(张海藩编著).ppt

第3章软件需求分析 教学目的与要求 深刻理解需求分析阶段的概念及任务 熟练掌握ER图 HIOP图的画法 教学重点 需求分析阶段的任务 方法 具体任务 教学难点 写出需求规格说明书 第3章需求分析 3 1需求分析的任务3 2与用户沟通获取需求的方法3 3分析建模与规格说明3 4实体 联系图3 5数据规范化 3 6状态转换图3 7其他图形工具3 8验证软件需求3 9小结习题 成功来之不易 31 取消 16 2 成功地完成 53 8 受到挑战 Source StandishGroup 2 软件项目失败的原因 软件项目失败的最重要的五个原因 需求不完整 缺少客户的参与缺少资源 期望值过高 缺少高层的支持 0 5 10 15 3 需求错误的成本 4 5 软件需求的重要性 软件需求是决定软件开发是否成功的一个关键因素 需求分析可以帮助开发人员真正理解业务问题 需求分析是估算成本和进度的基础 需求分析可以避免建造错误的系统 从而减少不必要的浪费 软件需求的重要性 软件规格说明有助于开发人员与客户在 系统应该做什么 问题上达成正式契约 需求分析形成了软件开发的基线 有助于管理软件的演化和变更软件需求是软件质量的基础 为系统验收测试提供了标准 3 1需求分析的任务 什么是软件需求分析 将用户非形式的需求陈述转化为完整的需求定义 再由需求定义转换到相应的需求规格说明的过程 软件需求分析的重要性 软件需求分析是软件生存期决定性的一步 是软件开发的基础 分析员和用户 在分析软件需求和书写软件需求规格说明书的过程中 分析员和用户都起着关键的 必不可少的作用 3 1需求分析的任务 案例 小型图书资料管理系统问题描述 某学院打算开发一个小型图书资料管理系统MiniLibrary 该系统基于Internet实现教师和学生对各种图书资料的借阅 查询和管理 图书管理员负责管理各种图书资料 查询图书资料信息 并进行图书的借阅管理 注册用户可以通过Internet随时查询图书资料信息和个人借阅情况 预订目前借不到的图书资料 并可以快捷地查找和浏览所需要的电子资料 系统可以提供适当的浏览器供用户阅读电子文献资料 要求用户界面友好 响应速度快 具有良好的可扩展性 3 1需求分析的任务 软件需求分析的基本任务是准确地回答 系统必须做什么 3 1需求分析的任务 不同层次的软件需求 功能需求 非功能需求 业务需求 项目视图与范围文档 业务规则 用户需求 质量属性 用例文档 外部接口 系统需求功能需求 约束条件 软件需求规格说明 9 一 功能需求1 业务需求 业务需求是组织或客户对于系统的高层次目标要求 定义了项目的远景和范围 即确定软件产品的发展方向 功能范围 目标客户和价值来源 业务需求的内容 业务 产品属于哪类业务范畴 应该完成什么功能 需要为什么服务 客户 产品为谁服务 目标客户是谁 特性 产品区别于其他竞争产品的特性是什么 价值 产品的价值体现在什么方面 优先级 产品功能特性的优先级次序是什么 10 业务需求 MiniLibrary 业务要求 各种图书资料的借阅 查询和管理 使用计算机实现图书资料的日常管理 提高工作效率和服务质量 用户通过网络查询和浏览电子资料 改变原有的借阅模式 由于版权的限制 某些电子资料只能让用户浏览和打印而不能下载 客户与用户 学院的高层管理者 图书管理员 借阅者 教师 学生 11 2 用户需求 用户需求是从用户角度描述的系统功能需求和非功能需求 通常只涉及系统的外部行为 而不涉及系统的内部特性 用户需求的描述 原则 应该易于用户的理解 一般不采用技术性很强的语言 而是采用自然语言和直观图形相结合的方式进行描述 问题 自然语言表达容易含糊和不准确 12 用户需求 MiniLibrary 举例 用户可以通过Internet随时查询图书信息和个人借阅情况 并可以快捷地查找和浏览所需要的电子资料 分析 上述需求描述包含了三个不同的需求 用户可以通过Internet随时查询图书信息 用户可以通过Internet随时查询个人借阅情况 用户可以通过Internet快捷地查找和浏览所需要的电子资料 问题 随时 和 快捷 是对系统功能的约束 十分模糊 13 3 系统功能需求 功能需求 描述系统应该提供的功能或服务 通常涉及用户或外部系统与该系统之间的交互 一般不考虑系统的实现细节 举例 MiniLibrary 用户可以从图书资料库中查询或者选择其中的一个子集 系统可以提供适当的浏览器供用户阅读电子文献 用户每次借阅图书应该对应一个唯一的标识号 它被记录到用户的帐户上 15 二 非功能需求 非功能需求从各个角度对系统的约束和限制 反映了应用对软件系统质量和特性的额外要求 例如响应时间 数据精度 可靠性 开发过程的标准等 举例 MiniLibrary 系统应在20秒之内响应所有的请求 系统每周7天 每天24小时都可以使用 对于一个没有经验的用户而言 经过两个小时的培训就可以使用系统的所有功能 16 非功能需求 非功能需求 过程需求 产品需求 外部需求 软件交付实现方法标准 互操作性道德法规成本 可用性软件性能 存贮空间 可靠性 可移植性安全性 17 非功能需求 特性 度量指标 每秒处理的事务 速度 用户或事件的响应时间 屏幕的刷新时间 字节数 存贮空间 RAM芯片数 培训时间 可用性 帮助页面数 平均失败时间 可靠性 系统无效的概率 失败发生率 失败后的重启次数 容错性 事件引起失败的比例 失败时数据崩溃的可能性 18 系统需求 系统需求是更加详细地描述系统应该做什么 通常包括许多不同的分析模型 诸如对象模型 数据模型 状态模型等 系统需求模型的描述结构化英语 PDL 可视化模型 形式化方法 系统需求主要是面向开发人员进行描述 是开发人员进行软件设计的基础 14 需求的来源 客户或用户学院的高层管理者 项目投资人 系统管理员 教师 学生 图书管理员 标准图书资料的标准 政策或法律图书资料管理规程 知识产权和版权保护等 系统或过程文档 当前手工管理的文件 表格 记录等 相关领域的专家 19 3 1 1确定对系统的综合要求 1 功能需求这方面的需求指定系统必须提供的服务 通过需求分析应该划分出系统必须完成的所有功能 2 性能需求性能需求指定系统必须满足的定时约束或容量约束 通常包括速度 响应时间 信息量速率 主存容量 磁盘容量 等方面的需求 3 可靠性 可用性 安全性 保密性等需求要求定量地指定系统的可靠性 可用性 安全性 保密性等 思考题例 A银行长年开放100台ATM机 1000台用于商场酒店的POS机 B银行没有ATM和POS机只有10个每天8点上班17点下班的储蓄所 请问 A B银行的可靠性可用性各应如何设置 4 出错处理需求在某些情况下 出错处理 指的是当应用系统发现它自己犯下一个错误时所采取的行动 但是 应该有选择地提出这类出错处理需求 对应用系统本身错误的检测应该仅限于系统的关键部分 而且应该尽可能少 5 接口需求接口需求描述应用系统与它的环境通信的格式 常见的接口需求有 用户接口需求 硬件接口需求 软件接口需求 通信接口需求 6 约束常见的约束有 精度 工具和语言约束 设计约束 应该使用的标准 应该使用的硬件平台 7 用户界面需求 系统环境 多少台机器 机型等接口 8 系统可移植性 可维护性等方面的需求 9 将来可能提出的要求 这是软件需求分析的一个重要任务 软件系统经常使用各种长期保存的信息 为减少数据冗余 避免出现插入异常或删除异常 简化修改数据的过程 通常需要把数据结构规范化 见3 5节 3 1 3导出系统的逻辑模型在分析综合中逐步细化软件功能划分各子功能 对系统数据域进行分析 建立新系统的逻辑模型 系统图 数据流图 数据字典 E R图 UML模型图表示 常用方法是 面对结构化分析方法 SA 面向数据结构 JSP 方法 面向对象OOA方法 3 1 2分析系统的数据要求 3 1 4修正系统开发计划 3 1 4修正系统开发计划根据在分析过程中获得的对系统的更深入更具体的了解 可以比较准确地估计系统的成本和进度 修正以前制定的开发计划 3 2与用户沟通获取需求的方法需求获取的困难 用户通常并不真正知道自己希望计算机系统做什么用户通常使用业务语言表达需求 开发人员缺乏相关的领域知识和经验 难以准确理解这些需求 不同的用户提出不同的需求 可能存在矛盾和冲突管理者可能出于增加影响力的原因而提出特别的需求由于经济和业务环境的动态性 需求经常发生变更 补充 与用户沟通获取需求的方法 3 2与用户沟通获取需求的方法 需求获取的关键在于通过与用户的沟通和交流 收集和理解用户的各项要求 3 2 1访谈3 2 2面向数据流自顶向下求精3 2 3简易的应用规格说明技术3 2 4快速建立软件原型 1 访问用户和用户领域的专家 2 需求讨论会 3 问卷调查 4 现场考察 3 2 1访谈 获取需求的具体方法 3 3分析建模与规格说明 需求分析的步骤 用户面谈 用户面谈 一种理解商业功能和商业规则的最有效方法 面谈过程需要认真的计划和准备 面谈之前 确立面谈目的 确定要包括的相关用户 确定参加会议的项目小组成员 建立要讨论的问题和要点列表 复查有关文档和资料 确立时间和地点 通知所有参加者有关会议的目的 时间和地点 52 用户面谈 面谈过程需要认真的计划和准备 续 进行面谈 衣着得体 准时到达 寻找异常和错误情况 深入调查细节 详细记录 指出和记录下未回答条目和未解决问题 面谈之后 复查笔记的准确性 完整性和可理解性 把所收集的信息转化为适当的模型和文档 确定需要进一步澄清的问题域 适当的时候向参加会议的每一个人发一封感谢信 53 需求专题讨论会 需求专题讨论会 项目主要风险承担人在短暂而紧凑的时间段内集中在一起 一般为1至2天 与会者可以在应用需求上达成共识 对操作过程尽快取得统一意见 优点 协助建立一支高效的团队 围绕项目成功的目标 所有的风险承担人都畅所欲言 促进风险承担人和开发团队之间达成共识 揭露和解决那些妨碍项目成功的行政问题 能够很快地产生初步的系统定义 54 需求专题讨论会 专题讨论会准备 参加会议人员 主持人 用户 技术人员 项目组人员 安排日程 通常在具有相应支持设备的专用房间进行 举行会议 可能出现行政间的责备或冲突 主持人应掌握讨论气氛并控制会场 会议最重要的部分是自由讨论阶段 这种技术非常符合专题讨论会的气氛 并且营造一种创造性的和积极的氛围 同时可以获得所有相关者的意见 注意分配会议时间 记录所有言论 55 需求专题讨论会 56 问卷调查 问卷调查 可用于确认假设和收集统计倾向数据 问卷需要快速回答 允许匿名方式 存在问题 相关的问题不能事先决定 问题背后的假设对答案造成偏颇 如这符合你的期望吗 难以探索一些新领域 难以继续用户的模糊响应 在完成最初的面谈和分析后 可作为一项协作技术可以收到良好的效果 57 现场考察 现场观察商业过程和工作流程 掌握用户如何实际使用一个系统以及到底用户需要哪些信息 最好的办法是亲自观察用户是如何完成实际工作的 一般方法 对办公室进行快速浏览 了解布局 设备要求和使用 工作流总体情况 安排几个小时观察用户是如何实际完成他们的工作 理解用户实际使用计算机系统和处理事务的细节 像用户一样接受训练和做实际工作 发现关键问题和瓶颈 注意 观察可能使用户紧张 58 3 3 1分析建模1 问题识别双方确定对问题的综合需求 基于项目有关的软件的功能 性能 环境 用户界面 可靠性 安全性 保密性 可移植性 可维护性 等方面的需求 3 3分析建模与规格说明 需求分析的步骤 2 分析和综合导出软件的逻辑模型 2 分析和综合导出软件的逻辑模型1 分析人员对获取的需求进行一致的分析检查 逐步细化软件功能 划分各子功能 2 对系统数据域进行分解 分配到各子功能上 3 用图文结合的形式 建立新系统的逻辑模型和物理视图 物理视图指系统数据输入输出使用什么设备或方式 例键盘输入 数据扫描 数据传送等方式 3 3 2软件需求规格说明 3 3 2软件需求规格说明软件需求规格说明书 是需求分析阶段得出的最主要的文档 补充 需求分析阶段要编写文档 1 编写 需求规格说明书 2 编写初步用户手册3 编写 确认测试计划 为系统完成后确认验收的依据 4 修改完善软件开发计划需求规格说明书写法见实验指导书 3 4实体 联系图 E R图 应该包括在SRS 需求规格说明 中的内容 功能 软件应该提供什么功能 外部接口 软件如何与人 系统硬件和其他系统等进行相互作用 性能 软件系统在运行速度 可用性 响应时间 恢复时间等方面有什么要求 特性 软件系统在可移植性 可维护性 安全性等方面有什么考虑 设计约束 是否存在必要的标准 开发语言 数据库 资源限制 运行环境等因素的影响和策略 不应该包括在SRS中的内容 项目开发计划 如成本 人员 进度 工具 方法等 产品保证计划 如配置管理 验证与测试 质量保证等 软件设计细节 需求通常用于表达 做什么 而不描述 如何做 编写需求规格说明的原则 原则1 只描述 做什么 而无须描述 怎么做 原则2 必须说明运行环境原则3 考虑用户 分析员和实现者的交流 对形式化和自然语言之间作出恰当的选择 明确的理解最重要 不存在十全十美的软件规格说明书 编写需求规格说明的原则 原则4 力求寻找到恰如其分的需求详细程度 一个有益的原则就是编写单个的可测试需求文档 建议将可测试的需求作为衡量软件产品规模大小的尺度原则5 文档段落不宜太长简短 记住 不要在需求说明中使用 和 或 等等 之类的词原则6 避免使用模糊的 主观的术语 如用户友好 容易 简单 迅速 有效 许多 最新技术 优越的 可接受的 最大化 最小化 提高等 不可验证 建议 采用一种标准的SRS模板 需求工程 需求工程是应用已证实有效的原理和方法 并通过合适的工具和符号 系统地描述出待开发系统及其行为特征和相关约束 活动 持续进行的需求管理需求 需求获取 需求分析 需求验证 规格说明 工作产品 已确认的 需求规格 会议记录等 分析模型 需求规格 说明书 说明书 22 为了把用户的数据要求清楚 准确地描述出来 系统分析员通常建立一个概念性的数据模型 也称为信息模型 数据模型中包含3种相互关联的信息 数据对象 数据对象的属性及数据对象彼此间相互连接的关系 3 4 1数据对象3 4 2属性3 4 3联系3 4 4实体 联系图的符号通常 使用实体 联系图 entity relationshipdiagram 来建立数据模型 可以把实体 联系图简称为ER图 相应地可把用ER图描绘的数据模型称为ER模型 3 4实体 联系图 E R图 E R信息模型的设计 E R信息模型的设计E R方法是英文entity relationshipapproach的简称 译作实体一联系方法 此法通过E R图形表示信息世界中的实体 属性 关系的模型 1 E R图约定 实体用方框表示 联系用菱形框表示 框内填入相应的实体名 联系名及属性名 下图举了三个例子 表示了二个实体间的联系 而三个例子由三种不同的联系方法 三个例子 三个例子 表示了二个实体间的联系 而三个例子由三种不同的联系方法 第一种情况 第一种情况 是一对一的关系 一个工厂只有一个正厂长 第二种情况 是一对多的联系 一个仓库存放多种和多个产品 第三种情况 是多对多的联系 一个学生要学习多门课程 而一门课程又有多名学生学习 所以是多对多的联系 同时从图中也可看出联系也可能有属性 如存放有属性数量 学习有属性成绩等 2 如何设计E R图先画出局部E R图 再对局部E R加以综合 产生一个总体E R图 先画出局部E R图 再对局部E R加以综合 产生一个总体E R图 软件系统经常使用各种长期保存的信息 这些信息通常以一定方式组织并存储在数据库或文件中 为减少数据冗余 避免出现插入异常或删除异常 简化修改数据的过程 通常需要把数据结构规范化 下面给出第一 第二和第三范式的定义 1 第一范式在同一表中没有重复项出现 如果有则应将重复项去掉 每个属性值都必须是原子值 即仅仅是一个简单值而不含内部结构 3 5数据规范化 2 第二范式满足第一范式条件 2 第二范式满足第一范式条件 而且每个非关键字属性都由整个关键字决定 而不是由关键字的一部分来决定 每个表必须有一个 而且仅一个 数据元素为主关键字 其它元素与主关键字一一对应 3 第三范式符合第二范式的条件 每个非关键字属性都仅由关键字决定 而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述 即一个非关键字属性值不依赖于另一个非关键字属性值 表中的所有数据元素 不但要能够唯一地被主关键字所标识 而且它们之间还必须相互独立 不存在其它的函数关系 3 6状态转换图 根据本章开头讲的结构化分析的第3条准则 在需求分析过程中应该建立起软件系统的行为模型 状态转换图 简称为状态图 通过描绘系统的状态及引起系统状态转换的事件 来表示系统的行为 此外 状态图还指明了作为特定事件的结果系统将做哪些动作 例如 处理数据 因此 状态图提供了行为建模机制 可以满足第3条分析准则的要求 面向对象模型中介绍 3 6状态转换图 略 3 7其他图形工具 3 7其他图形工具3 7 1层次方框图 H图 层次方框图是用树形结构的一系列多层次的矩形框描绘数据的层次结构 树形结构的顶层是一个单独的矩形框 它代表完整的数据结构 下面的各层矩形框代表这个数据的子集 最底层的各个框代表组成这个数据的实际数据元素 不能再分割的元素 3 7 2Warnier图 图3 5层次方框图的一个例子 需求工程 需求工程是应用已证实有效的原理和方法 并通过合适的工具和符号 系统地描述出待开发系统及其行为特征和相关约束 活动 持续进行的需求管理需求 需求获取 需求分析 需求验证 规格说明 工作产品 已确认的 需求规格 会议记录等 分析模型 需求规格 说明书 说明书 22 1 一致性所有需求必须是一致的 任何一条需求不能和其他需求互相矛盾 2 完整性需求必须是完整的 规格说明书应该包括用户需要的每一个功能或性能 3 现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的 对硬件技术的进步可以做些预测 对软件技术的进步则很难做出预测 只能从现有技术水平出发判断需求的现实性 4 有效性必须证明需求是正确有效的 确实能解决用户面对的问题 3 8 2验证软件需求的方法 3 8验证软件需求3 8 1从哪些方面验证软件需求的正确性 1 验证需求的一致性 正确性当需求分析的结果是用自然语言书写的时候 除了靠人工技术审查验证软件系统规格说明书的正确性之外 目前还没有其他更好的 测试 方法 在目标系统规模庞大 规格说明书篇幅很长的时候 人工审查的效果是没有保证的 当软件需求规格说明书是用形式化的需求陈述语言书写的时候 可以用软件工具验证需求的一致性 2 验证需求的现实性分析员参照以往开发类似系统的经验 分析用现有的软 硬件技术实现目标系统的可能性 必要的时候应该采用仿真或性能模拟技术 辅助分析软件需求规格说明书的现实性 3 8 2验证软件需求的方法 3 验证需求的完整性和有效性 3 验证需求的完整性和有效性只有在用户的密切合作下才能完成 只有当用户有某种工作着的软件系统可以实际使用和评价时 才能完整确切地提出他们的需要 用户通过试用原型系统 也能获得许多宝贵的经验 从而可以提出更符合实际的要求 3 8 3用于需求分析的软件工具这类软件工具应该满足下列要求 1 必须有形式化的语法 或表 因此可以用计算机自动处理使用这种语法说明的内容 2 使用这个软件工具能够导出详细的文档 3 必须提供分析 测试 规格说明书的不一致性和冗余性的手段 并且应该能够产生一组报告指明对完整性分析的结果 4 使用这个软件工具之后 应该能够改进通信状况 理想的做法 下面的需求描述正确吗 在用户每次存钱的时候系统将进行信用检查 下面的需求描述是无歧义的吗 如果用户试图透支 系统将采取适当的行动 下面的两个需求描述中哪一个难以验证 系统将在20秒内响应所有有效的请求 如果用户试图透支 系统将采取适当的行动 下面的两个需求描述是否有矛盾 系统允许立即使用所存的资金 只有在手工验证所存资金后 系统才能允许使用 需求描述示例 举例如果可能的话 应当根据图书编号的列表在线确认所输入的图书编号 问题 如果可能的话 意味着什么 应当 是否精确 改正 系统必须根据在线的图书编号列表确认所输入的图书编号 如果在图书编号列表中查不到该图书的编号 或者当进行图书编号确认时图书编号列表不可访问 系统必须显示一个出错信息并且拒绝预订 需求描述示例 举例1 产品必须在固定的时间间隔内提供状态信息 并且每次时间间隔不得小于60秒 问题 上述需求描述有什么缺陷 如何改正 46 需求描述示例与改正 改正 后台任务管理器应该在用户界面的指定区域显示状态信息 1 在后台任务进程启动之后 消息必须每隔60 10秒更新一次 并且保持连续的可见性 2 如果正在正常处理后台任务进程 那么后台任务管理器必须显示后台任务进程已完成的百分比 3 当完成后台任务时 后台任务管理器必须显示一个 已完成 的信息 4 如果后台任务中止执行 那么后台任务管理器必须显示一个出错信息 47 传统软件工程方法学使用结构化分析技术 完成分析用户需求的工作 需求分析是发现 求精 建模 规格说明和复审的过程 第一步是进一步了解用户当前所处的情况 发现用户所面临的问题和对目标系统的基本需求 接下来应该与用户深入交流 对用户的基本需求反复细化逐步求精 以得出对目标系统的完整 准确和具体的需求 具体地说 应该确定系统必须具有的功能 性能 可靠性和可用性 必须实现的出错处理需求 接口需求和逆向需求 必须满足的约束条件 并且预测系统的发展前景 3 9小结 第3章软件需求分析 练习题 1 请举例说明使用自然语言描述用户需求和系统需求的问题 2 请指出下面需求