需求评估培训.ppt

day01,需求评估培训,agenda,需求的基本概念与原理 需求工程 需求定义最佳实践 需求捕获最佳实践 业务流程与规则分析 数据需求分析与建模,agenda,需求的基本概念与原理 需求工程 需求定义最佳实践 需求捕获最佳实践 业务流程与规则分析 数据需求分析与建模,1）理论是实践的基础 2）解决概念性的误区,讨论,你认为“什么是需求”？ 日常工作中，遇到与“需求”相关的问题有哪些？ 关于“需求”最大的困惑是什么？ 以下问题中，对你影响最大的是哪个？ 不切实际的用户需求 很多需求最终是不需要的 用户介入太少 需求不完整 需求变更频繁,软件需求的定义,软件行业存在这样一个问题，用于描述需求工作的术语没有统一的定义。 对同一项需求，不同的人会有不同的描述，称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。 客户对需求的定义，在开发人员看来可能只是高级别的产品概念；而开发人员的需求概念对用户来说也许就是详细的用户界面设计。 需求必须被记录成文档，这一点很重要。,5,对需求的不同解释,ieee的软件工程标准术语表(1990)则将需求定义为: 用户为解决某个问题或达到某个目标而需具备的条件或能力。 系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。 上述第一项或第二项中定义的条件和能力的文档表达。,6,注意 : 不要一厢情愿地认为项目涉众对需求的理解是一致的。应该事先给出定义， 才能保证大家谈论的是同一个问题。,需求导致项目失败的罪魁祸首,根据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%),软件需求曾经让我们如此狼狈,参与各方都以自已角度讲述问题,分布式 web services 三层 对话框 菜单条 dcom b/s 数据交换,财务计算 管理报表 工作流 自动库存控制 库存报警 业务线索管理 业务经线索跟踪 销售月报生成 交易流数据,问题的根源是什么？,用户说的不是他想的：客户提供（陈述的需求）的需求并不是真实的需求，还需要作进一步的分析，以确定客户的真正需求和期望，接下来需要澄清并重新描述。可以这么说客户在理解基础业务过程和描述自己的需求方面有很大的差异。 需求分析方法有问题：系统开发人员 使用低效的需求分析和项目管理方法。 共同责任强调不足：对客户和提供商 在项目成功的共同责任方面强调不够。,优秀的团队遇到糟糕的需求,用户参与不足 用户需求扩展 有歧义的需求 镀金问题 过于抽象的需求 忽略某种用户 不准确的计划 ,用户参与不足,开发人员往往也不重视用户的参与，原因是他们认为与用户打交道不像写代码那么有趣，或者自以为已经知道了用户想要什么。 用户参与不足将导致不能在项目早期及时发现需求中的缺陷，从而延误项目的完成。 在整个项目开发过程中，开发团队必须始终与实际用户直接合作。,14,用户需求扩展,由于开发过程中需求的不断发展与增加，项目往往会落后于计划的进度并超出预算。 出现这种情况是因为没有依据对需求的规模和复杂度的实际评估来制订计划，而不断修改需求又使情况变得更糟。 问题的责任部分在于用户不断提出修改需求的要求，部分在于开发人员处理这种要求的方式。 要控制项目范围的改变： 首先应明确项目的业务目标、全局规划、范围、限制、成功标准以及产品的预计用途。 然后参考这一框架对所有新特性和需求变更进行评估。,15,有岐义的需求,岐义表现为同一读者可以对一项需求声明作出多种解释，或者不同的读者对同一需求产生不同的理解。 岐义会导致以下几点： 涉众对产品怀有不同的期望。因此最终交付的产品会让部分人感到意外。 有岐义的需求使开发人员的时间浪费在解决无需解决的问题上。 有岐义的需求导致测试人员与开发人员对产品功能的理解不同，从而使测试人员也要浪费时间来解决这些差异。 消除歧义的办法之一是让代表不同观点的人对需求作正式的检查 。,16,镀金问题,开发人员为产品添加了一项需求说明中没有提到的功能，他认为“用户肯定会喜欢的”。这就是所谓的“镀金问题(gold plating)”。 开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定。 要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。,17,过于抽象的需求,营销人员或经理经常喜欢只给出一个粗略的说明，他们希望开发人员在开发过程中充实它。 这种方式对研究性项目或需求特别灵活的项目或许管用，但是需要紧密合作的团队，而且仅限于开发小型系统(mcconnell 1996)。 大多数情况下，这种做法的结果是使开发人员受挫，让客户失望。,18,忽略了某类用户,用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。 因此，多数产品都拥有不同的用户群。如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。确定所有用户群后，还要保证获得各类用户的需求 。,19,不准确的计划,不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。 造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确，以及对需求的分析不透彻(davis 1995)等。,20,优质需求过程的好处,实现有效的需求工程过程。减少开发后期以及整个维护过程中不必要的返工并可带来极大的回报。 下面列出的好处并不能完全量化，但确实存在： 减少需求缺陷 减少开发过程中的返工 减少不必要的特性 降低改进成本 加快开发进度 提高沟通效率 控制需求范围的改变 项目更有序 对系统测试的评估更准确 提高客户和开发人员的满意度,21,优秀需求的特点,如何才能将好的需求规格说明与那些有问题的区分开来？ 这一节首先对说明中的单条需求(即需求声明)特点进行讨论，然后将介绍srs作为整体应具备的特点。 如果想知道您的需求是否具备这些特点，最好的办法就是请几位项目相关人员仔细审阅您的srs。不同的人会发现不同的问题。,22,需求陈述的特点,每一项用户需求、业务需求和功能需求都应具备下列性质 。 完整性 每一项需求都必须完整地描述即将交付使用的功能。 正确性 每一项需求都必须准确地描述将要开发的功能。 可行性 需求必须能够在系统及其运行环境的已知能力和约束条件内实现。 必要性 每一项需求记录的功能都必须是用户的真正需要，或者是为符合外部系统需求或某一标准而必须具备的功能。 有优先次序 为每一项功能需求、特性或用例指定一个实现优先级，以表明它在产品的某一版本中的重要程度。 无歧义 一项需求声明对所有读者应该只有一种一致的解释，然而自然语言却极易产生歧义。 可验证性 看看您能否设计一些测试方法或使用其他验证方法，如检查或演示来判断产品是否正确实现了需求。,23,权利和义务法案,我们应该怎么办？,对“需求”建立正确的认识； 客户和供应商一根绳子上的两个蚂蚱； 和客户一起建立起“共同的目标”； 寻找并使用正确的、有效的需求捕获、描述（建模）、管理方法； 动态、持续地适应需求的变化；,需求是什么？,业务需求,业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求 。 背景描述：xx保险公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。 业务需求/目标 ：通过该系统的实施，将人 工保费续缴、投保手续办理两项业务运转 周期缩短10以上，使企业内部沟通效率 大幅改善，以帮助企业运转效率得以提高。,业务目标示例,某船厂商业管理系统目标： a1.取代过时的系统 a2.集成订单文档及数据库 a3.使用经验数据进行报价 a4.支持系统化的销售 a5.快速捕获成本数据 a6.加快发票的制作,某医院管理系统目标： b1.降低it成本 人事部门： b2.实现一些任务的自动化 b3.消除出错源 b4.遵守最后期限 b5.减少繁琐工作 医院部门： b6.减少加班及工作量不足的情况 b7.更快速的勤务规划 b8.改进勤务表质量,业务需求就是定义系统目标,现状：功能分解盛行的今天，常常会犯“盲人摸象”的错误，这使得需求太过脆弱，难以经受考验。 目标！目标！还是目标！-系统开发应目标驱动！目标是团队唯一的行动纲领。 目标的定义不能够流于形式，应该具有以下特征：业务导向、可度量、合理、可行。要 注意目标太夸大会浪费资源，目标 太缩小会影响士气。（教堂与小屋） 目标通常就是业务需求！,业务需求就是定义系统目标,目标在哪里？业务需求是构建在“项目发起人”的脑子里的，也就是谁提出项目，谁就拥有对“业务需求”的最清晰的理解。 引出宏观的目标：思考企业运作中存在什么问题？这些问题主要是体现在哪些方面？这些问题对企业造成了什么影响？认为可以怎么解决？希望达到什么样的效果？ 将大任务分解成为小目标，并且引导客户良好地定义，这也是我们形成“项目子目标描述”的关键基础。 衡量这些目标的合理性与可行性。,业务需求就是定义系统目标,形成一个不超过50字的项目目标，并且列出5-9个主要子目标，并且将其制作成一页文档，作为“项目的行动纲领”，还应该得到“项目发起人”的认可。 在此基础上，可以编写“项目的目标和范围文档”(或称项目综述，即pos，内容包括问题/机会、项目目标、项目目的、成功标准、假设/风险/障碍)，对于产品而言，我们还可以构建一个从市场角度分析的“愿景”文档。 该部分工作是处于“需求过程”的金字塔尖，多花费一些时间和精力是值得的，也是必要的。,业务需求就是定义系统目标,有了清晰的目标之 后，还应该对系统 划定范围，最常用 的方法是工作上下 文范围图（结构化 分析方法）：,用户需求,用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。 用户有不同类型： 管理型、事务型 信息系统、人 决策层、使用层 常用者、偶用者 组织方法：用例、用户故事、特性 例子：对快到期的客户，系统将通过短信 将续保信息发给该客户的代理人,系统需求,解释一：系统需求是相关联的硬件、软件系统对待开发系统的相关需求。 解释二：从系统实现的角度描述的需求。 开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。,功能需求,功能需求是需求的主体，是需求的本质 功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作 零散（需求项）整理（特性、用例） 敏捷方法：用户故事,质量属性,产品必须具备的属性或品质 可靠性：成熟性、容错性、易恢复性 易使用性：易理解性、易学习性、易操作性 效率：时间特性、资源特性 可维护性：易分析性、易更改性、稳定性、易测试性 可移植性：适应性、易安装性、一致性、易替换性 mccall体系：运行(正确性、可靠性、效率、 完整性、使用性)、修正(维护性、测试性、 灵活性)、转移(移植性、复用性、共运行性),设计约束,也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。 例如：必须采用国有自主知识版权的数据库系统 再如：必须运行在unix操作系统之下,两个世界三种设计,优秀的需求,完整性：完整描述即将交付使用的功能，发现缺少某项信息，可以采用tbd来标注 正确性：经过用户或用户信任的代理人审阅 可行性：在已知能力和约束条件中实现 必要性：每项需求记录的功能都应是用户真正需要的 有优先次序：提供了实现优先级 无歧义：对所有读者只有一种一致的解释 可验证性：可以设计测试方法来检查,讨论,前面的描述中，最大的感触是什么？,agenda,需求的基本概念与原理 需求工程 需求定义最佳实践 需求捕获最佳实践 业务流程与规则分析 数据需求分析与建模,1）掌握需求的相关工作 2）了解需求的相关人员,需求错误的代价,需求：1,设计：5,编码：10,测试：20-50,运行与维护：200,需求开发与管理,需求开发活动,需求开发,需求开发可进一步细分为获取(elicitation)、分析(analysis)、规格说明(specification)和确认(validation)(abran和moore 2001)。 这些子学科涵盖了为软件和软件相关产品收集、评估和记录需求相关的所有活动，包括： 确定产品将要面对的各类用户。 从各类用户的代表处收集需求。 了解用户的任务和目标，以及这些任务要实现的业务目标。 分析从用户处得到的信息，将用户的任务目标与功能需求、非功能需求、业务规则、解决方案建议及其他无关信息区分开来。 将顶层的需求分配到系统构架内定义好的软件组件中。 了解各质量属性的相对重要性。 协商需求的实现优先级。 将收集的用户需求表述为书面的需求规格说明和模型。 审阅需求文档，以确保在认识上与用户声明的需求相一致。应在开发小组接受需求之前解决所有分岐。,45,需求获取,应收集什么信息： 问题域的描述 要求解决的问题列表（需求） 用户对解系统的行为或结构施加的任何约束 信息来源： 客户（实际的和潜在的） 任何原有解系统（已有系统）及其文档 原有系统用户 / 新系统的潜在用户 应用（问题）领域专家 定义了任何接口系统的特片和行为的文档 相关的技术标准和法规,需求获取技术,阅读背景资料 头脑风暴 讨论分析 文档考古 面谈（用户访谈） 联合应用设计 用户调查 需求剥离,现场观摩 任务观察 用例和场景,需求获取的误区,缺乏计划性：随意、走过场，预先没计划 缺乏科学性：未从本质入手 捕获对象不明确，甚至造成岐义 过于迷信现有文档 过于迷信“听”到的东西,需求分析,所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明 分析方法：结构化分析法、面向对象分析法、面向问题域分析法 任何分析法，均需描述以下几个方面: 问题域的结构（子域，及子域间关系） 问题域的数据 问题子域的固有属性及行为 问题域中的重要事件及现象 需求：应产生的效果,需求分析何时进行,应该在“业务需求”充分理解，并且收集了最本质的“用户需求”之后就开始需求分析，但并不是等到需求捕获完全做完之后 交替进行，先把握用户需求主要部分，然后在分析的基础上引入系统级的需求（系统的设计与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台 分析的基础上，就会发现更多的不明确项， 更多待捕获的信息，这时就可以生成第二次 的需求调研的计划、问题、素材,需求分析何时结束,需求捕获、分析与建模、规格说明书的编写、需求的验证这个需求开发的循环，是在整个软件开发生命周期中存在的 每一次的循环，都将在需求开发的工作要点与份量上有所不同，它们应该遵循以下： 从本质到边缘：本质、重要、次重要、一般、镶金 细化阶段是需求开发最密集的阶段 构建阶段需求开发逐渐减少,需求分析内容与形式,需求分析与建模不应该是孤立的行为 ，产生的结果也不一定非得是规范度很高的标准文档，而应该重在分析、重在方法、重在交流、重在解决问题 团队聚在一起，利用白板甚至是纸张，在充分的合作下进行分析与初步建模是成本最低、效率最高、实用性最强的方法 对于这些活动所产生的结果，可以利用数码相机、扫描仪进行文档化 ，“直到你一定要用时，再写文档” 对于比较重要、核心的内容，再采用 rose、together这样的工具进行文档化,编写规约,规格说明书是对需求分析结果的文档化过程 比较“正规”的开发组织都会重视这个活动，甚至可以说是“重视过度”，而且产生出来的文档经常是与实际的开发脱离，完成之后就束之高阁，再也不使用、不更新。这是一个需求崩溃的信号 规格说明书的格式与所采用的开发过程、分析方法相关的，不同的方法格式不同 定义统一的格式是一个很重要的工作 规约内容的严谨、正确、无岐义是很重要的,需求验证,这个工作大多数组织都不够重视，导致这个工作直到交付系统时才真正被履行，这也就是为什么客户拿到系统后才提出许多这样那样的需求变更，甚至认为整个系统都不是他所需要的 提高需求质量的重要手段： 需求评审 需求确认 通过原型来验证需求,需求开发与需求管理的分界,需求管理,需求管理的任务是“与客户就软件项目的需求达成并保持一致”(paulk et al. 1995)。 需求管理包括下列活动： 定义需求基线(某一时刻，对特定版本中已达成一致的需求内容的描述)。 审查需求变更请求，评估其可能产生的影响以决定是否批准。 以可控的方式将准的需求变更融入项目中。 保持项目计划与需求的同步。 估计需求变更的影响，在此基础上协商新的需求约定。 跟踪每项需求，找到与其对应的设计、源代码和测试用例(test case)。 在项目开发过程中，始终跟踪需求的状态和变更。,56,需求基线管理,频繁的需求变更会破坏开发的节奏，使整个项目开发的进度陷入混乱和失控的状态，而且会变成一个“救火队”式的工作，整天都在处理突发事件 将所有现在的、将来的需求进行优先级评估，然后分解成为不同的组，每次迭代都选择其中优先级最高的部分进行开发，然后在迭代完成之前，开发工作不响应变更，这些划入的需求项就是需求基线的组成部分,需求基线管理操作思路,我们应该在分析的基础上，将需求整合成为用例或功能项，然后对其进行优先级、依赖性进行综合性评估 优先级判断：业务人员确定业务决定，技术人员确定技术决策；“满意度/不满意度”模型 依赖性是指对于某些功能，在实现上有必须的依赖关系，即当某些功能没有实现时，另外的功能无法开始，这就需要对其进行调整,需求变更管理,需求变更是一定存在的，而需求变更管理并不是指逃避它，更不是说要避免它，它实际上是希望控制变更 在基线内的需求不响应变更，为开发人员提供一个安静的工作时间状态 专门的需求变更管理来对所有的需求变更进行响应，了解需求变更的关键意图、新产生的工作量，从而良好地进行重新计划，以便能够有效地解决其对整个开发带来的麻烦,需求变更管理变更的流程,提出变更：正式的方式提交变更是很重要的，合约式的沟通平台 变更评估：合理性评估，进一步了解其变更的主要原因，认清其是否是因为沟通上的误会与不理解而造成的不必要的变更；工作量评估则是评估其对进度的影响；影响面分析则是评估该变更会对哪些部分工作产生影响，具体地说会对哪些人的工作产生影响 分级响应评估：不影响相关模块开发进度的，可直接响应；影响本模块开发进度但不影响项目总体进度的，可由项目经理协调后直接响应；影响项目进度的，则应该交与客户协商响应方式,需求跟踪,需求的跟踪是指对需求的完成情况、变更影响进行系统化的跟踪与处理 “需求是不是已经被实现？”、“需求的变化将需要修改哪些设计元素？会影响谁的工作？对已经完成的部分是否有影响？”,需求管理的参与者,需求分析师,需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者，是用户群体与软件开发团队间进行需求沟通的主要渠道 典型活动：定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求 必备技能：倾听、交谈和提问的技巧，分析、 协调、观察、写作、组织、建模、人际交 往和创造能力,需求分析师,必备知识：现代需求管理技术、各种软件开发生命周期、领域知识 需求分析员的来源：用户转为分析员（软件工程知识欠缺）、开发人员转为分析员（领域知识、沟通能力）、主题专家（易按自己的偏好来构建系统）,需求过程,需求过程,agenda,需求的基本概念与原理 需求工程 需求定义最佳实践 需求捕获最佳实践 业务流程与规则分析 数据需求分析与建模,对问题进行了正确的定义 意味着成功解决了问题的一半,讨论,你认为需求定义的目标是什么？ 通常需求定义在什么阶段进行？ 其主要的产物是什么？,信息系统立项前的分析方法,gpoa方法：goalproblemoptionanswer,信息系统立项前的分析方法,g（目标）：要确定需要开发某个信息系统之前，应该分析其应该达到的目标：业务性、可度量 p（问题）：要达到该目标所需解决的问题！ o（选项）：针对这些问题可选的解决方案 a（答案）：针对各种option进行分析、评估，最终确定答案。,信息系统立项可行性分析,确定目标：信息系统实现前，信息系统实现后 提出解决方案：分析p，给出o，得出a 可行性分析： 效益分析：经济可行性，投资回报 社会可行性 技术可行性,信息系统立项时的常见误区,目标：含混不清，过为宏观 solution: 基于业务需求思考 解决方案：思路过于受限 solutions: 只想what，别想how 了解、理解it技术 期望值：脱离现实 发起人、用户、使用者想法不一致,框定问题的技巧,问题的定义是需求工作的第一步，也是最重要的一步。 问题是否能够解决，通常与是否能够更好、更准确地框定问题相关。 例如，经典的马的遍历问题： 寻找一系列的移动步骤，使 马走完每个方块，而落入任 何一个方块一次：,框定问题的技巧,框定问题的技巧,软件需求第一和可能最重要的步骤是框定问题把问题的特定部分，以及部分间特定的关系，放入一个特定的形式中。问题框定方法应使问题的细节适合一个简单连贯的框架 同时，这也表现出，深入地理解问题域的知识，正确地抓住其本质特性，是十分重要的。 （你的灯还亮着吗？）,框定问题的技巧,问题：日内瓦湖上的山脉中建成了一条很长的汽车隧道，为了防止停电时发生灾难，必须提醒司机进入隧道之前把车灯打开。 解决方案一：“警告！前有隧道请打开车头灯” 新问题：隧道出口风景很美，返回时发现汽车没电忘了关车头灯！ 解决方案二：出口处立标牌“关掉车灯” 新问题：夜行车也会关掉车灯？ 解决方案三：建充电站 新问题：维护开支大，充电站也会出故障,框定问题的技巧,解决方案四：授权私人经营充电站 新问题：风景区商业化，政府与游客均不接受 解决方案五：在隧道尽头，树立新标牌 如果是白天，并且车灯开着，请熄灭车灯； 如果天色已晚，并且车灯没开，请打开车灯； 如果是白天，并且车灯没打，就别打开它； 如果天色已晚，并且车灯开着，请别关掉它。 新问题：谁能在行驶时读完？！ 终极解决方案：你的灯亮着吗？,问题分析的五个步骤,问题分析：理解真实世界中的问题和用户的需求并提出满足这些多方面要的解决方案的过程 在问题定义上达成共识 理解根本原因问题背后的问题 确定风险承担人和用户 定义解决方案系统的界限 确定加在解决方案上的约束,在问题定义上达成共识,把问题写下来，看每个人是否都同意 采用标准化格式： 问题：描述问题 影响：确定受问题影响的风险承担人 结果：确定问题对风险承担人和商业活动的影响 成功的解决方案：指出解决方案并列出主要优点,理解原因后对问题的陈述,问题：不准确的订单 影响：订单操作者、客户、生产者、销售者及客服 结果：增加废品、额外处理成本、客户不满及收益降低 成功的解决方法： 增加了输入点订单的准确性 增加了销售数据的报告以便进行管理 获得更好的效率,理解原因后对问题的陈述,问题：随时提供大学体育赛事的最新报道 影响：移动办公的人群 结果：他们不可能花很多时间来搜索他们感兴趣的新闻，因此无法随时了解到有关他们母校的赛事（或者他们感兴趣的其他大学的体育赛事）。 成功的解决方法：当发生他们感兴趣的新闻时，向他们发出通知，并提供一个地点来为他们提供所请求的新闻。,理解根本原因问题背后的问题,tqm的鱼骨图,帕雷托图,确定风险承担人和用户,系统的用户是谁？ 系统的客户是谁？ 还有哪些人会受系统输出的影响？ 系统完成并投入使用后，有谁会对它进行评估？ 还有没有其他系统内部或外部用户，他们的需要有没有必要被考虑到？ 系统将来由谁维护？ 还有其他人吗？,定义解决方案系统的界限,谁会对系统提供信息？谁会在系统中使用信息？谁会从系统中删除信息？ 谁将操作该系统？ 谁是系统的维护者？ 系统将会在哪儿被使用？ 系统从哪儿得到信息？ 哪些外部系统要 和系统进行交互？,定义解决方案系统的界限,不好！大部分工 作都留给操作员了,常见划分，但 可以更好,订单接收自动化,顾客缺货前提醒,确定加在解决方案上的约束,经济约束：预算？ 行政约束：存在许可问题？潜在内外部政问题？部门间问题？ 技术约束：技术选择有何限制？限制在已有平台或技术上？禁止使用新技术？需要购买软件包？ 系统约束：建立在现有系统上？需要维护与原系统的兼容性？必须支付什么操作系统？ 环境约束：合法吗？安全性要求？其他标准限制？ 进度及资源：进度要求？已有资源？外部劳动力可用否？有无扩展资源？,确定加在解决方案上的约束,操作性：销售订单数据必须在数据库中备份一年，因为数据丢失风险太大，需并行运行至少一年的数据 系统及操作系统：应用在服务器上占用不超过200m，因为服务器上存储空间有限 设备预算：必须在已有服务器和主 机上开发 人员预算：固定的人力资源，没有外部资源 技术要求：应用新的面向对象的方法,项目定义业务需求,产品/项目的目的：对业务目标的简短、可度量的描述 客户：为谁构建？ 顾客 ：谁会购买？ 风险承担者：哪些人在产品中拥有既得利益？ 用户：谁将操作它？他们的能力如何？ 限制条件：必须采用某设计方案？时间？经费？ 名称：该项目使用哪些术语？ 相关事实和假定：每个人都需要知道什么？ 工作的范围：什么是产品和项目的边界？ 估算的费用：需要花费多少工作量或资金 风险：面临的主要风险,项目定义目标的六要素,目标：精确预报道路结冰时间并分派除冰卡车 业务优势：通过预报道路结冰情况来减少道路事故 度量：因结冰而发生的事故数年将低于冬季发生的事故总数的15% 合理性：消除因结冰而发生的事故而减少的损失，与构建该系统所花费的成本和工作量相比，是否有价值？ 可行性：及时地除冰能否减少事故的发生？会降到总数的15%以下吗？ 可达成性：该目标能达到吗？,项目定义风险承担人与用户,用户：与主题相关的经验、技术上的经验、智力能力、对工作的态度、对技术的态度、受教育程度、语言技能、年龄、性别 风险承担者：用户、客户、顾客、管理者、业务主题相关者、开发人员、检查人员、市场力量、法律方面、反对者、专业团体、公众意见、政府、特殊利益团队、技术专家、文化利益、相邻系统 （stakeholder解析）,项目定义文档前景文档,业务需求 背景：新产品的来由与背景 业务机遇 业务目标与成功标准 客户与市场需求 业务风险 解决方案的前景 前景说明(目标客户、需求与机会、竞争对手与优势) 主要特性 假设与依赖,项目定义文档前景文档,范围与限制 第一个版本的范围 各后续版本的范围 限制与排除 业务背景 涉众简介 项目优先级 操作环境,需求心理学常见现象,言过其实心理：说的流程是一种理想化流程，与实际情况严重不符 越俎代疱心理：对非自己处理的流程津津热道，根据自己的理解、想像进行肯定的描述 非正事心理：一直忙于工作，无瑕配合需求调研 抗拒心理：新系统对其利益有损，故意不配合 推卸责任心理：装不知，说没需求,需求变化的预期,流程变化：流程顺序变化，流程细节变化，流程负责人变化，流程输入变化，流程输出变化。 数据变化：数据格式变化、数据规则变化、数据输出变化、数据项变化 业务规则：规则增加、规则减少、规则变化 系统表现形式变化：界面、风格、输入形式、 展现方式、访问方法、网络环境 目标变化,agenda,需求的基本概念与原理 需求工程 需求定义最佳实践 需求捕获最佳实践 业务流程与规则分析 数据需求分析与建模,需求捕获是一个探索的过程 是一个有计划、科学性的过程,讨论,平时需求捕获怎么做？ 需求捕获有哪些方法？ 主要的优缺点是什么？ 在需求捕获过程中遇到的主要障碍有哪些？,需求捕获的主要障碍,大多数情况下，系统相关的人员无法陈述自己的需要 许多用户难以解释所执行的任务，更难解释为什么执行这些任务 相关人员经常指定解决方案而不是需求 相关人员也难以构想出新的工作方法，或者想像出使用提供的方法执行熟悉的任务所能够得到的结果 不同的相关人员可能持有相互矛盾的观点 相关人员经常出于抵制变更而拒绝新系统 需求可能过多过度的需求 需求随着时间而变化,需求捕获的各方职责,由需求分析师策划，由需求分析师、用户和其他风险承担者积极合作完成。 用户、顾客和客户：有责任向需求分析师提供他们的工作知识 需求分析师：理解用户所说的关于工作的事情，并将其解释成产品的需求规格说明 观察和学习该项工作，从用户角度来理解它 用户对某项工作的描述必须作为事实来对待，要发现工作的本质，而非表象 发明完成该工作更好的方法 以需求规格说明书和分析模型的方式记录,用户在需求捕获过程中的角色,作为设计组、专题讨论会的成员，参与设计用户界面 作为知识来源，提供任务、商业过程的当前执行情况 参与集策讨论会，提供构想、确定问题 作为测试用户，在验收时测试系统检查能否正常工作 作为审查者评估用户界面 进行可用性测度，尝试使用新的用户界面执行任务 作为项目管理委员会成员,用户的各种需求,意识到的需求：是指那些用户最先想到的需求，常常表明用户希望改进的一些事情 无意识的需求：是指那些用户没有言明的事情，因为用户对它们知道得太多，以致于他们假定其他任何人都具备同样的知识 未梦想过的需求：是指那些一旦用户认识到它们可能就会要求的事情,系统化地组织需求捕获,术语表、域建模、领域培训这些都是因地制宜的业务建模的常见工具。（wiki） 与业务流程相关的系统，最重要的是：置身于流程之中，分析信息、工作流。 从“组织结构与岗位设置图”所体现的管理层次与线条建立全局了解；-参与者的来源； 针对业务流程，绘制出跨部门职能流程图，以帮助开发人员对客户方的业务流程建立宏观、清晰的认识，以便更加有的放矢地进行进一步的需求捕获工作。,跨部门职责流程图,跨部门职责流程图,系统化地组织需求捕获,应该搜集什么信息？细化地研究流程图，看看是否已经对每个环节、每个步骤都清楚地认识了。我们应该根据自己的理解首先对每个流程的工作进行定义，写出事件流，并且标识出疑问点，这些都将使我们明白“应该收集什么信息”。 从哪搜集这些信息？流程涉及到什么部门、岗位，答案就应该从谁身上找。 用什么机制来搜集？需求捕获技术有多种，重点在于因地制宜地使用不同的机制,主要需求捕获技术比较,主要需求捕获技术比较,用户访谈,用户访谈：最基本、最常见的技术 利：直接有效、形式灵活、交流深入，应该做为主要的需求捕获技术（宽带通信、固有灵活性、各类信息） 弊：占用时间长（特别当客户忙时更显示出其不足）、面窄而容易造成信息的片面性。 要点：首先要有准备：通常包括说明对流程的理解，并征得客户的意见；预先根据流程中的不明确点设计要询问的问题，并将客户的反馈记录下来；应留有一些即兴的空间，根据实际情况应变，以确保信息完善。第二是要有计划性：计划好时间、计划好人员、计划好策略。,用户访谈：特点,最传统的方法，单独使用并不有效，通常别期望用户知道并能够说出他们的需求 应先草拟一份问卷，向要访谈的用户发出一份涉及访谈主题和时间安排的材料 在访谈的过程中，及时用草图绘制模型（dfd、用例、思维图），从而得以及时反馈 应以业务事件为谈话的中心， 问问题，听取回答，然后反馈理解,用户访谈：准备工作,围绕目标制订一个计划，包括一组按逻辑方式分组和排序的问题 在计划内应有时间在结束时检查是否已涵盖所有问题，并理解对所有问题的答复 不要超过1小时，否则应安排下一次面谈 地点选择：适当的不受干扰和避免打扰 记录：自己做笔记（分神）、专门一同事做笔记（成本高）、录音 （失去身体语言）/录像（难操作）自己做笔记+录音,用户访谈：通用问卷,建立客户或用户情况表 姓名、职位等基本信息 你的主要职责是什么？ 你们的主要输出是什么？ 为谁做的？ 如何测试成功? 什么问题阻挠你们的成功? 如果有，什么使你的工作更容易或更困难,用户访谈：通用问卷,评估问题 你对哪种问题缺乏好的解决方案？ 它们是什么？（提示：不断问“还有吗？”） 对每个问题，问： 为什么存在这个问题？ 现在你怎么解决它？ 你打算怎么解决它？,用户访谈：通用问卷,理解用户环境 谁是用户？ 他们的教育背景如何？ 他们的计算机背景如何？ 用户经历过这种类型的应用吗? 使用的是哪一种平台？计划将来的平台是什么？ 有没有用其他和该应用有关的应用？如果有简单介绍 对产品可用性的预期是什么? 你需要什么样的用户帮助（在线文档、纸介质？）,用户访谈：通用问卷,简要说明理解情况 你刚才告诉我（用自己的话列出客户所述问题） 这是否足以表达你认为现在存在的问题？ 如果还有，那是什么问题？ 分析人员对客户问题的输入 (有效或无效的假设)，如果有，问题与什么有关？ 对于每个建议，提问: 这是一个实际的问题吗？产生的原因是什么？ 你是怎么解决这个问题的？希望怎么解决？ 和你提到的其他问题相比，这些问题 的位置如何？,用户访谈：通用问卷,评估你的解决 (总结你建议的解决方案的主要功能) 如果你能够 对于这些的重要性，你是如何排序的？ 评估机会 在你的单位中，谁需要这样的应用？ 使用这种应用的用户有多少? 如何评价一个成功的解决方案?,用户访谈：通用问卷,评估可靠性、性能及支持的需要 你对可靠性的预期是什么？ 你对性能的预期是什么？ 是你还是其他人来支持该系统？ 你对支持还有特别的要求吗？ 维护及服务如何? 安全需求是什么？ 安装和配置需求是什么？ 有什么特殊的许可需求吗？,用户访谈：通用问卷,其他需求 有必须支持的法律、法规、环境需求或标准吗？ 你还能想到其他我们应该知道的需求吗? 总结性提问 我还有其他问题应该问你吗？ 如果我还问你其他问题的话，可以打电话给你吗？你愿意参加需求审阅吗？ 分析人员总结：面谈后，趁你记得时，总结 出用户/客户确认的三条最高优先级的需求或 问题,用户访谈：操作法,避免类似以下暗示：我的时间比你宝贵，我不知道我在做什么，你不知道你在讲什么 用简单的语言清楚地表达问题，采用对方的术语和行话 不要遗漏任何事情 能够找到和探究异常现角，例如 对未预料问题的反应 不要搞错基本信息流要求的方向,用户访谈：询问的问题,问题类型：待解决的问题、开发解决方案的过程、需求获取本身 需求获取本身的问题： 我的问题看起来相关吗？你的回答正式吗？ 你是回答这些问题的最佳人选吗？ 我问了太多的问题吗？ 还有其他什么我该问你的？ 你想问我什么？ 我还应该见其他什么人？ 关于这个项目有什么人我们不需要？,用户访谈：主要困难,缺乏对所需要的人的访问（知道最多的人最忙） 在面谈时记录信息很困难 被访谈人会试图说他们认为你想要听的话 访谈人用诱导性问题提问 束缚关键职员的有关费用 由不同领域知识和行话引起的交流困难 隐蔽的动机和组织政策产生错误信息,用户调查：概述,用户调查：调查面最广的技术 利：面广，能够获得更多的人的反馈。这点是对用户访谈技术不足之处的最好补充。 弊：不够深入，容易形而上学。而这点是正是用户访谈技术所能够解决的。 要点：结合用户访谈技术使用，具体来说：先设计问题，制作成为用户调查表，下发填写完后，进行仔细的分组、整理、分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作为补充。,用户调查：主要用途,搜索某项假设的统计依据：设计一些封闭的问题，例如“从现有系统中取得客户统计资料的难易程度：非常困难、相当困难、容易、非常容易” 搜索意见、建议：询问与用户访谈类似的开放性问题，例如“日常工作中的三个最大问题是什么？”，“你对能够更好地支持日常工作的it系统有什么建议”。-误解你的问题，你误解他的回答,用户调查：主要困难,相关的问题不能事先决定 问题背后的假设对答案会造成偏颇 例如：这功能符合你的期望吗？ 假设：你有期望，所以这是一个有意义的提问 难以探索一些新的领域，也没有探索新的需要被探索的领域的交互 难以继续用户的模糊响应,用户调查示例,现场观摩：概述,现场观摩：最生动的技术 利：百闻不如一见，能够对需求与业务流程建立直观的认识。 弊：消耗时间长，而且由于“被观摩”的微妙心理变化，会使得“观摩”失真。 适用性：要对于复杂流程的更加深入的 理解时。 要点：悄悄地进行，明确要强化理解的 具体流程环节。,现场观摩：常用变体,任务示范：要求用户示范如何执行特定的任务 利：可用于发现异常的、关键性的任务 弊： “示范”失真、耗时 做学徒：和用户坐在一起，通过观察、问问题、并在用户指导下完成一些工作来学习 适用性：用户无法详细解释清楚他们在做什么时 “人们正在做一件事时，最能解释他们在 做什么，为什么要这么做” 需求分析员可以通过学徒关系试验他的 需求和设计思想,文档考古：概述,文档考古：最贴近实现的技术 利：能详细、直观地对数据流细节进行了解与分析。 弊：易陷入文山书海之中不可自拔， 甚至常引起误导。 要点：应该尽量让客户提供写有真 实数据的文档。 特点：从旧的工作材料中挖掘新的需求 检查收集的文档 ，从中找出名词，或 “东西”，包括列标题、命名的表格区域 涉及内容：文档、打印输出、清单、 手册、屏幕等,文档考古：常用思考点,此物的目的是什么？怎么用它？为什么用它？用它做什么？系统都利用它来做些什么？ 哪些业务事件用到或引用了此物？此物会有一个值吗？是数字、代码、数量？如果是这样的话，它属于哪些东西的组成体？ 此物的用途是什么？ 文档中是否包含了一组重复的事物？如果是这样的话，这些事物的集合称为什么？,文档考古：常用思考点,我能找到事物之间的联系吗？ 什么过程建立了它们之间的联系？ 每件事物附加的规则是什么？换句话说，哪部分业务策略涉及该事物？ 什么过程确保了这些规则会被遵守？ 什么文档给用户最多问题？,建议：做为数据建模方法的一部分,文档考古：优缺点,优：获取信息相对比较直接，获得系统所有输入、输出及内部文档（但不应假定已获得全部描述）；有助于数据模型分析。 缺：文档说明的系统与实际系统可能是不匹配的；文档考古的传统分析方式（如开发文档流图）可能导致产生现有系统的结构模型，从而带入新系统,联合开发：概述,联合开发：最理想的技术 利：客户、开发人员直接的头脑风暴，是击破需求盲点的关键手段。 弊：成本高，如果缺乏控制会变成一次闲扯大会。 要点：需要有一个经验丰富、能够把控大局的主持人。,联合开发：优点,协助建立一支高效的团队，围绕一个目的：项目成功 所有风险承担人都畅所欲言，没人被落下 正如应用项目所必须做的，它促进风险承担人和开发团队之间达成共识 它能够揭露和解决那些妨碍项目上成功的行政问题 能够产生一个在特征级别上的初步系统定义,联合开发：准备工作,推销概念：充分的准备是联合开发的关键，推销联合开发（需求专题讨论会）的好处 确保真正的风险承担人参与 后勤保障 热身材料：在开会前散发资料 项目专有信息：需求文件草案、已排序的特性 摆脱束缚思想的：提供创新方法、自由讨论规则 2天1周内散发，太早会使人忘记！,联合开发：准备工作,备忘录 收件人：xxx项目的风险承担人 主 题：即将召开的需求专题讨论会 我是xx产品（项目）的管理者。这个项目已经（或即将）于 开始并截止于 完成。 （我们了解它，我们是认真的，我们想要按时完成它） 正如大多数的项目一样，获得关于应用项目的新特征的共识并定义一个最初的基本系统来 满足不同风险承担人的需要是十分困难的。 （它甚至比在这个组达成任何其他共识更，因此我们将尝试一些不同的方法） 为了使这个过程更加容易，我们将召开一次关于 的需求专题讨论会。 专题讨论会的目标是：为产品的下一个基线版本确定新特性。为了做到这些，听取每一个 风险承担人的意见就极为重要。专题讨论会将由 来主持，他是一位经验丰富的需求管理联 络员。 （作为风险承担人，我们可能也有偏见，从外面聘请主持人可以使其更公平） 专题讨论会将很快得出结果，并在第二天将结果分发给开发部。我们热忱地邀请您参加专 题讨论会并提出代表你的（团队、部门、用户）需求的意见。如果您无法参加，我们热切地希 望你能够授权一名代表您的需求的成员参加。 （会后第一天我们将开始工作；如果你希望对项目提出什么意见，请到这里来，或授权一 名代表来。换句话说，要么现在说，要么永远别说。） 备忘录中有一个关于当前产品期望特征的简短说明，以及其他关于专题讨论会和自由讨论 进程的资料。专题讨论会将于上午8:30开始，下午5:30结束。 （这个专题讨论会以及该项目将按专业要求运作，需要你们来建议，使项目更顺利） 热切期盼在会场上见到您。 项目领导人,联合开发：联络员,联络员：熟悉该过程，有风度受尊重，团队外成员 主要职责 在会议中建立一种专业、客观的基调 按时开始、结束会议 建立并维持会议“规则” 为会议订立目标和议程 管理会议进程并保持在“正确轨道” 提供一种决策和达成共识的机制 管理设施和后勤保障事务 确定所有风险承担人都在参加 控制混乱或没有意义的行为,联合开发：安排日程,08:0008:30 介绍 议程、设备、规则 08:3010:00 情况简介 现状、需要、面谈结果 10:0012:00 自由讨论 应用特性 12:0013:00 午餐 13:0014:00 自由讨论 继续 14:0015:00 特征定义 写出23句话的特征定义 15:0016:00 意见精简与优先级排序 16:0017:00 总结和操作议项,联合开发：组织技巧,中间休息 迟到,规则：每人先发一张，允许迟到一次 而后向罚款箱投入xx元 目的：保持会议的动向,5分钟发言,好主意！,1次自由 廉价攻击,规则：每人先发一张，允许自由攻击 或批评任何个人或部门，而后 再出现就向