需求分析师培训资料

需求分析师培训软件需求实作要点与误区分析Agenda不同软件工程的需求视图软件需求误区与应对之道需求工程组织与实作要点Agenda不同软件工程的需求视图软件需求误区与应对之道需求工程组织与实作要点1理论是实践的基础2解决概念性误区软件需求误区与应对之道2.1透过表象，分析本质2.2国内外需求实践现状分析2.3需求的三个层面和三种类型2.4优秀需求的要点与实现手段软件需求误区与应对之道2.1透过表象，分析本质2.2国内外需求实践现状分析2.3需求的三个层面和三种类型2.4优秀需求的要点与实现手段需求问题的病症1病症：在软件工程中，变更频繁，而且集中出现在工程的中后阶段。分析要点：

>变更是对原需求的背离，还是补遗(需求不完整)?

>背离发生在什么方面(流程间/流程内/数据使用…)？

>这些变更是需求阶段是否可能预见的?

>是否存在无效的变更响应(管理有问题)?改进方向：

>变更的可预测性需求阶段标识(需求捕获/分析)

>变更渠道单一化、统一化(需求管理)需求问题的病症2病症：软件工程上线运行时遇到很多阻力。分析要点：

>是否为组织因素?

>阻力源于操作层还是管理层?改进方向：

>清晰的业务需求导向(需求定义)

>面向不同层面的需求分析

>正确识别组织因素(需求捕获)需求问题的病症3病症：软件工程上线运行后效果很差。分析要点：

>为什么不使用(用户界面/功能/手工系统)?

>使用者的本钱/效益分析?改进方向：

>抓准业务需求(需求定义)

>不同层面用户的分析(需求捕获/分析)

需求问题的病症4病症：产品二次开发量大。分析要点：

>二次开发量最要集中于什么方面(业务规那么/用户界面/流程顺序/流程细节/报表格式)?改进方向：

>工作流模型顺序/细节

>弹性设计业务规那么/UI

>报表格式理解数据模型

需求问题的病症5病症：产品/工程完全不可用或崩溃。分析要点：

>忽略了哪方面非功能需求?改进方向：

>性能与能力

>操作环境

>可靠性

>……

软件需求误区与应对之道2.1透过表象，分析本质2.2国内外需求实践现状分析2.3需求的三个层面和三种类型2.4优秀需求的要点与实现手段需求:导致工程失败的罪魁祸首根据StandishGroup对23000个工程进行的研究结果说明，28%的工程彻底失败，46%的工程超出经费预算或者超出工期，只有约26%的工程获得成功。而在于这些高达74%的不成功工程中，有约60%的失败是源于需求问题。也就是说，有近45%的工程最终因为需求的问题最终导致失败。

对不知道航行目的地的人来说，没有顺风！我们在哪里重重摔了一跤在StandishGroup的报告中总结了导致工程失败的最重要的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%)软件需求曾经让我们如此狼狈

-软件需求误区与应对之道2.1透过表象，分析本质2.2国内外需求实践现状分析2.3需求的三个层面和三种类型2.4优秀需求的要点与实现手段需求是什么?业务需求业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。背景描述：XX保险公司希望充分利用日益完善的移动通信技术，在原有的办公系统的根底上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。业务需求/目标：通过该系统的实施，将人

工保费续缴、投保手续办理两项业务运转

周期缩短10％以上，使企业内部沟通效率

大幅改善，以帮助企业运转效率得以提高。

业务需求就是系统目标现状：功能分解盛行的今天，常常会犯“盲人摸象〞的错误，这使得需求太过脆弱，难以经受考验。目标！目标！还是目标！--系统开发应目标驱动！目标是团队唯一的行动纲领。目标的定义不能够流于形式，应该具有以下特征：业务导向、可度量、合理、可行。要

注意目标太夸大会浪费资源，目标

太缩小会影响士气。〔教堂与小屋〕目标通常就是业务需求！

用户需求用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的根底上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户有不同类型：

>管理型、事务型>信息系统、人

