软件工程之 需求获取PPT课件

第5章需求获取 第五章需求获取 5 1软件需求的定义5 2软件需求的类型5 3需求获取5 4需求规格说明书5 5需求验证5 6需求变更 教学目的与要求 掌握需求的基本概念及类型 掌握如何进行获取需求 掌握需求规格说明书 4 掌握需求验证 理解软件需求变更管理 教学重点 软件需求的基本概念及类型 如何进行获取需求 什么是需求规格说明书以及什么是优秀的需求规格说明书 4 需求验证和需求变更管理 引言 团队和管理对项目开发很重要 但项目开发的成败取决于是否正确的进行需求获取 注 从前有一个人 从魏国到楚国去 他带上很多的盘缠 雇了上好的车 驾上骏马 请了驾车技术精湛的车夫 就上路了 楚国在魏国的南面 可这个人不问青红皂白让驾车人赶着马车一直向北走去 路上有人问他的车是要往哪儿去 他大声回答说 去楚国 路人告诉他说 到楚国去应往南方走 你这是在往北走 方向不对 那人满不在乎地说 没关系 我的马快着呢 路人替他着急 拉住他的马 阻止他说 方向错了 你的马再快 也到不了楚国呀 那人依然毫不醒悟地说 不打紧 我带的路费多着呢 路人极力劝阻他说 虽说你路费多 可是你走的不是那个方向 你路费多也只能白花呀 那个一心只想着要到楚国去的人有些不耐烦地说 这有什么难的 我的车夫赶车的本领高着呢 路人无奈 只好松开了拉住车把子的手 眼睁睁看着那个盲目上路的魏人走了 寓言告诉我们 无论做什么事 都要首先看准方向 才能充分发挥自己的有利条件 如果方向错了 条件再有利也达不到目的 同样在项目开发中有再好的团队 再好的技术 如果没有正确的进行需求获取 那么项目不可能成功 5 1需求的定义 不同背景的人对需求会有不同的看法 像瞎子摸象一样大家会站在自己的立场去理解需求 因此需求在软件工程中没有统一的定义 IEEE对需求的定义为 1 用户为解决某个问题或达到某个目标而需具备的条件或能力 2 系统或系统组件为符合合同 标准 规范或其他正式文档而必须满足的条件或必须具备的能力 IEEE的定义中同时包括了用户的观点 第一条 和开发者的观点 第二条 关于需求还有其他不同的定义 产生这些不同的原因有两点 一是需求工程的发展过程还不太长 人们的认识还不够 二是真正的需求实际上是人们的想法 很难给予准确的定义 5 2需求的类型 1 功能需求 FunctionalRequirement 和系统主要工作相关的需求 即在不考虑物理约束的情况下 用户希望系统所能够执行的活动 这些活动可以帮助用户完成任务 2 性能需求 PerformanceRequirement 系统整体或系统组成部分应该拥有的性能特征 例如CPU使用率 内存使用率等 3 质量属性 QualityAttribute 系统完成工作的质量 即系统需要在一个 好的程度 上实现功能需求 4 对外接口 ExternalInterface 系统和环境中其他系统之间需要建立的接口 包括硬件接口 软件接口 数据库接口等 5 约束 Constraint 进行系统构造时需要遵守的约束 例如编程语言 硬件设施等 5 2需求的类型 5 2需求的类型 1 2 1功能需求业务需求 BusinessRequirement 表示组织或客户高层次的目标 它描述了组织为什么要开发系统 即组织希望达到的目标 例如实现车辆的有效管理和利用 业务需求通常来自项目的投资人 购买产品的客户 实际用户的管理者 用户需求 UserRequirement 就是执行实际工作的用户对系统所能完成的具体任务的期望 业务需求是由组织的专门部门提出 但普通用户才是组织中任务的实际执行者 只有通过具体并且合理的业务流程才能真正的实现目标 也就是说用户需求描述了用户能使用系统来做些什么 系统需求 SystemRequirement 规定开发人员必须在产品中实现的软件功能 用户利用这些功能来完成任务 满足业务需求 行为需求描述的是开发人员需要实现什么 5 2需求的类型 1 2 2非功能性需求除了功能需求外 软件需求还包含非功能需求 包括性能需求 质量属性 对外接口和约束 非功能需求是衡量软件能否良好运行的定性指标 因此 非功能需求也是非常重要的 在非功能需求中 质量属性对系统的影响极大 因此在某些情况下 非功能需求又被用来特指质量属性 1 可靠性 指在给定的时间内以及规定的环境条件下 软件系统能完成所要求功能的概率 其定量指标通常用平均无故障时间和平均修复时间来衡量 2 可用性 指用户学习和使用软件系统功能的简易程度 也包括对系统的输出结果易于理解的程度 3 可维护性 指在软件系统中发现并纠正一个故障或进行一次更改的简易程度 可维护性取决于理解 更改和测试软件的简易程度 4 可移植性 指把一个软件系统从一种运行环境移植到另一个运行环境所花费的工作量的量度 5 效率 执行功能时的响应时间 处理时间和吞吐速度 比如要求系统需要满足所有用户查询都必须在7秒内完成 5 3需求获取 构建一个软件系统最困难的部分是确定构建什么 其他部分工作不会像这部分工作一样 在出错之后会如此严重地影响随后实现的系统 并且在以后修补竟会如此的困难 FredBrooks 5 3 1需求获取的方法 1 面谈用户面谈是一种十分直接而常用的需求获取方法 它也经常与其他需求获取技术一起使用 以便更好地澄清和理解一些细节问题 需要说明的是 面谈过程应该进行认真的计划和准备 我们将以小型图书馆系统的一次面谈举例说明其主要步骤 5 3 1需求获取的方法 2 需求专题讨论会需求分析员需要经常组织和协调需求专题讨论会 人们通过协调讨论和群体决策等方法 为具体问题找到解决方案 并在应用需求上达成共识 对操作过程尽快取得统一意见 在这种会议中 参加人员一般包括三种角色 主持人或协调人 该角色在会议中起着十分关键的作用 他应该鼓励参会人员积极参与和畅所欲言 保证会议过程顺利进行 记录人 该角色需要协助主持人将会议期间所讨论的要点内容记录下来 参与人 该角色的首要任务是提出设想和意见 并激励其他人员产生新的想法 5 3 1需求获取的方法 3 调查问卷调查问卷是一种经常和面谈配合使用的需求获取方法 它在内容的安排上类似于结构化面谈方法 完全按照事先确定的问题来得到反馈信息 较多地使用封闭式问题 但是在交流的媒介上 调查问卷方法和面谈方法有着明显的差异 面谈方法以口头语言为主要的交流媒介 而调查问卷以文档为主要的交流媒介 5 3 1需求获取的方法 4 原型法原型 prototype 是在软件开发中被广泛使用的一种工具 在软件开发过程中的各个阶段 包括需求开发 都会使用不同类型的原型来达到不同的目的 通常 人们更愿意从原型使用的角度来理解原型概念 如果在最终的物件 FinalArtifact 产生之前 一个中间物件 MediateArtifact 被用来在一定广度和深度范围内表现这个最终物件 那么这个中间物件就被认为是最终物件在该广度和深度上的原型 也就是说原型通常仅仅是真实系统的一个部分或者一个模型 重要的不在于使用什么材料和工具来创建它们 而是人们怎么利用它们来探索和论证未来物件的某个方面 5 3 2需求获取常见的困难 在需求获取中有很多困难是客观存在的 了解这些困难对更好地了解需求获取活动有中重要的意义 下面介绍一些常见的困难 1 用户和开发人员立场不同2 用户固执地坚持某些功能3 用户消极参与 5 4需求规格说明书 Swanick空中交通控制系统原计划在1998年完工 但直到2001年尚未交付使用 额外开支高达1亿英镑以上 经官方调查 发现其中的一个主要原因在于 缺乏健壮的需求规格说明导致无法继续进行系统实现 从上述历史事实可以看出健壮的需求规格说明书对软件开发是多么的重要 在一个复杂软件系统的开发中 编写需求规格说明书是很必要的 首先 清晰 明确的说明书可以将软件系统的需求信息和解决方案更好的传递给开发者 说明书能够弥补人们记忆能力的不足 而且不会像人类的记忆一样慢慢褪去 更重要的是需求规格说明书可以成为项目开发的一个重要依 它可以作为软件估算和项目进度安排的基础 5 4 1需求说明规格模板 5 4 2优秀需求规格说明书的特性 优秀需求规格说明书应该具备下面的特性 1 完备性 需求规格说明书是完备的 当且仅当描述了用户所有有意义的需求 包括功能 性能 约束 质量属性和对外接口 需求的完备性要求不能遗漏任何需求或者必要的信息 但需求遗漏问题很难被发现 为避免需求的遗漏 需求工程师要做好需求的分析 建立并控制正确的项目范围 2 一致性 一致性是指本层次与其他软件需求或高层需求不相矛盾 3 可修改性 需求规格说明书必须能够被修改 并可以为提供每项需求维护修改的历史记录 人们可以对其中任一需求进行容易 完整 一致的修改 4 可跟踪性 需求的可跟踪性是指可以跟踪一个需求使用期限的全过程 它为我们提供了从需求到产品实现整个过程范围的明确查阅的能力 它的目的是确保所有的工作成果符合用户需求 人们可以很容易地写出一个完全优秀的需求 但是没有人能够写出一个完全优秀的需求规格说明文档 所以上述的特性并不是对需求规格说明文档的严格验收标准 它们只是用于指导人们进行文档的编写和审阅 以产生更好的需求文档 开发更好的软件产品 5 5需求验证 5 5 1引言Standishgroup1999年的调查报告表明坚实的需求基础是影响项目成败的重要因素 这份调查报告重申了需求在软件开发中的重要性 另一方面从侧面也可以看到需求验证在实践中的重要性 需求验证是要检验需求能否反映客户的意愿 是要发现需求中的问题 需求验证很重要 如果在后续的开发或当系统投入使用时才发现需求规格说明书中的错误 就会导致更大的代价返工 由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大得多 5 5 2需求验证的方法 1 需求评审评审又被称为同级评审 是指由作者之外的其他人来检查产品问题地方法 在系统中 评审是主要的静态分析手段 所以评审也是需求评审的一种主要方法 原则上 每一个需求都应该经过评审 5 5 2需求验证的方法 2 原型与模拟在大多数情况下 需求都是在静态的方式下被加以验证的 例如评审方法 但是 当有些需求涉及复杂的动态行为时 可能就需要使用原型或者模拟方法来加以验证 5 5 2需求验证的方法 3 利用跟踪关系功能需求通常有业务需求 用户需求和系统需求三个不同的抽象层次 并存在逐步细化的关系 业务需求 用户需求 系统需求 基于这种细化关系 可以建立需求之间的跟踪关系 业务需求 系统特性 用户需求 业务 任务 系统需求 分析模型 也就是说 上述的链条中 每一个前项都可以跟踪到后项 后项是对前项的展开和细化 5 5 2需求验证的方法 需求验证的方法还有开发测试用例 用户手册编制和自动化分析等方法 5 6需求变更 Standish1995 认为对需求变化有效处理是项目成功的关键因素 Robert2002 将 需求变化 和 糟糕的项目计划 并列为导致项目失败的两个最主要的因素 在需求变化的处理上 变更控制起到至关重要的作用 5 6 1需求变化 需求开发是一个获取 明确并定义需求的过程 但需求并不是在需求开发结束之后就会恒定不变的 在产品开发和实现中或者产品递交之后 用户也常常提出需求的变化 这会给系统的开发工作带来额外的烦恼 增加工作量 尤其是在软件应用日益复杂的情况下 需求变更带来的影响越发明显 5 6 1需求变化 1 问题发生了改变 2 环境发生了改变 3 需求基线存在缺陷 此外 在实践中 下述因素也常常会导致需求的变化 1 用户变动 2 用户对软件的认识变化 3 相关产品的出现 5 6 2变更控制过程 需求的变更是正当和不可避免的 在需求开发之后冻结需求是不恰当的做法 但是需求的变更又可能会给项目带来很大的负面影响 随意的需求变更也是不恰当的做法 正确的做法是在形式需求基线之后 进行需求的变更控制 5 6 3变更控制中的注意事项 1 认识到变更的必要性 并为之制订计划项目团队必须认识到系统需求的变更是不可避免的 甚至还是必需的 认识到将会有一定数量的变更发生并为之制定变更控制计划是成功进行变更控制的关键 计划的内容应该包括 定义明确的变更控制过程 建立变更控制的有效渠道 所有的需求变更都应该遵循这一控制过程 如果提交变更请求的过程与此过程不符 则不予考虑 所有提交的需求变更请求都要进行仔细的评估 是否进行变更的决定应该由变更控制委员会统一做出 对未获批准的变更 除可行性研究之外 不应再做其他的设计和实现工作 必须对变更的实现结果进行验证 需求的变化情况要及时的通知到所有会受到影响的项目涉众 5 6 3变更控制中的注意事项 2 维护需求基线 审计变更记录有效地变更控制需要项目团队建立和维护需求基线 一旦建立了需求基线 就很容易对新需求进行识别和管理 可以把新需求与已有的基线进行比较 确定它合适的位置以及它是否会和其他已有需求冲突 在响应需求变更的过程中 项目团队还要及时准确地维护需求基线 审计变更记录 要更新需求基线 保证项目涉众可以访问到最新的需求 保留需要变更表单的记录 尤其是对批准或否决每一个变更请求的理由都要进行记录 决不能删除或修改变更请求的原始文本 5 6 3变更控制中的注意事项 3 管理范围蔓延在需求变更的过程中 对合理和不可避免的需求变化要进行有效变更 但是对不合理的变更请求也要敢于说 不 范围蔓延就是一类最为常见的不合理的需求变化请求 范围蔓延是指在需求基线确定之后 再行大幅度增加新的特性 功能和需求 而且这些新增部分是不符合预期的项目前景或者超出预期的项目范围的 因为超出了原来的预算范围 所以范围蔓延的变更请求会消耗额外的项目资源 使项目失去控制 对范围蔓延的管理 要根据业务目标 产品前景和项目范围 评估每一项提议的新增需求和特性 当然 管理范围蔓延 并不意味着要绝对拒绝任何的范围蔓延 如果涉及非常重大的业务目标调整和市场机遇变化 也