需求分析师培训.ppt

中程信息产业培训网需求分析师培训Agendal需求的基本概念与原理l需求工程l需求定义最佳实践l需求捕获最佳实践l业务流程与规则分析l数据需求分析与建模Agendal需求的基本概念与原理l需求工程l需求定义最佳实践l需求捕获最佳实践l业务流程与规则分析l数据需求分析与建模1）理论是实践的基础2）解决概念性的误区讨论l你认为“什么是需求”？l日常工作中，遇到与“需求”相关的问题有哪些？l关于“需求”最大的困惑是什么？l以下问题中，对你影响最大的是哪个？ > 不切实际的用户需求 1 > 很多需求最终是不需要的 0 > 用户介入太少 3 > 需求不完整 2 > 需求变更频繁 需求—导致项目失败的罪魁祸首l根据Standish Group对23000个项目进行的研究结果 表明，28%的项目彻底失败，46%的项目超出经费预 算或者超出工期，只有约26%的项目获得成功l而在于这些高达74%的不成功项目中，有约60%的失 败是源于需求问题l也就是说，有近45%的项目最终因为需求的问题最终 导致失败对不知道航行目的地的人来说， 没有顺风！我们在哪里重重摔了一跤l在Standish Group的报告中总结了导致项目失 败的最重要的8大原因中，有5个与需求相关：l不完整的需求(13.1%)；l缺乏用户的介入(12.4%)； l不实际的客户期望(9.9%)；l需求和规范的变更(8.7%)；l提供了不再需要的(7.5%)缺乏资源(10.6%),没有执行层支持(9.3%),缺少规划(8.1%)项目成功的因素l用户的参与：15.9%l管理层支持：13.9%l清晰的需求描述(13.0%)；l合适的规划(9.6%)； l现实的客户期望(8.2%)；l较小的里程碑(7.7%)；l有才能的员工(7.2%)软件需求曾经让我们如此狼狈参与各方都以自已角度讲述问题分布式 WebServices 三层 对话框 菜单条 DCOM B/S 数据交换……财务计算 管理报表 工作流 自动库存控制 库存报警 业务线索管理 业务经线索跟踪 销售月报生成 交易流数据 问题的根源是什么？l用户说的不是他想的：客户提供（陈述的需求 ）的需求并不是真实的需求，还需要作进一步 的分析，以确定客户的真正需求和期望，接下 来需要澄清并重新描述。

可以这么说客户在理 解基础业务过程和描述自己的需求方面有很大 的差异l需求分析方法有问题：系统开发人员 使用低效的需求分析和项目管理方法l共同责任强调不足：对客户和提供商 在项目成功的共同责任方面强调不够优秀的团队遇到糟糕的需求l用户参与不足l用户需求扩展l有歧义的需求l镀金问题l过于抽象的需求l忽略某种用户l不准确的计划l……我们应该怎么办？l对“需求”建立正确的认识；l客户和供应商—一根绳子上的两个蚂蚱；l和客户一起建立起“共同的目标”；l寻找并使用正确的、有效的需求捕获、描述（ 建模）、管理方法；l动态、持续地适应需求的变化；需求是什么？业务需求l业务需求是指反映组织机构或客户对系统、产品高层 次的目标要求，通常问题定义本身就是业务需求 l背景描述：XX保险公司希望充分利用日益完善的移 动通信技术，在原有的办公系统的基础上进行扩展， 使得在外的业务人员能够及时地获得客户、业务相关 的动态信息，与此同时，实现企业内部的即时通信l业务需求/目标 ：通过该系统的实施，将人 工保费续缴、投保手续办理两项业务运转 周期缩短10％以上，使企业内部沟通效率 大幅改善，以帮助企业运转效率得以提高。