>决策层、使用层>常用者、偶用者组织方法：用例、用户故事、特性例子：对快到期的客户，系统将通过短信

将续保信息发给该客户的代理人软件需求从系统实现的角度描述的需求。开发人员〔设计及分析人员〕在业务需求、用户需求的根底上生成的。有时还需要考虑相关联的硬件、环境方面的需求功能需求功能需求是需求的主体，是需求的本质功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作零散〔需求项〕整理〔特性、用例〕敏捷方法：用户故事质量属性产品必须具备的属性或品质可靠性：成熟性、容错性、易恢复性易使用性：易理解性、易学习性、易操作性效率：时间特性、资源特性可维护性：易分析性、易更改性、稳定性、易测试性可移植性：适应性、易安装性、一致性、易替换性McCall体系：运行(正确性、可靠性、效率、

完整性、使用性)、修正(维护性、测试性、

灵活性)、转移(移植性、复用性、共运行性)设计约束也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。例如：必须采用国有自主知识版权的数据库系统…再如：必须运行在UNIX操作系统之下三如：用户将在户外完成作业软件需求误区与应对之道2.1透过表象，分析本质2.2国内外需求实践现状分析2.3需求的三个层面和三种类型2.4优秀需求的要点与实现手段优秀的需求完整性：完整描述即将交付使用的功能，发现缺少某项信息，可以采用TBD来标注正确性：经过用户或用户信任的代理人审阅无歧义：对所有读者只有一种一致的解释必要性：每项需求记录的功能都应是用户真正需要的有优先次序：提供了实现优先级可行性：在能力和约束条件中实现可验证性：可以设计测试方法来检查Agenda不同软件工程的需求视图软件需求误区与应对之道需求工程组织与实作要点1掌握需求相关工作任务2了解需求相关工作人员需求工程组织与实作要点3.1需求工作要素与需求工程3.5需求过程与SERU模型3.4需求参与人员构成分析3.3需求管理工作要点解析3.2需求开发工作要点解析需求工程组织与实作要点3.1需求工作要素与需求工程3.5需求过程与SERU模型3.4需求参与人员构成分析3.3需求管理工作要点解析3.2需求开发工作要点解析需求错误的代价需求：1设计：5编码：10测试：20～50运行与维护：200

需求开发与管理需求工程组织与实作要点3.1需求工作要素与需求工程3.5需求过程与SERU模型3.4需求参与人员构成分析3.3需求管理工作要点解析3.2需求开发工作要点解析需求开发活动需求获取应收集什么信息：

>问题域的描述--业务模型

>要求解决的问题列表〔需求〕

>用户对解系统的行为或结构施加的任何约束信息来源：

>客户〔实际的和潜在的〕

>任何原有解系统〔已有系统〕及其文档

>原有系统用户/新系统的潜在用户

>应用〔问题〕领域专家

>定义了任何接口系统的特片和行为的文档

>相关的技术标准和法规需求获取技术阅读背景资料头脑风暴讨论分析文档考古面谈〔用户访谈〕联合应用设计用户调查需求剥离现场观摩任务观察用例和场景需求获取的误区缺乏方案性：随意、走过场，预先没方案缺乏科学性：未从本质入手捕获对象不明确，甚至造成岐义过于迷信现有文档过于迷信“听〞到的东西需求分析所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中〔需要解决〕的问题特性的透彻理解并用文档说明分析方法：结构化分析法、面向对象分析法、面向问题域分析法任何分析法，均需描述以下几个方面:

>问题域的结构

>问题子域的固有属性及行为

>问题域中的重要事件及现象

>需求：应产生的效果需求分析方法--结构化分析从基于文本分析和规格文档图形建模表示法结构化分析初期的模型：数据流图+E-R图数据流图：表达了流程，但是以数据为中心的流程E-R图：表达了要存储的信息数据字典：对数据、数据流的描述对问题域的研究力度不够大分析和设计之间缺乏清晰的界限，将

