软件工程 第3章 需求工程.pptVIP

复旦大学计算机科学与工程系 软件工程课程 软件工程 第3章 需求工程 需求:成功的软件开发的前提 软件质量= 系统所实现的需求/客户所期望的需求 需求的定义 IEEE Standard Glossary of Software Engineering Terminology 用户解决一个问题或达到一个目标所需要的一种状况或能力 系统为了满足一种约定、标准、规格说明或其它正式文件而必须满足或拥有的一种状况或能力 以上两种状态或能力的文档化表示 功能性需求和非功能性需求 功能性需求 系统需要提供的服务或功能：如图书检索 系统对特定输入的处理方式：如对非法输入的提示 系统在特定环境下的行为：如长时间无操作时的屏保 非功能性需求 对系统功能或服务附加的质量约束，例如响应时间、容错性、安全性等——客户所关心的(外部质量) 从系统开发和维护角度出发的质量属性，例如可理解性、可扩展性、可配置性等——软件开发或维护者所关心的(内部质量、软件所特有) 内容摘要 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 内容摘要 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动” (强调做什么) Herb Krasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理 Matthias Jarke和Klaus Pohl提出了三阶段周期的说法：获取、表示和验证 … … 需求工程的六个阶段 需求获取：资料收集 需求分析与协商：理解分析整理 系统建模：用模型描述(写下来) 需求规约：完善需求文档并定稿 需求验证：验证确认 需求管理：整体规划及变更管理 需求获取 系统分析人员通过与用户的交流，了解业务现状以及对待开发系统的期望 确定系统或产品范围的限制性描述 与系统或产品有关的人员及特征列表 系统的技术环境的描述 系统功能的列表及应用于每个需求的领域限制 一组描述不同运行条件下的应用场景以及为更好地定义需求而开发的系统原型 需求获取收集的“原始材料”为进行需求分析提供了基础 需求分析与协商 对需求进行分类组织，分析需求之间的关系 检查需求的一致性、重叠和遗漏的情况 根据用户的需要对需求进行排序。 在需求获取阶段，经常出现以下问题： 提出的要求超出软件系统可以实现的范围或实现能力 不同的用户提出了相互冲突的需求 系统建模 建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁 系统分析人员借助建模技术对获取的需求信息进行分析和表达，排除错误和弥补不足，确保需求文档正确反映用户真实意图 常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法 需求规约(Specification) 通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求 软件需求规约是分析任务的最终产物 需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用 需求验证 需求开发阶段工作的复查手段 对功能的正确性、完整性和清晰性，以及其它需求给予评价 为保证软件需求定义的质量，评审应以专门指定的人员负责(应该是需求分析人员之外的其他人员)，并按规程严格进行 需求确认与需求分析 二者密切相关 都需要对系统需求中的遗漏和冲突进行识别和分析 区别 需求分析处理的是未整理的原始需求，此时发现的问题是客户的问题 需求确认的对象是经分析后形成的需求规格说明，此时发现的问题是需求分析人员的问题，此外还需要考虑需求文档是否满足相应的质量标准 在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。 需求管理 一种获取、组织并记录系统需求的系统化方案：对所有需求工程相关活动的规划和总体控制 需求变更管理：一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程(变更的记录、分析、变更过程管理、追踪等) 回顾：需求的各种形式 从高度抽象的系统服务或系统目标到对某一系统功能的精确约束 原始需求 客户对软件系统及新的工作方式的期望目标 客户单位已经存在的日常工作方式和业务规则 系统所属领域固有的法规、标准或惯例等 一般目标：更快、更好、更安全 需求文档 自然语言描述 UML图等图形表示 业务规则表格 内容摘要 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 需求获取 缺少用户参与是项目失败的主要原因之一 良好的开端是成功的一半 需求获取：通过客户调研等手段对需求进行收集、分析、细化、核实和组织 两