业务目标示例某船厂商业管理系统目标： A1.取代过时的系统 A2.集成订单文档及数据库 A3.使用经验数据进行报价 A4.支持系统化的销售 A5.快速捕获成本数据 A6.加快发票的制作某医院管理系统目标： B1.降低IT成本 人事部门： B2.实现一些任务的自动化 B3.消除出错源 B4.遵守最后期限 B5.减少繁琐工作 医院部门： B6.减少加班及工作量不足的情况 B7.更快速的勤务规划 B8.改进勤务表质量业务需求就是定义系统目标l现状：功能分解盛行的今天，常常会犯“盲人摸象”的 错误，这使得需求太过脆弱，难以经受考验l目标！目标！还是目标！--系统开发应目标驱动！目 标是团队唯一的行动纲领l目标的定义不能够流于形式，应该具有以下特征：业 务导向、可度量、合理、可行要 注意目标太夸大会浪费资源，目标 太缩小会影响士气教堂与小屋）l目标通常就是业务需求！业务需求就是定义系统目标l目标在哪里？业务需求是构建在“项目发起人”的脑子 里的，也就是谁提出项目，谁就拥有对“业务需求”的 最清晰的理解l引出宏观的目标：思考企业运作中存在什么问题？这 些问题主要是体现在哪些方面？这些问题对企业造成 了什么影响？认为可以怎么解决？希望达到什么样的 效果？l将大任务分解成为小目标，并且引导客户良好地定义 ，这也是我们形成“项目子目标描述”的关键基础。

l衡量这些目标的合理性与可行性业务需求就是定义系统目标l形成一个不超过50字的项目目标，并且列出5-9个主 要子目标，并且将其制作成一页文档，作为“项目的 行动纲领”，还应该得到“项目发起人”的认可l在此基础上，可以编写“项目的目标和范围文档”(或称 项目综述，即POS，内容包括问题/机会、项目目标 、项目目的、成功标准、假设/风险/障碍)，对于产品 而言，我们还可以构建一个从市场角度分析的“愿景” 文档l该部分工作是处于“需求过程”的金字塔尖，多花费一 些时间和精力是值得的，也是必要的 业务需求就是定义系统目标l有了清晰的目标之 后，还应该对系统 划定范围，最常用 的方法是工作上下 文范围图（结构化 分析方法）：用户需求l用户需求是指描述用户使用产品必须要完成什么任务 ，怎么完成的需求，通常是在问题定义的基础上进用 户访谈、调查，对用户使用的场景进行整理，从而建 立从用户角度的需求 l用户有不同类型： > 管理型、事务型 > 信息系统、人 > 决策层、使用层 > 常用者、偶用者l组织方法：用例、用户故事、特性l例子：对快到期的客户，系统将通过短信 将续保信息发给该客户的代理人系统需求l解释一：系统需求是相关联的硬件、软件系统对待开 发系统的相关需求。

