本讲的主要内容 软件需求分析的意义 需求分析的步骤 需求规格说明书SRS 需求分析方法学 结构化分析方法
本讲的主要内容 • 软件需求分析的意义 • 需求分析的步骤 • 需求规格说明书SRS • 需求分析方法学 • 结构化分析方法
需求( Requirements) 定义:需求是关于系统将要完成什么工作 (what)的一段描述语句,它们必须经过所 有相关人员的认可,其目的是彻底解决客 户的问题。 需求是指用户或者客户对要开发的软件 系统的要求。需求的内容在“问题定义” 中描述(可能是招标文件)
需求（Requirements) • 定义:需求是关于系统将要完成什么工作 (what)的一段描述语句,它们必须经过所 有相关人员的认可,其目的是彻底解决客 户的问题。 • 需求是指用户或者客户对要开发的软件 系统的要求。需求的内容在“问题定义” 中描述（可能是招标文件）
软件需求的类型 功能需求 系统可以完成的所有事情 涉及与本系统有接口的其他系统的所有事情 非功能需求 是软件开发过程中必须遵守的约束( Constraint) 是对可以使用的资源和软件质量的各个方面的限 制,往往会影响软件工程师做决策的自由度。 非功能需求应是可验证的( Verifiable)
软件需求的类型 • 功能需求 – 系统可以完成的所有事情 – 涉及与本系统有接口的其他系统的所有事情 • 非功能需求 – 是软件开发过程中必须遵守的约束（Constraint)。 是对可以使用的资源和软件质量的各个方面的限 制，往往会影响软件工程师做决策的自由度。 – 非功能需求应是可验证的（Verifiable)
非功能需求 目性能 实时性、精确度、资源利用率等 标可靠性 有效性、完整性 系 统安全/保密性 安全性、保密性 的 限运行限制 使用频度、运行期限、控制方式、操作要求 制物理限制 系统规模等限制 开开发类型 实用性开发、试验性开发 发和维 开发工作量的估计 护开发方法 质量控制标准、里程碑和评审、验收标准 的优先性和可修改性 限 制可维护性
非功能需求 目 标 系 统 的 限 制 性能 实时性、精确度、资源利用率等 可靠性 有效性、完整性 安全/保密性 安全性、保密性 运行限制 使用频度、运行期限、控制方式、操作要求 物理限制 系统规模等限制 开 发 和 维 护 的 限 制 开发类型 实用性开发、试验性开发 开发工作量的估计 开发方法 质量控制标准、里程碑和评审、验收标准 优先性和可修改性 可维护性
需求分析( Requirements analysis 指开发人员为了准确地理解和表达用户要求,进 行细致的调查分析,将用户非形式的需求陈述转 化为完整的需求定义,再由需求定义转换到相应 的形式功能规约(需求规格说明)的过程。 准确地回答“系统必须做什么?” Requirements analysis results in the specification of softwares operational characteristics; indicates softwares interface with other system elements; and esta blishes constraints that software must meet
需求分析(Requirements Analysis) • 指开发人员为了准确地理解和表达用户要求，进 行细致的调查分析，将用户非形式的需求陈述转 化为完整的需求定义，再由需求定义转换到相应 的形式功能规约（需求规格说明）的过程。 • 准确地回答“系统必须做什么？” • Requirements analysis results in the specification of software’s operational characteristics；indicates software’s interface with other system elements; and establishes constraints that software must meet
需求分析的意义 有关软件错误和需求分析的一组事实 在软件生命周期中,一个错误发现得越晚,修复 的费用也越高。 许多错误是潜伏的,并且在错误产生后很长一段 时间才被检查出来 在需求过程中会产生很多错误和误解,人与人之 间的“通信”障碍无法避免。 需求阶段代表性的错误:疏忽、不一致、二义性。 需求错误是可以被检查和审查出来的
需求分析的意义 • 有关软件错误和需求分析的一组事实 – 在软件生命周期中，一个错误发现得越晚，修复 的费用也越高。 – 许多错误是潜伏的，并且在错误产生后很长一段 时间才被检查出来。 – 在需求过程中会产生很多错误和误解，人与人之 间的“通信”障碍无法避免。 – 需求阶段代表性的错误：疏忽、不一致、二义性。 – 需求错误是可以被检查和审查出来的
篇的級感 问题域与解空间 现实世界中系统处理的业务范围 问题空间,它是人们利用认识现实世界和描述现实 问题的方法所描述的。它与“解空间”的概念相对 应,软件工程应该是问题空间和解空间一致 系统责任 所开发的系统应该具备的职能 系统边界 开发出的系统和与该系统打交道的人或物之间的明 确边界
需求的相关概念 • 问题域与解空间 – 现实世界中系统处理的业务范围。 – 问题空间，它是人们利用认识现实世界和描述现实 问题的方法所描述的。它与“解空间”的概念相对 应，软件工程应该是问题空间和解空间一致 • 系统责任 – 所开发的系统应该具备的职能。 • 系统边界 – 开发出的系统和与该系统打交道的人或物之间的明 确边界
领域分析( Domain Analysis Technical literature Class taxonomies Sources of Existing applications Reuse standards Domain Customer surveys Domain Domain Analysis Functional models Analysis Knowledge Expert ad vice Model Domain languages Current/future requirements
领域分析（Domain Analysis) Domain Analysis Sources of Domain Knowledge Domain Analysis Model Technical literature Existing applications Customer surveys Expert advice Current/future requirements Class taxonomies Reuse standards Functional models Domain languages
需求过程中可能的参与者 合同监督人员,提出里程碑( Milestones)和约 束系统开发进度的计划 需求者,客户( Customer)和使用者(User) 开发者 项目管理者,必须理解建立和使用目标系统所可 能产生的后果。 系统分析员——分析阶段活动的主体。 设计员——依据需求提出可接受的解决方案。 测试员——确保软件系统满足每一需求
需求过程中可能的参与者 • 合同监督人员，提出里程碑（Milestones）和约 束系统开发进度的计划 • 需求者，客户(Customer)和使用者(User)。 • 开发者 – 项目管理者，必须理解建立和使用目标系统所可 能产生的后果。 – 系统分析员——分析阶段活动的主体。 – 设计员——依据需求提出可接受的解决方案。 – 测试员——确保软件系统满足每一需求
系统分析员应具有的素质 综合能力 总体规划,抽象和分解,本质确认的能力 过程 保证整个过程的善始善终的能力 交流 理解和表达能力 技术 了解问题域和描述解空间的能力
系统分析员应具有的素质 • 综合能力 – 总体规划，抽象和分解，本质确认的能力 • 过程 – 保证整个过程的善始善终的能力 • 交流 – 理解和表达能力 • 技术 – 了解问题域和描述解空间的能力