软件工程Chapter_4 需求工程.pptVIP

第四章 需求工程 (Requirements Engineering);软件项目失败的最重要的五个原因;需求错误的成本;软件需求的重要性;软件需求的重要性;?;内容提纲;4.1 软件需求;软件需求的不同层次;4.1.1 业务需求;案例：业务需求：MiniLibrary;客户与用户 学院的高层管理者 图书管理员 借阅者：教师、学生; 用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。;? 举例：; 系统需求是更加详细地描述系统应该做什么，通常包括许多不同的分析模型，如对象模型、数据模型、状态模型等。;功能需求 描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。;非功能需求;4.1.5非功能需求;4.1.5非功能需求;? 分析以下描述，它们是否属于需求？;软件需求的错误;4.2 需求工程;需求工程过程;内容提纲;4.2 需求获取技术;? 客户或用户;4.2 需求获取技术;需求获取-过程;4.2需求获取技术;4.2.1 用户面谈;面谈过程需要认真的计划和准备（续） 进行面谈 衣着得体，准时到达 寻找异常和错误情况 深入调查细节 详细记录 指出和记录下未回答条目和未解决问题 面谈之后 复查笔记的准确性、完整性和可理解性 把所收集的信息转化为适当的模型和文档 确定需要进一步澄清的问题域 适当的时候向参加会议的每一个人发一封感谢信;34;4.2.3 问卷调查;4.2.4现场考察;4.2.5 原型化方法;快速原型方法示意图;需求获取的文档;确定产品前景与项目范围;识别和描述项目相关者;问题描述;理解项目相关者的要求;理解项目相关者的要求;识别系统特性;知识回顾;内容提纲;4.3 需求分析与需求文档;需求分析的方法 1.结构化方法 2.面向对象的方法 ;1、结构化方法 ;1、结构化方法 基本思想：自顶向下，逐步求精。 两个基本原则：抽象与分解,上层对问题抽象、对模块抽象和对数据抽象，下层则进一步分解，进入另一个抽象层次。 特点： (1) 是使用最早的开发方法，使用时间也最长。 (2) 应用最广，特别适合于数据处理。 (3) 相应的支持工具多，发展较为成熟。;4.3.2 面向对象分析OOA;SRS应包含的主要内容 功能：软件应该提供什么功能？ 外部接口：软件如何与人、系统硬件和其他系统等进行相互作用？ 性能：软件系统在运行速度、可用性、响应时间、恢复时间等方面有什么要求？ 特性：软件系统在可移植性、可维护性、安全性等方面有什么考虑? 设计约束：是否存在必要的标准、开发语言、数据库、资源限制、运行环境等因素的影响和策略？ ;不应该包括在 SRS 中的内容 项目开发计划 产品保证计划 软件设计细节 ;编写需求规格说明的原则 原则 1：只描述“做什么”而无须描述“怎么做” 原则 2：必须说明运行环境 原则 3：考虑用户、分析员和实现者的交流 对形式化和自然语言之间作出恰当的选择 明确的理解最重要，不存在十全十美的软件规格说明书 原则 4：力求寻找到恰如其分的需求详细程度 一个有益的原则就是编写单个的可测试需求文档 ;编写需求规格说明的原则 原则 5：文档段落不宜太长 原则 6：避免使用模糊的、主观的术语 如用户友好、容易、简单、迅速、有效、许多、最新技术 建议：采用一种标准的 SRS 模板 ;SRS （IEEE 830－1998 ）;需求规格说明的质量特性： 正确性(Correctness) 需求规格说明对系统功能、行为、性能等的描述必须与用户的期望相吻合，代表了用户的真正需求。 审查需求的正确性应该考虑的问题 用户参与需求过程的程度如何？ 每一个需求描述是否准确地反映了用户的需要？ 系统用户是否已经认真考虑了每一项描述？ 需求可以追溯到来源吗？ 举例：下面的需求描述正确吗？ 在用户每次存钱的时候系统将进行信用检查。;需求规格说明的质量特性： 无二义性(unambiguous ) 需求规格说明中的描述对于所有人都只能有一种明确统一的解释。 审查需求的无二义性应该考虑的问题 需求规格说明是否有术语词汇表？ 具有多重含义或未知含义的术语是否已经定义？ 需求描述是否可量化和可验证？ 每一项需求都有测试准则吗？ 举例：下面的需求描述是无歧义的吗？ 如果用户试图透支，系统将采取适当的行动。 ;需求规格说明的质量特性： 完整性(completeness ) 需求规格说明应该包括软件要完成的全部任务，不能遗漏任何必要的需求信息。 ;需求规格说明的质量特性： 4. 可验证性(verifiability ) 需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认。 审查需求的可验证性应该考虑的问题 在需求文档中是否存