l解释二：从系统实现的角度描述的需求l开发人员（设计及分析人员）在业务需求、用户需求 的基础上生成的功能需求l功能需求是需求的主体，是需求的本质l功能需求定义了：系统必须完成的那些事，即为了向 它的用户提供有用的功能，产品必须执行的动作 l零散（需求项）整理（特性、用例）l敏捷方法：用户故事质量属性l产品必须具备的属性或品质 l可靠性：成熟性、容错性、易恢复性l易使用性：易理解性、易学习性、易操作性l效率：时间特性、资源特性l可维护性：易分析性、易更改性、稳定性、易测试性l可移植性：适应性、易安装性、一致性、易替换性lMcCall体系：运行(正确性、可靠性、效率、 完整性、使用性)、修正(维护性、测试性、 灵活性)、转移(移植性、复用性、共运行性)设计约束l也称为限制条件、补充规约，这通常是对解决 方案的一些约束说明l例如：必须采用国有自主知识版权的数据库系 统…l再如：必须运行在UNIX操作系统之下两个世界三种设计优秀的需求l完整性：完整描述即将交付使用的功能，发现缺少某 项信息，可以采用TBD来标注l正确性：经过用户或用户信任的代理人审阅l可行性：在已知能力和约束条件中实现l必要性：每项需求记录的功能都应是用户真正需要的l有优先次序：提供了实现优先级l无歧义：对所有读者只有一种一致的解释l可验证性：可以设计测试方法来检查检查表示例讨论l前面的描述中，最大的感触是什么？Agendal需求的基本概念与原理l需求工程l需求定义最佳实践l需求捕获最佳实践l业务流程与规则分析l数据需求分析与建模1）掌握需求的相关工作2）了解需求的相关人员需求错误的代价需求：1设计：5编码：10测试：20-50运行与维护：200需求开发与管理需求开发活动需求获取l应收集什么信息： > 问题域的描述 > 要求解决的问题列表（需求） > 用户对解系统的行为或结构施加的任何约束l信息来源： > 客户（实际的和潜在的） > 任何原有解系统（已有系统）及其文档 > 原有系统用户 / 新系统的潜在用户 > 应用（问题）领域专家 > 定义了任何接口系统的特片和行为的文档 > 相关的技术标准和法规需求获取技术 •阅读背景资料•头脑风暴•讨论分析•文档考古•面谈（用户访谈）•联合应用设计•用户调查•需求剥离•现场观摩•任务观察•用例和场景需求获取的误区l缺乏计划性：随意、走过场，预先没计划l缺乏科学性：未从本质入手l捕获对象不明确，甚至造成岐义l过于迷信现有文档l过于迷信“听”到的东西需求分析l所谓分析是指通过对问题域的研究，获得对该领域特 性及存在于其中（需要解决）的问题特性的透彻理解 并用文档说明l分析方法：结构化分析法、面向对象分析法、面向问 题域分析法l任何分析法，均需描述以下几个方面: > 问题域的结构（子域，及子域间关系） > 问题域的数据 > 问题子域的固有属性及行为 > 问题域中的重要事件及现象 > 需求：应产生的效果需求分析—何时进行l应该在“业务需求”充分理解，并且收集了最本质的“用 户需求”之后就开始需求分析，但并不是等到需求捕 获完全做完之后 l交替进行，先把握用户需求主要部分，然后在分析的 基础上引入系统级的需求（系统的设计与实现角度） ，并且分析模型，成为开发人员之间、开发人员与客 户之间达成共识的一个平台l分析的基础上，就会发现更多的不明确项， 更多待捕获的信息，这时就可以生成第二次 的需求调研的计划、问题、素材 需求分析—何时结束l需求捕获、分析与建模、规格说明书的编写、需求的 验证这个需求开发的循环，是在整个软件开发生命周 期中存在的 l每一次的循环，都将在需求开发的工作要点与份量上 有所不同，它们应该遵循以下： > 从本质到边缘：本质、重要、次重要、一般、镶金 > 细化阶段是需求开发最密集的阶段 > 构建阶段需求开发逐渐减少需求分析—内容与形式l需求分析与建模不应该是孤立的行为 ，产生的结果也 不一定非得是规范度很高的标准文档，而应该重在分 析、重在方法、重在交流、重在解决问题 l团队聚在一起，利用白板甚至是纸张，在充分的合作 下进行分析与初步建模是成本最低、效率最高、实用 性最强的方法 l对于这些活动所产生的结果，可以利用数码相机、扫 描仪进行文档化 ，“直到你一定要用时，再写文档” l对于比较重要、核心的内容，再采用 Rose、Together这样的工具进行文档化 编写规约l规格说明书是对需求分析结果的文档化过程l比较“正规”的开发组织都会重视这个活动，甚至可以 说是“重视过度”，而且产生出来的文档经常是与实际 的开发脱离，完成之后就束之高阁，再也不使用、不 更新。

这是一个需求崩溃的信号 l规格说明书的格式与所采用的开发过程、分析方法相 关的，不同的方法格式不同l定义统一的格式是一个很重要的工作l规约内容的严谨、正确、无岐义是很重要的需求验证l这个工作大多数组织都不够重视，导致这个工作直到 交付系统时才真正被履行，这也就是为什么客户拿到 系统后才提出许多这样那样的需求变更，甚至认为整 个系统都不是他所需要的l提高需求质量的重要手段： > 需求评审 > 需求确认 > 通过原型来验证需求需求开发与需求管理的分界需求基线管理l频繁的需求变更会破坏开发的节奏，使整个项目开发 的进度陷入混乱和失控的状态，而且会变成一个“救 火队”式的工作，整天都在处理突发事件l将所有现在的、将来的需求进行优先级评估，然后分 解成为不同的组，每次迭代都选择其中优先级最高的 部分进行开发，然后在迭代完成之前，开发工作不响 应变更，这些划入的需求项就是需求基线的组成部分 需求基线管理—操作思路l我们应该在分析的基础上，将需求整合成为用例或功 能项，然后对其进行优先级、依赖性进行综合性评估l优先级判。