需求分析师培训资料.ppt

软件需求实作要点与误区分析 Agenda 不同软件项目的需求视图 软件需求误区与应对 之道 需求工程组织 与实作要点 Agenda 不同软件项目的需求视图 软件需求误区与应对 之道 需求工程组织 与实作要点 需求问题 的症状 1 症状：在软件项目中，变更频繁，而且集中出现在 项目的中后阶段。 分析要点： 变更是对原需求的背离，还是补遗 (需求不完整)? 背离发生在什么方面(流程间/流程内/数据使用)？ 这些变更是需求阶段是否可能预见 的? 是否存在无效的变更响应(管理有问题 )? 改进方向： 变更的可预测 性 需求阶段标识 (需求捕获/分析) 变更渠道单一化、统一化(需求管理) 需求问题 的症状 2 症状：软件项目上线运行时遇到很多阻力。 分析要点： 是否为组织 因素? 阻力源于操作层还 是管理层? 改进方向： 清晰的业务 需求导向 (需求定义) 面向不同层面的需求分析 正确识别组织 因素(需求捕获) 需求问题 的症状 3 症状：软件项目上线运行后效果很差。 分析要点： 为什么不使用(用户界面/功能/手工系统)? 使用者的成本/效益分析? 改进方向： 抓准业务 需求(需求定义) 不同层面用户的分析(需求捕获/分析) 需求问题 的症状 4 症状：产品二次开发量大。 分析要点： 二次开发量最要集中于什么方面(业务规则 /用户界 面/流程顺序/流程细节 /报表格式)? 改进方向： 工作流模型 顺序/细节 弹性设计 业务规则 /UI 报表格式 理解数据模型 需求问题 的症状 5 症状：产品/项目完全不可用或崩溃。 分析要点： 忽略了哪方面非功能需求? 改进方向： 性能与能力 操作环境 可靠性 需求:导致项目失败的罪魁祸首 根据Standish Group对23000个项目进行的研究结果 表明，28%的项目彻底失败，46%的项目超出经费 预算或者超出工期，只有约26%的项目获得成功。 而在于这些高达74%的不成功项目中，有约60%的失 败是源于需求问题 。 也就是说，有近45%的项目最终因为需求的问题 最 终导 致失败。 对不知道航行目的地的人来说 ，没有顺风！ 我们在哪里重重摔了一跤 在Standish Group的报告中总结 了导致项目失败的 最重要的8大原因中，有5个与需求相关： 不完整的需求(13.1%)； 缺乏用户的介入(12.4%)； 不实际 的客户期望(9.9%)； 需求和规范的变更(8.7%)； 提供了不再需要的(7.5%) 缺乏资源(10.6%),没有执行层支持(9.3%),缺少规划(8.1%) 项目成功的因素 用户户的参与：15.9% 管理层支持：13.9% 清晰的需求描述(13.0%)； 合适的规划(9.6%)； 现实现实 的客户户期望(8.2%)； 较小的里程碑(7.7%)； 有才能的员工(7.2%) 软件需求曾经让 我们如此狼狈 - 业务 需求 业务 需求是指反映组织 机构或客户对 系统、产品高 层次的目标要求，通常问题 定义本身就是业务 需求 。 背景描述：XX保险公司希望充分利用日益完善的移动 通信技术，在原有的办公系统的基础上进行扩展， 使得在外的业务 人员能够及时地获得客户、业务 相 关的动态 信息，与此同时，实现 企业内部的即时通 信。 业务 需求/目标 ：通过该 系统的实施，将人 工保费续缴 、投保手续办 理两项业务 运转 周期缩短10以上，使企业内部沟通效率 大幅改善，以帮助企业运转效率得以提高。 业务 需求就是系统目标 现状：功能分解盛行的今天，常常会犯“盲人摸象”的 错误 ，这使得需求太过脆弱，难以经受考验。 目标！目标！还是目标！-系统开发应 目标驱动标驱动 ！ 目标是团队 唯一的行动纲领 。 目标的定义不能够流于形式，应该 具有以下特征： 业务导业务导 向、可度量、合理、可行。要 注意目标太夸大会浪费资 源，目标 太缩小会影响士气。（教堂与小屋） 目标通常就是业务业务 需求！ 用户需求 用户需求是指描述用户使用产品必须要完成什么任务 ，怎么完成的需求，通常是在问题 定义的基础上进用 户访谈 、调查 ，对用户使用的场景进行整理，从而 建立从用户角度的需求。 用户有不同类型： 管理型、事务型 信息系统、人 决策层、使用层 常用者、偶用者 组织 方法：用例、用户故事、特性 例子：对快到期的客户，系统将通过短信 将续保信息发给该 客户的代理人 软件需求 从系统实现 的角度描述的需求。 开发人员（设计 及分析人员）在业务 需求、用户需 求的基础上生成的。 有时还 需要考虑相关联的硬件、环境方面的需求 功能需求 功能需求是需求的主体，是需求的本质 功能需求定义了：系统必须完成的那些事，即为了向 它的用户提供有用的功能，产品必须执 行的动作 零散（需求项） 整理（特性、用例） 敏捷方法：用户故事 质量属性 产品必须具备的属性或品质 可靠性：成熟性、容错性、易恢复性 易使用性：易理解性、易学习性、易操作性 效率：时间 特性、资源特性 可维护 性：易分析性、易更改性、稳定性、易测试 性 可移植性：适应性、易安装性、一致性、易替换性 McCall体系：运行(正确性、可靠性、效率、 完整性、使用性)、修正(维护 性、测试 性、 灵活性)、转移(移植性、复用性、共运行性) 设计约 束 也称为限制条件、补充规约 ，这通常是对解决方案 的一些约束说明。 例如：必须采用国有自主知识版权的数据库系统 再如：必须运行在UNIX操作系统之下 三如：用户将在户外完成作业 优秀的需求 完整性：完整描述即将交付使用的功能，发现 缺少某 项信息，可以采用TBD来标注 正确性：经过 用户或用户信任的代理人审阅 无歧义：对所有读者只有一种一致的解释 必要性：每项需求记录 的功能都应是用户真正需要的 有优先次序：提供了实现优 先级 可行性：在已知能力和约束条件中实现 可验证 性：可以设计测试 方法来检查 Agenda 不同软件项目的需求视图 软件需求误区与应对 之道 需求工程组织 与实作要点 需求错误 的代价 需求开发与管理 需求开发活动 需求获取 应收集什么信息： 问题 域的描述-业务业务 模型 要求解决的问题 列表（需求） 用户对 解系统的行为或结构施加的任何约约束 信息来源： 客户（实际 的和潜在的） 任何原有解系统（已有系统）及其文档 原有系统用户 / 新系统的潜在用户 应用（问题 ）领域专家 定义了任何接口系统的特片和行为的文档 相关的技术标 准和法规 需求获取技术 阅读阅读 背景资资料 头脑风头脑风 暴 讨论讨论 分析 文档考古 面谈谈（用户访谈户访谈 ） 联联合应应用设计设计 用户调查户调查 需求剥离 现场观现场观 摩 任务观务观 察 用例和场场景 需求获取的误区 缺乏计划性：随意、走过场 ，预先没计划 缺乏科学性：未从本质入手 捕获对 象不明确，甚至造成岐义 过于迷信现有文档 过于迷信“听”到的东西 需求分析 所谓分析是指通过对问题 域的研究，获得对该领 域 特性及存在于其中（需要解决）的问题 特性的透彻理 解并用文档说明 分析方法：结构化分析法、面向对象分析法、面向问 题域分析法 任何分析法，均需描述以下几个方面: 问题 域的结构 问题 子域的固有属性及行为 问题 域中的重要事件及现象 需求：应产 生的效果 需求分析方法-结构化分析 从基于文本分析和规格文档 图形建模表示法 结构化分析初期的模型：数据流图+E-R图 数据流图：体现了流程，但是以数据为中心的流程 E-R图：体现了要存储的信息 数据字典：对数据、数据流的描述 对问题问题 域的研究力度不够大 分析和设计 之间缺乏清晰的界限，将 会导致不成熟的内部设计 需求分析-何时进 行 应该 在“业务 需求”充分理解，并且收集了最本质的“用 户需求”之后就开始需求分析，但并不是等到需求捕获 完全做完之后 交替进行，先把握用户需求主要部分，然后在分析的 基础上引入系统级 的需求（系统的设计 与实现 角度 ），并且分析模型，成为开发人员之间、开发人员 与客户之间达成共识的一个平台 分析的基础上，就会发现 更多的不明确 项，更多待捕获的信息，这时 就可以生 成第二次的需求调研的计划、问题 、素材 需求分析-何时结 束 需求捕获、分析与建模、规格说明书的编写、需求的 验证这 个需求开发的循环，是在整个软件开发生命 周期中存在的 每一次的循环，都将在需求开发的工作要点与份量上 有所不同，它们应该 遵循以下： 从本质到边缘 ：本质、重要、次重要、一般、镶金 细化阶段是需求开发最密集的阶段 构建阶段需求开发逐渐减少 需求分析-内容与形式 需求分析与建模不应该 是孤立的行为 ，产生的结果 也不一定非得是规范度很高的标准文档，而应该 重在 分析、重在方法、重在交流、重在解决问题 团队 聚在一起，利用白板甚至是纸张 ，在充分的合作 下进行分析与初步建模是成本最低、效率最高、实用 性最强的方法 对于这些活动所产生的结果，可以利用数码相机、 扫描仪进 行文档化 ，“直到你一定要用时，再写文档” 对于比较重要、核心的内容，再采用Rose、 Together这样 的工具进行文档化 编写规约 规格说明书是对需求分析结果的文档化过程 比较“正规”的开发组织 都会重视这 个活动，甚至可以 说是“重视过 度”，而且产生出来的文档经常是与实际 的开发脱离，完成之后就束之高阁，再也不使用、不 更新。这是一个需求崩溃的信号 规格说明书的格式与所采用的开发过 程、分析方法相 关的，不同的方法格式不同 定义统 一的格式是一个很重要的工作 规约 内容的严谨 、正确、无岐义是很 重要的 需求验证 这个工作大多数组织 都不够重视，导致这个工作直 到交付系统时 才真正被履行，这也就是为什么客户拿 到系统后才提出许多这样 那样的需求变更，甚至认 为整个系统都不是他所需要的 提高需求质量的重要手段： 需求评审 需求确认 通过原型来验证 需求 需求开发与需求管理的分界 需求基线管理 为何需要：频繁的需求变更会破坏开发的节奏，使整 个项目开发的进度陷入混乱和失控的状态，而且会变 成一个“救火队”式的工作，整天都在处理突发事件 主要思想：将所有现在的、将来的需求进行优先级评 估，然后分解成为不同的组，每次迭代都选择 其中优 先级最高的部分进行开发，然后在迭 代完成之前，开发工作不响应变 更， 这些划入的需求项就是需求基线的组 成部分 需求基线管理-操作思路 我们应该 在分析的基础上，将需求整合成为用例或功 能项，然后对其进行优先级、依赖性进行综合性评 估 优先级判断：业务 人员确定业务 决定，技术人员确 定技术决策；“满意度/不满意度”模型 依赖性是指对于某些功能，在实现 上有必须的依赖 关系，即当某些功能没有实现时 ，另 外的功能无法开始，这就需要对其 进行调整 需求变更管理 需求变更是一定存在的，而需求变更管理并不是指逃 避它，更不是说要避免它，它实际 上是希望控制变更 在基线内的需求不响应变 更，为开发人员提供一个 安静的工作时间 状态 专门 的需求变更管理来对所有的需求变更进行响应 ，了解需求变更的关键意图、新产生的工作量，从而 良好地进行重新计划，以便能够有效地解决其对整个 开发带 来的麻烦 需求跟踪 需求的跟踪是指对需求的完成情况、变更影响进行系 统化的跟踪与处理 “需求是不是已经被实现 ？”、“需求的变化将需要修改 哪些设计 元素？会影响谁的工作？对已经完成的部分 是否有影响？” 需求管理的参与者 需求分析师 需求分析员是对项 目涉众的需求进行收集、分析、记 录和验证 等职责 的主要承担者，是用户群体与软件 开发团队间进 行需求沟通的主要渠道 典型活动：定义业务 需求、确定项目涉众和用户类 别、获取需求、分析需求、为需求建模、编写需求规 格说明、主持对需求的验证 、引导对 需求的优先级 划分、管理需求 必备技能：倾听、交谈和提问的技巧， 分析、协调 、观察、写作、组织 、建 模、人际交往和创造能力 需求分析师 必备知识：现代需求管理技术、各种软件开发生命 周期、领域知识 需求分析员的来源：用户转为 分析员（软件工程知 识欠缺）、开