会导致不成熟的内部设计需求分析--何时进行应该在“业务需求〞充分理解，并且收集了最本质的“用户需求〞之后就开始需求分析，但并不是等到需求捕获完全做完之后交替进行，先把握用户需求主要局部，然后在分析的根底上引入系统级的需求〔系统的设计与实现角度〕，并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台分析的根底上，就会发现更多的不明确

项，更多待捕获的信息，这时就可以生

成第二次的需求调研的方案、问题、素材需求分析--何时结束需求捕获、分析与建模、规格说明书的编写、需求的验证这个需求开发的循环，是在整个软件开发生命周期中存在的每一次的循环，都将在需求开发的工作要点与份量上有所不同，它们应该遵循以下：

>从本质到边缘：本质、重要、次重要、一般、镶金

>细化阶段是需求开发最密集的阶段

>构建阶段需求开发逐渐减少需求分析--内容与形式需求分析与建模不应该是孤立的行为，产生的结果也不一定非得是标准度很高的标准文档，而应该重在分析、重在方法、重在交流、重在解决问题团队聚在一起，利用白板甚至是纸张，在充分的合作下进行分析与初步建模是本钱最低、效率最高、实用性最强的方法对于这些活动所产生的结果，可以利用数码相机、扫描仪进行文档化，“直到你一定要用时，再写文档〞对于比较重要、核心的内容，再采用Rose、Together这样的工具进行文档化编写规约规格说明书是对需求分析结果的文档化过程比较“正规〞的开发组织都会重视这个活动，甚至可以说是“重视过度〞，而且产生出来的文档经常是与实际的开发脱离，完成之后就束之高阁，再也不使用、不更新。这是一个需求崩溃的信号规格说明书的格式与所采用的开发过程、分析方法相关的，不同的方法格式不同定义统一的格式是一个很重要的工作规约内容的严谨、正确、无岐义是很

重要的需求验证这个工作大多数组织都不够重视，导致这个工作直到交付系统时才真正被履行，这也就是为什么客户拿到系统后才提出许多这样那样的需求变更，甚至认为整个系统都不是他所需要的提高需求质量的重要手段：

>需求评审

>需求确认

>通过原型来验证需求需求工程组织与实作要点3.1需求工作要素与需求工程3.5需求过程与SERU模型3.4需求参与人员构成分析3.3需求管理工作要点解析3.2需求开发工作要点解析需求开发与需求管理的分界需求基线管理为何需要：频繁的需求变更会破坏开发的节奏，使整个工程开发的进度陷入混乱和失控的状态，而且会变成一个“救火队〞式的工作，整天都在处理突发事件主要思想：将所有现在的、将来的需求进行优先级评估，然后分解成为不同的组，每次迭代都选择其中优先级最高的局部进行开发，然后在迭

代完成之前，开发工作不响应变更，

这些划入的需求项就是需求基线的组

成局部需求基线管理--操作思路我们应该在分析的根底上，将需求整合成为用例或功能项，然后对其进行优先级、依赖性进行综合性评估优先级判断：业务人员确定业务决定，技术人员确定技术决策；“满意度/不满意度〞模型依赖性是指对于某些功能，在实现上有必须的依赖关系，即当某些功能没有实现时，另

外的功能无法开始，这就需要对其

进行调整需求变更管理需求变更是一定存在的，而需求变更管理并不是指逃避它，更不是说要防止它，它实际上是希望控制变更在基线内的需求不响应变更，为开发人员提供一个安静的工作时间状态专门的需求变更管理来对所有的需求变更进行响应，了解需求变更的关键意图、新产生的工作量，从而良好地进行重新方案，以便能够有效地解决其对整个开发带来的麻烦需求跟踪需求的跟踪是指对需求的完成情况、变更影响进行系统化的跟踪与处理“需求是不是已经被实现？〞、“需求的变化将需要修改哪些设计元素？会影响谁的工作？对已经完成的局部是否有影响？〞需求工程组织与实作要点3.1需求工作要素与需求工程3.5需求过程与SERU模型3.4需求参与人员构成分析3.3需求管理工作要点解析3.2需求开发工作要点解析需求管