需求评估培训.ppt

day01 需求评估培训 agenda 需求的基本概念与原理需求工程需求定义最佳实践需求捕获最佳实践业务流程与规则分析数据需求分析与建模 agenda 需求的基本概念与原理需求工程需求定义最佳实践需求捕获最佳实践业务流程与规则分析数据需求分析与建模 1 理论是实践的基础2 解决概念性的误区 讨论 你认为 什么是需求 日常工作中 遇到与 需求 相关的问题有哪些 关于 需求 最大的困惑是什么 以下问题中 对你影响最大的是哪个 不切实际的用户需求 很多需求最终是不需要的 用户介入太少 需求不完整 需求变更频繁 软件需求的定义 软件行业存在这样一个问题 用于描述需求工作的术语没有统一的定义 对同一项需求 不同的人会有不同的描述 称其为用户需求 软件需求 功能需求 系统需求 技术需求 业务需求或产品需求 客户对需求的定义 在开发人员看来可能只是高级别的产品概念 而开发人员的需求概念对用户来说也许就是详细的用户界面设计 需求必须被记录成文档 这一点很重要 5 对需求的不同解释 ieee的软件工程标准术语表 1990 则将需求定义为 用户为解决某个问题或达到某个目标而需具备的条件或能力 系统或系统组件为符合合同 标准 规范或其他正式文档而必须满足的条件或必须具备的能力 上述第一项或第二项中定义的条件和能力的文档表达 6 注意 不要一厢情愿地认为项目涉众对需求的理解是一致的 应该事先给出定义 才能保证大家谈论的是同一个问题 需求 导致项目失败的罪魁祸首 根据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 软件需求曾经让我们如此狼狈 参与各方都以自已角度讲述问题 分布式webservices三层对话框菜单条dcomb s数据交换 财务计算管理报表工作流自动库存控制库存报警业务线索管理业务经线索跟踪销售月报生成交易流数据 问题的根源是什么 用户说的不是他想的 客户提供 陈述的需求 的需求并不是真实的需求 还需要作进一步的分析 以确定客户的真正需求和期望 接下来需要澄清并重新描述 可以这么说客户在理解基础业务过程和描述自己的需求方面有很大的差异 需求分析方法有问题 系统开发人员使用低效的需求分析和项目管理方法 共同责任强调不足 对客户和提供商在项目成功的共同责任方面强调不够 优秀的团队遇到糟糕的需求 用户参与不足用户需求扩展有歧义的需求镀金问题过于抽象的需求忽略某种用户不准确的计划 用户参与不足 开发人员往往也不重视用户的参与 原因是他们认为与用户打交道不像写代码那么有趣 或者自以为已经知道了用户想要什么 用户参与不足将导致不能在项目早期及时发现需求中的缺陷 从而延误项目的完成 在整个项目开发过程中 开发团队必须始终与实际用户直接合作 14 用户需求扩展 由于开发过程中需求的不断发展与增加 项目往往会落后于计划的进度并超出预算 出现这种情况是因为没有依据对需求的规模和复杂度的实际评估来制订计划 而不断修改需求又使情况变得更糟 问题的责任部分在于用户不断提出修改需求的要求 部分在于开发人员处理这种要求的方式 要控制项目范围的改变 首先应明确项目的业务目标 全局规划 范围 限制 成功标准以及产品的预计用途 然后参考这一框架对所有新特性和需求变更进行评估 15 有岐义的需求 岐义表现为同一读者可以对一项需求声明作出多种解释 或者不同的读者对同一需求产生不同的理解 岐义会导致以下几点 涉众对产品怀有不同的期望 因此最终交付的产品会让部分人感到意外 有岐义的需求使开发人员的时间浪费在解决无需解决的问题上 有岐义的需求导致测试人员与开发人员对产品功能的理解不同 从而使测试人员也要浪费时间来解决这些差异 消除歧义的办法之一是让代表不同观点的人对需求作正式的检查 16 镀金问题 开发人员为产品添加了一项需求说明中没有提到的功能 他认为 用户肯定会喜欢的 这就是所谓的 镀金问题 goldplating 开发人员和需求分析员不应擅自添加特性 应该把创意和备选方案提交给客户 让他们做决定 要避免镀金问题 就应该追溯每项功能的来源 弄清楚为什么添加该功能 17 过于抽象的需求 营销人员或经理经常喜欢只给出一个粗略的说明 他们希望开发人员在开发过程中充实它 这种方式对研究性项目或需求特别灵活的项目或许管用 但是需要紧密合作的团队 而且仅限于开发小型系统 mcconnell1996 大多数情况下 这种做法的结果是使开发人员受挫 让客户失望 18 忽略了某类用户 用户所使用的产品特性 产品的使用频率以及用户自身的经验水平不尽相同 因此 多数产品都拥有不同的用户群 如果一开始没能找出产品的所有重要用户群 就会有某些用户需求得不到满足 确定所有用户群后 还要保证获得各类用户的需求 19 不准确的计划 不能充分理解需求 就会作出过于乐观的估计 最终不可避免地陷入超支的泥潭 造成软件成本估算失败的最主要原因包括频繁变更需求 遗漏需求 未与用户充分沟通 需求的说明不精确 以及对需求的分析不透彻 davis1995 等 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和moore2001 这些子学科涵盖了为软件和软件相关产品收集 评估和记录需求相关的所有活动 包括 确定产品将要面对的各类用户 从各类用户的代表处收集需求 了解用户的任务和目标 以及这些任务要实现的业务目标 分析从用户处得到的信息 将用户的任务目标与功能需求 非功能需求 业务规则 解决方案建议及其他无关信息区分开来 将顶层的需求分配到系统构架内定义好的软件组件中 了解各质量属性的相对重要性 协商需求的实现优先级 将收集的用户需求表述为书面的需求规格说明和模型 审阅需求文档 以确保在认识上与用户声明的需求相一致 应在开发小组接受需求之前解决所有分岐 45 需求获取 应收集什么信息 问题域的描述 要求解决的问题列表 需求 用户对解系统的行为或结构施加的任何约束信息来源 客户 实际的和潜在的 任何原有解系统 已有系统 及其文档 原有系统用户 新系统的潜在用户 应用 问题 领域专家 定义了任何接口系统的特片和行为的文档 相关的技术标准和法规 需求获取技术 阅读背景资料头脑风暴讨论分析文档考古面谈 用户访谈 联合应用设计用户调查需求剥离 现场观摩任务观察用例和场景 需求获取的误区 缺乏计划性 随意 走过场 预先没计划缺乏科学性 未从本质入手捕获对象不明确 甚至造成岐义过于迷信现有文档过于迷信 听 到的东西 需求分析 所谓分析是指通过对问题域的研究 获得对该领域特性及存在于其中 需要解决 的问题特性的透彻理解并用文档说明分析方法 结构化分析法 面向对象分析法 面向问题域分析法任何分析法 均需描述以下几个方面 问题域的结构 子域 及子域间关系 问题域的数据 问题子域的固有属性及行为 问题域中的重要事件及现象 需求 应产生的效果 需求分析 何时进行 应该在 业务需求 充分理解 并且收集了最本质的 用户需求 之后就开始需求分析 但并不是等到需求捕获完全做完之后交替进行 先把握用户需求主要部分 然后在分析的基础上引入系统级的需求 系统的设计与实现角度 并且分析模型 成为开发人员之间 开发人员与客户之间达成共识的一个平台分析的基础上 就会发现更多的不明确项 更多待捕获的信息 这时就可以生成第二次的需求调研的计划 问题 素材 需求分析 何时结束 需求捕获 分析与建模 规格说明书的编写 需求的验证这个需求开发的循环 是在整个软件开发生命周期中存在的每一次的循环 都将在需求开发的工作要点与份量上有所不同 它们应该遵循以下 从本质到边缘 本质 重要 次重要 一般 镶金 细化阶段是需求开发最密集的阶段 构建阶段需求开发逐渐减少 需求分析 内容与形式 需求分析与建模不应该是孤立的行为 产生的结果也不一定非得是规范度很高的标准文档 而应该重在分析 重在方法 重在交流 重在解决问题团队聚在一起 利用白板甚至是纸张 在充分的合作下进行分析与初步建模是成本最低 效率最高 实用性最强的方法对于这些活动所产生的结果 可以利用数码相机 扫描仪进行文档化 直到你一定要用时 再写文档 对于比较重要 核心的内容 再采用rose together这样的工具进行文档化 编写规约 规格说明书是对需求分析结果的文档化过程比较 正规 的开发组织都会重视这个活动 甚至可以说是 重视过度 而且产生出来的文档经常是与实际的开发脱离 完成之后就束之高阁 再也不使用 不更新 这是一个需求崩溃的信号规格说明书的格式与所采用的开发过程 分析方法相关的 不同的方法格式不同定义统一的格式是一个很重要的工作规约内容的严谨 正确 无岐义是很重要的 需求验证 这个工作大多数组织都不够重视 导致这个工作直到交付系统时才真正被履行 这也就是为什么客户拿到系统后才提出许多这样那样的需求变更 甚至认为整个系统都不是他所需要的提高需求质量的重要手段 需求评审 需求确认 通过原型来验证需求 需求开发与需求管理的分界 需求管理 需求管理的任务是 与客户就软件项目的需求达成并保持一致 paulketal 1995 需求管理包括下列活动 定义需求基线 某一时刻 对特定版本中已达成一致的需求内容的描述 审查需求变更请求 评估其可能产生的影响以决定是否批准 以可控的方式将准的需求变更融入项目中 保持项目计划与需求的同步 估计需求变更的影响 在此基础上协商新的需求约定 跟踪每项需求 找到与其对应的设计 源代码和测试用例 testcase 在项目开发过程中 始终跟踪需求的状态和变更 56 需求基线管理 频繁的需求变更会破坏开发的节奏 使整个项目开发的进度陷入混乱和失控的状态 而且会变成一个 救火队 式的工作 整天都在处理突发事件将所有现在的 将来的需求进行优先级评估 然后分解成为不同的组 每次迭代都选择其中优先级最高的部分进行开发 然后在迭代完成之前 开发工作不响应变更 这些划入的需求项就是需求基线的组成部分 需求基线管理 操作思路 我们应该在分析的基础上 将需求整合成为用例或功能项 然后对其进行优先级 依赖性进行综合性评估优先级判断 业务人员确定业务决定 技术人员确定技术决策 满意度 不满意度 模型依赖性是指对于某些功能 在实现上有必须的依赖关系 即当某些功能没有实现时 另外的功能无法开始 这就需要对其进行调整 需求变更管理 需求变更是一定存在的 而需求变更管理并不是指逃避它 更不是说要避免它 它实际上是希望控制变更在基线内的需求不响应变更 为开发人员提供一个安静的工作时间状态专门的需求变更管理来对所有的需求变更进行响应 了解需求变更的关键意图 新产生的工作量 从而良好地进行重新计划 以便能够有效地解决其对整个开发带来的麻烦 需求变更管理 变更的流程 提出变更 正式的方式提交变更是很重要的 合约式的沟通平台变更评估 合理性评估 进一步了解其变更的主要原因 认清其是否是因为沟通上的误会与不理解而造成的不必要的变更 工作量评估则是评估其对进度的影响 影响面分析则是评估该变更会对哪些部分工作产生影响 具体地说会对哪些人的工作产生影响分级响应评估 不影响相关模块开发进度的 可直接响应 影响本模块开发进度但不影响项目总体进度的 可由项目经理协调后直接响应 影响项目进度的 则应该交与客户协商响应方式 需求跟踪 需求的跟踪是指对需求的完成情况 变更影响进行系统化的跟踪与处理 需求是不是已经被实现 需求的变化将需要修改哪些设计元素 会影响谁的工作 对已经完成的部分是否有影响 需求管理的参与者 需求分析师 需求分析员是对项目涉众的需求进行收集 分析 记录和验证等职责的主要承担者 是用户群体与软件开发团队间进行需求沟通的主要渠道典型活动 定义业务需求 确定项目涉众和用户类别 获取需求 分析需求 为需求建模 编写需求规格说明 主持对需求的验证 引导对需求的优先级划分 管理需求必备技能 倾听 交谈和提问的技巧 分析 协调 观察 写作 组织 建模 人际交往和创造能力 需求分析师 必备知识 现代需求管理技术 各种软件开发生命周期 领域知识需求分析员的来源 用户转为分析员 软件工程知识欠缺 开发人员转为分析员 领域知识 沟通能力 主题专家 易按自己的偏好来构建系统 需求过程 需求过程 agenda 需求的基本概念与原理需求工程需求定义最佳实践需求捕获最佳实践业务流程与规则分析数据需求分析与建模 对问题进行了正确的定义意味着成功解决了问题的一半 讨论 你认为需求定义的目标是什么 通常需求定义在什么阶段进行 其主要的产物是什么 信息系统立项前的分析方法 gpoa方法 goal problem option answer 信息系统立项前的分析方法 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 00 08 30介绍议程 设备 规则08 30 10 00情况简介现状 需要 面谈结果10 00 12 00自由讨论应用特性12 00 13 00午餐13 00 14 00自由讨论继续14 00 15 00特征定义写出2 3句话的特征定义15 00 16 00意见精简与优先级排序16 00 17 00总结和操作议项 联合开发 组织技巧 中间休息迟到 规则 每人先发一张 允许迟到一次而后向罚款箱投入xx元目的 保持会议的动向 5分钟发言 好主意 1次自由廉价攻击 规则 每人先发一张 允许自由攻击或批评任何个人或部门 而后再出现就向罚款箱投入xx元目的 逗趣并提醒人们注意发言 规则 每人先发两张 送给提出好建议的人 要尽快给出目的 刺激与会者并奖励提出创新者 规则 每人可以在任何时候使用 让出讲台给他并计时 不得打断目的 允许结构化的即席发言 联合开发 自由讨论与意见精简 每人发25张索引卡片 按以下规则进行自由讨论意见精简 修剪 去掉不值得进一步集体讨论的意见 归类 把意见归类 特征定义 用一句话描述未被删除的意见 确定优先次序 累积投票 百元测试 关键 重要 有用 不允许批评或争吵允许发挥你的想像力产生尽可能多的意见转换和组合想法 情节串联板制作 概述 情节串联板制作 最互动的技术利 用户友好 交互性 对用户界面提供早期评审 易于创建和修改 弊 需求捕获速度慢 情节串联板制作 类型 联合开发 做什么及要点 谁是扮演者他们发生了什么事是怎样发生的不要在情节串联板上投入太多精力如果什么都不变 就什么都学不到不要做得太好 误以为已完成只要可能 就制作交互折 需求捕获的最佳实践 评估系统可行性 进行需求捕获之前 应先进行一个可行性研究 评估现有技术下系统是否能够实现目的 主要效益 提示是否真正需要一个系统 引入成本 低 应用成本 低 中注意组织和行政方面的因素 需求捕获时 必须注意影响需求源和可能会对你隐藏真正系统需求的组织和行政因素 主要效益 有助于理解一些需求被建议的原因 引入成本 低 应用成本 很低 实施要点 注意不一致的目标 责任的丧失或转移 组织文化 组织的管理态度和士气 部门差异 需求捕获的最佳实践 识别和咨询系统的项目相关人员 即那些直接或间接从开发的系统中受益的人 主要效益 发现所有可能的需求源 引入成本 很低 应用成本 低记录需求源 即记录该需求所基于的信息的链接 可以是人员 文档 其他需求 主要效益 来自于初始需求源的需求可跟踪性 引入成本 低 应用成本 低定义系统的操作环境 主动 硬件和软件系统 主要效益 交付系统没有安装问题 引入成本 低 应用成本 低 需求捕获的最佳实践 使用业务关系来驱动需求捕获 业务关系是必须满足的高层目标 应识别 记录这些目标 主要效益 需求集中在核心业务需求上 引入成本 低 应用成本 低寻找领域约束 即来自于系统应用领域的系统需求 主要效益 领域约束经常会导致识别出关键需求 引入成本 低 应用成本 中等记录需求理由 即关于提出某需求的原因 根据系统所需解决的问题来证明需求 是从需求源导出的 主要效益 提高对需求的理解 引入成本 低 应用成本 低 中等 需求捕获的最佳实践