4章 需求分析与系统设计----需求开发.pptVIP

第四章 需求工程 本章学习内容 需求工程概述 需求发现 需求规约 需求文档化 需求验证 4.1需求工程概述 4.1.1 需求的“缺陷”导致风险 40～60％的项目失败都是由与需求有关的工作缺陷造成的。 遗漏了需求的提供者导致产品无法被接受。 需求的增加和频繁变化带来过度的耗费和产品质量的降低。 模棱两可的需求说明导致的返工。 用户和开发人员增加一些不必要的特性导致时间的浪费。 需求说明过分简略以致某些关键要求没有得到满足。 不完善的需求说明使得项目计划和跟踪无法准确进行。 ………… 4.1.2 什么是需求工程 4.1.3 需求工程的活动 需求开发 需求发现 需求规约 需求文档化 需求验证 需求管理 变更控制 版本控制 需求跟踪 状态管理 （1）需求开发 需求开发包括一组为“产生高质量软件需求”而设立的活动，其主要任务包括 定义软件的业务目标和应用范围 确定软件的用户群体 捕获并记录用户对系统的要求 对需求进行分类和整理，建立需求优先级 协商处理需求的冲突和冗余 建立系统的概念模型 编写《需求规格说明书》 组织对需求的验证，形成开发的基线 需求开发的产品 需求规格说明书（也可能包含其他文档） 系统分析模型 需求开发的过程 需求开发活动完成了软件开发全过程中最重要、也是跨度最大的一次概念转换，即将“需要解决的问题”由应用领域的业务系统转移到技术领域的软件系统中。 知识背景的差异 思维方式和表达习惯的差异 …… （2） 需求管理 需求管理包括一组在工程进展过程中维持需求约定集成性和精确性的活动，其主要任务包括 定义需求基线（制定需求文档的主体）。 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。 以一种可控制的方式将需求变更融入到项目中。 在接受需求变更时协商新的承诺（约定）。 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。 在整个项目过程中跟踪需求状态及其变更情况。 CMM（能力成熟度模型)的第二级要求开发组织必须具有在软件开发与管理的六个KPA（关键过程域 Key Process Areas）以展示达到目标的能力。需求管理是其中之一 版本控制 版本控制是需求管理的一个必要方面，需求文档的每一个版本必须被统一确定，组内每个成员必须能够得到需求的当前版本。 每个公布的需求文档的版本应该包括一个修正版本的历史情况，既已做变更的内容、变更日期、变更人姓名以及变更的原因。 版本控制的最简单办法是根据标准约定手工标记软件需求规格说明的每一次修改。 高级的版本控制包括使用版本控制工具来存储需求文档。 需求联系链跟踪 效益 审核所有的需求被应用 分析变更影响 维护 项目跟踪 再设计 重用 减小风险 测试 需求的状态 已建议 该需求已被有权提出的人建议 已批准 软件开发团队已同意实现该需求 已实现 已实现需求代码的设计、编写和单元测试 已验证 该需求被认为完成 已删除 计划的需求已从基线中删除 4.2 需求发现 4.2.1 需求发现的任务 需求发现阶段的任务框架 领域了解：熟悉应用环境和业务流程 获取业务需求：确定软件的总体目标和范围边界 划分用户类：明确用户群体和代表 用户通信：搜集需求 需求整理 4.2.2 领域了解 可能的参与者：领域专家、客户 目的：对目标系统的应用领域建立概括性认识 当前业务开展的现状——业务流程图 行业规则——业务文档（规程、手册……） 职能部门及其职责——组织结构图 理解在领域内常用术语和概念——术语表 效益提高分析员与用户沟通时的理解能力，缩短需求开发的时间，并增强用户对开发团队经验、能力的信心。 4.2.3 获取业务需求 参与者：甲方负责人（客户） 目标 确认领域了解所获得的业务知识 明确要解决的主要问题（实例）和软件系统的整体目标 确定软件系统的应用范围、开发约束及计算机应用环境等。 效益： 业务需求是《软件需求说明书》的必要内容 应用范围为“划分用户类”提供依据 项目整体目标和范围是防止需求扩张、审核需求必要性等工作的重要依据。 4.2.4 划分用户类 目标 划分应用范围内的用户群体，同类用户应从事相容的业务活动，对软件的使用要求大致相同。 描述用户类的特征 工作职责和特点 使用要求 知识背景、计算机应用能力 在用户类中确定用户代表 用户代表是主要的需求获取对象，并能在出现需求冲突时帮助决策。 效益： 减少用户通信的工作量和时间 可根据用户类的特点采用合适的通信手段。 4.2.5 用户通信（需求收集） 用户通信是需求发现阶段的核心任务，即利用有效的通信手段收集各类用户的需求。 用户通信的实施手段 访谈——“唠嗑” 实际观察——“偷窥” 调查表——“考试” 原型——“试验” JAD（联合应用开发）——“开会” JAD并不仅限于应用在需求发现阶段，而是一种快速进行需求开发