【公务员考试】（行政职业能力测验）机会分配不仅能对收入分配结果产生重要影响，而且会直接影响到社会的经济发展效率。在不公正的机会分配下，一些人会因为某些特殊原因而获得发展机会，但这些获得机会的人很可能缺乏利用发展机会从事社会劳动和创造的能力，这必然导致他们所从事的劳动或经营项目的生产效率在下降，进而影响到整个社会的经济发展效率。让真正有才华的人获得机会，把合适的人放在适合的岗位上，是经济体系健康运行的基础。只有实现机会平等，才能最大限度地激发社会活力和人的积极性、主动性、创造性，提高社会劳动生产率和生产力发展水平。-正解问答-正解网0【公务员考试】（行政职业能力测验）机会分配不仅能对收入分配结果产生重要影响，而且会直接影响到社会的经济发展效率。在不公正的机会分配下，一些人会因为某些特殊原因而获得发展机会，但这些获得机会的人很可能缺乏利用发展机会从事社会劳动和创造的能力，这必然导致他们所从事的劳动或经营项目的生产效率在下降，进而影响到整个社会的经济发展效率。让真正有才华的人获得机会，把合适的人放在适合的岗位上，是经济体系健康运行的基础。只有实现机会平等，才能最大限度地激发社会活力和人的积极性、主动性、创造性，提高社会劳动生产率和生产力发展水平。这段文字意在说明（
）A. 收入分配的差距主要由机会分配不平等造成B. 经济体系健康运行的标志是公平的机会分配C. 公平的机会分配有助于提高社会经济发展效率D. 机会分配是维护社会公平正义不可或缺的内容这段文字意在说明（
） * A. 收入分配的差距主要由机会分配不平等造成 * B. 经济体系健康运行的标志是公平的机会分配 * C. 公平的机会分配有助于提高社会经济发展效率 * D. 机会分配是维护社会公平正义不可或缺的内容作者：不止心伤?来源：正解网链接：投票0好问题烂问题同问已同问修改分享扫码分享复制网址OK了，粘贴即可！解答:1个同问:0人浏览:507次修改提问【公务员考试】（行政职业能力测验）机会分配不仅能对收入分配结果产生重要影响，而且会直接影响到社会的经济发展效率。在不公正的机会分配下，一些人会因为某些特殊原因而获得发展机会，但这些获得机会的人很可能缺乏利用发展机会从事社会劳动和创造的能力，这必然导致他们所从事的劳动或经营项目的生产效率在下降，进而影响到整个社会的经济发展效率。让真正有才华的人获得机会，把合适的人放在适合的岗位上，是经济体系健康运行的基础。只有实现机会平等，才能最大限度地激发社会活力和人的积极性、主动性、创造性，提高社会劳动生产率和生产力发展水平。&&&&&这段文字意在说明（
* A. 收入分配的差距主要由机会分配不平等造成
* B. 经济体系健康运行的标志是公平的机会分配
* C. 公平的机会分配有助于提高社会经济发展效率
* D. 机会分配是维护社会公平正义不可或缺的内容提交图片把图片文件拖到这里即可上传上传完，点击「插入图片」按钮插入title插入图片图片链接:图片描述:添加取消视频title插入视频视频链接:添加取消出于安全考虑，目前正解网仅支持腾讯视频（支持 HTTPS）的视频播放页链接
提交1个解答0正解正确答案C. 公平的机会分配有助于提高社会经济发展效率详细解析文段开头指出机会分配会直接影响到社会的经济发展效率，接着对此观点进行反面论证，最后用「只有……才……」提出对策，只要机会平等才能提高社会劳动生产率和生产力发展水平。文段重点强调公平的机会分配对于提高社会经济发展效率的重要作用，对应C项。A项非文段论述重点，排除。B项「经济体系健康运行」为对策前的内容，非文段重点，排除。D项「维护社会公平正义」无中生有，排除。因此C项当选。正确答案
* C. 公平的机会分配有助于提高社会经济发展效率 详细解析
文段开头指出机会分配会直接影响到社会的经济发展效率，接着对此观点进行反面论证，最后用「只有……才……」提出对策，只要机会平等才能提高社会劳动生产率和生产力发展水平。文段重点强调公平的机会分配对于提高社会经济发展效率的重要作用，对应C项。A项非文段论述重点...作者：来源：正解网链接：收藏已收藏感谢已感谢修改分享扫码分享复制网址OK了，粘贴即可！修改解答&&&&&## 正确答案
* C. 公平的机会分配有助于提高社会经济发展效率
## 详细解析
文段开头指出机会分配会直接影响到社会的经济发展效率，接着对此观点进行反面论证，最后用「只有……才……」提出对策，只要机会平等才能提高社会劳动生产率和生产力发展水平。文段重点强调公平的机会分配对于提高社会经济发展效率的重要作用，对应C项。A项非文段论述重点，排除。B项「经济体系健康运行」为对策前的内容，非文段重点，排除。D项「维护社会公平正义」无中生有，排除。因此C项当选。提交图片把图片文件拖到这里即可上传上传完，点击「插入图片」按钮插入title插入图片图片链接:图片描述:添加取消视频title插入视频视频链接:添加取消出于安全考虑，目前正解网仅支持腾讯视频（支持 HTTPS）的视频播放页链接
提交我的解答&&&&&提交图片把图片文件拖到这里即可上传上传完，点击「插入图片」按钮插入title插入图片图片链接:图片描述:添加取消视频title插入视频视频链接:添加取消出于安全考虑，目前正解网仅支持腾讯视频（支持 HTTPS）的视频播放页链接
提交登录正解您现在的位置： >> 需求分析师工作内容 >> 需求分析师工作总结
需求分析师工作总结
来源： 时间：
【需求分析师】需求分析师工作概要信息系统基础理论 需求的基本概念与原理 需求工程 需求定义最佳实践 需求捕获最佳实践1）了解我们将涉及的领域！ 2）从信息化的本质理解需求信息与信息系统基本概念? 信息：是指什么？ 信息是对某个事件或者事物的一般属性的描述。信息总是 通过数据形式来表示，加载在数据之上并对数据的具体含 义进行解释。因此，也可以说，信息就是经过加工处理后 有价值的数据 ? 信息系统（IS）：是人、数据、过程和接口的组合，它们 之间相互作用，支持并改进企业日常的运作，并支持管理 人员和用户解决问题和做出决策。信息系统的大致分类 及特点? 事务处理系统：收集和处理企业事务，事务的 响应时间、吞吐量、正确性、一致性等，BPR ? 管理信息系统：提供面向管理报告的信息系统 应用 ? 决策支持系统：为用户提供决策信息，基于数 据仓库 ? 专家系统：程序化的决策制定信息系统，人工 智能(AI) ? 办公自动化和工作组系统：改进工作流和通信事务处理系统(TPS)概述? 每个组织都有手工和自动化的TPS，用来处 理有关组织的基本业务记录更新所需的详 细数据 ? 处理系统包括：订单录入 、存货控制、工 资单、应付帐款、应收帐款、总分类帐处 理 ? 处理包括：数据收集、数据编辑、数据修 改、数据操作、数据存储和文档生成 ? 事务：基本业务，如顾客订单、购货 订单、时间卡和工资支票处理事务处理的机制? 批处理机制：将一时间内的一批事务一 次性处理的系统 ? 联机事务处理机制：该方法中每个事务即 时进行处理，而不累积成批 ? 处理延迟的联机录入机制 ：前两者的折衷事务处理系统的目标? ? ? ? ? ? 处理由事务产生的及与事务相关的数据 保持高准确度：输入和处理无错数据 保证数据和信息的完整性 及时生成文档和报告 提高劳动效率 有助于改善服务事务处理系统―要求? 一个组织的TPS必须支持业务正常工作过程中 发生的常规的日常活动，这有助于对产品 和服务增值 ? 数据应该在源处获得，以减少人工劳动，并且 能准确、及时地记录送入计算机的方式 ? 事务处理的业务数据包括数据收集、数据编辑、 数据修改、数据操作、数据存储和文档生成 ? 将一个公司的事务处理系统与其他公司连接起 来是降低成本、加快信息流动的有效策略―例 如SCM（supply chain management）管理信息系统概述? 管理信息系统的主要目标是帮助管理者了 解日常的业务以便进行既有效又高效的控 制、组织、，最后达到组织的目标。-向管理者提供信息 ? 多数是通过不同的汇总分析报表来实现功 能的；这些报表筛选、分析事务处理数据 库中高度细化的数据，然后用一种有意义 的方式将结果送给管理者 ? 在恰当的时机以恰当的方式向恰当的对象 提交正确的信息，以改进工作效率管理信息系统特点? 制作进度、需求、异常、常规四类报表， 有助于管理执行人员即时作出高质量决策 ? 报表具有固定和标准的格式 ? 生成硬拷贝和软拷贝报表 ? 使用存储在计算机系统内的内部数据 ? 报表由包括系统分析员和计算机程序员在 内的信息系统人员开发和实施 ? 需要用户提交正式需求管理信息系统―四大类报表? 进度报表：周期生成或按日程生成，如日、周、 月报 关键指标报表是一种特殊类型的进度表，汇总 前一日关键活动。? 需求报表：按管理者的要求提供相应的信息； 如产品形势报表 ? 异常报表：当情况出现异常，需管理者加以注 意而由系统自动生成的报表；如预算超支的项 目列表 ? 常规报表：就某一情况为管理者提供更为详尽 的数据管理信息系统―报表开发原则? 按用户要求定制每份报表：要求用户参与和输入 ? 时间与精力应只用于要使用的报表：一旦建立，即使 没人使用，许多报表仍会一直不断生成 ? 注意报表的内容和格式：突出显示最为重要的信息， 字和术语力求清晰易懂 ? 利用例外报告实施管理：某些报告只应出现亟待解决 问题或需要采取某动作时生成 ? 审核设定参数：如参数过低结果是报告过多，如参数 过高则忽略有价值信息 ? 确保报告的时效：过期的报告无价值或价值极小管理信息系统小结? MIS必须在恰当的时间以恰当的方式向恰当的人提供 恰当的信息 ? 组织的MIS的最重要的内部信息来源是事务处理系统 ? 在大多数的情况下，公司最了解如何得到数据以及何 时以何种形式向哪一位管理者提交报表可以为公司带 来最大的利益 ? 不同信息系统的集成使数据和信息可以更简单地共享， 从而降低公司的成本，提高报表的精确度、数据更安 全，公司达到更高的效率决策支持系统基本概念? 决策是问题解答的一个组成部分 ? 决策阶段是问题解答的处理阶段，其包括情报、设计 和选择三个时期。? 情报时期：认识和确定潜在的困难和(或者)机会 ? 设计时期：确定问题解答的可选择的方案 ? 选择时期：要求选择一种行动方案 ? 问题解答除了决策阶段外还包括实施时期和监控时期 ? 实施时期：确定的行动方案开始生效 ? 监控时期：决策者们评估问题解答方案实施效果决策支持系统基本概念? 程序化决策：使用一种、过程或量化方法所做的 决策。例如：存货下降到一百时应该定货。--系 统要素之间的关系通过规律、过程和数值关系的方式 固定下来，通常可以通过MIS实现 ? 非程序化决策：处理不常见和异常的情况，很难量化。例如为雇员确定合适的计划、决定是否新建一条 生产线。--决策支持系统将解决的问题 ? 最优化模型：找到最好解决方案的决策支持方法 ? 满意性模型：找出一个好的(但未必是最好)解决方案 ? 启发式方式：认为能找到一个较好解决方案的指导或 过程决策支持系统的作用与特点? 用于支持专门问题决策的人力、过程、软件、数据库 和设备的一个有组织的集合。用来解决非结构化或半 结构化企业问题的决策。? 将处理不同来源的大量数据 ? 提供灵活的报告和展示 ? 以文本和图表格式提供信息 ? 支持深入的分析 ? 使用先进的软件包，完成错综复杂的分析和比较 ? 支持最优化的、满意性和启发式的方法 ? 执行What-if，模拟和目标求解分析决策支持系统的组成? DSS的核心是数据库和模型库，还包括对话管理器(提 供更友好的人机界面) ? 模型库：模型、统计分析模型、图表模型、项目 管理模型……专家系统简介? 专家系统可以像某个特定领域的人类专家一样行动 ? 用来辅助设计新产品或新系统、决定木材的最佳使用、 提高医疗卫生的质量、决定信用卡的信贷额度 ? 它能对它们的推理或提议的决策作出解释 ? 能显示“智能”行为 ? 能从复杂的关系间得出结论 ? 能提供“可移动”的知识 ? 能处理不确定性不同视角下的信息系统人员角度 数据角度 过程角度 接口角度 管理层预期 性能 〃 信息 〃 经济 〃 控制 〃 效率 〃 服务 业务实例和 规则列表 业务知识 系 统 用 户 设 计 人 员 开发 人员 E-R图 数据需求 逻辑视图 数据库模式 数据库程序 业务功能和 事件列表 业务功能 数据流图和 业务流程图 过程需求 流程图 类图、活动图 过程需求 应用程序 业务地点和 系统列表 业务地点 上下文范围 图 接口需求系 统 所 有 者系 统 分 析 员接口规范 接口说明 接口程序主流信息应用系统? ? ? ? ? ? MRP?MRP II?ERP：制造业，成本、生产流程 CRM：客户关系管理 SCM：供应链管理 BI：商业智能 OA：办公自动化 E-Commerce：电子商务备注? MRP(Material Requirement Planning):物资需求计划,是根据市场需求预测和顾客订单制 定产品的生产计划，然后基于产品生成进度计划，组成产品的材料结构表和库存状况， 通过计算机计算所需物资的需求量和需求时间，从而确定材料的加工进度和订货日程 的一种实用技术。主要用于库存控制 ? MRPII（Manufacturing Resource Planning，制造资源计划） :在周密的计划下有效地利 用各种制造资源，控制资金占用，缩短生产周期，降低成本，实现企业整体优化，以 最佳的产品和服务占领市场。? ERP 是整合了企业管理理念、业务流程、基础数据、人力物力、计算机硬件和软件于 一体的企业资源管理系统。其主要宗旨是对企业所拥有的人、财、物、信息、时间和 空间等综合资源进行综合平衡和优化管理，协调企业各管理，围绕市场导向开展 业务活动，提高企业的核心竞争力，从而取得最好的经济效益。信息应用系统分类? 内部：OA(办公自动化)、MIS(管理信息系统)、BI(商 业智能)、KM(知识管理) ? 外部：CRM、E-Commerce、Web Portal（门户网站） ? 协作：SCM（供应链管理）、GroupWare（群件）、 Assistant Tools备注KM：在组织中建构一文与技术兼备的知识系统，让组织中的信息与知识，透过获得、创造、分享、整合、记录、存取、更新等过程，达到知识不断创 新的最终目的，并回馈到知识系统龋鋈擞胱橹闹兜靡杂啦患涠系睦 积，从系统的角度进行思考这将成为组织的智慧资本，有助于企业做出正确 的决策，以因应市场的变迁。未来人力资源管理的核心，是建设学习型组织 的最重要的手段之一。信息系统需求的本质? 流程电子化 & 利用信息化系统改进、固化流程 & 事务处理系统尤其明显 & 工作流定义、流程改进、再造 & 工作流模型 ? 数据信息化 & 业务术语，业务实体 & 需要留存哪些数据？谁需要共享？ & 需要什么报表？有哪些数据分析规则？信息系统常见技术? 计算模式：B/S （Browser/Server结构）、C/S（客户机/服务器网） ? 主要开发体系：.NET、J2EE、LAMP、Rail on Ruby ? 重要：SOA（Service-Oriented Architecture面向服务的体系结构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层 是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖 性）、Web Service（一种新的web应用程序分支，他们是自包含、自描述、模 块化的应用，可以发布、定位、通过web调用。Web Service可以执行从简单的请求到复 杂商务处理的任何功能。）、工作流引擎? 开发方法论：重方法论（RUP）、敏捷方法论 ? 建模技术：UML、E-R模型概要信息系统基础理论 需求的基本概念与原理 需求工程 需求定义最佳实践 需求捕获最佳实践1）理论是实践的基础 2）解决概念性的误区需求―导致项目失败的罪魁祸首? 根据Standish Group对23000个项目进行的研 究结果表明，24%的项目彻底失败，44%的 项目超出经费预算或者超出工期，只有约 32%的项目获得成功。? 而在于这些高达68%的不成功项目中，有约 60%的失败是源于需求问题。? 也就是说，有近40%的项目最终因为需求的 问题最终导致失败。对不知道航行目的地的人来说， 没有顺风！我们在哪里重重摔了一跤? 在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%)软件需求曾经让我们如此狼狈参与各方都以自已角度讲述问题财务计算 管理报表 工作流 自动库存控制 库存报警 业务线索管理 业务经线索跟踪 销售月报生成 交易流数据 分布式 WebServices 三层 对话框 菜单条 DCOM B/S 数据交换……问题的根源是什么？? 用户说的不是他想的：客户提供（陈述的 需求）的需求并不是真实的需求，还需要 作进一步的分析，以确定客户的真正需求 和期望，接下来需要澄清并重新描述。可 以这么说客户在理解基础业务过程和描述 自己的需求方面有很大的差异。? 需求分析方法有问题：系统开发人员 使用低效的需求分析和项目管理方法。? 共同责任强调不足：对客户和提供商 在项目成功的共同责任方面强调不够。优秀的团队遇到糟糕的需求? ? ? ? ? ? ? ? 用户参与不足 用户需求扩展 有歧义的需求 镀金问题 过于抽象的需求 忽略某种用户 不准确的计划 ……我们应该怎么办？? 对“需求”建立正确的认识； ? 客户和供应商―一根绳子上的两个蚂蚱； ? 和客户一起建立起“共同的目标”； ? 寻找并使用正确的、有效的需求捕获、描 述（建模）、管理方法； ? 动态、持续地适应需求的变化；需求是什么？业务需求项目视 图/范围 文档 用户需求 质量属性 非功能需求 其它非功能 需求 设计约束 功能需求 SRS用例文 档系统需求业务需求? 业务需求是指反映组织机构或客户对系统、产品高层 次的目标要求，通常问题定义本身就是业务需求 。? 背景描述：XX保险公司希望充分利用日益完善的移动 通信技术，在原有的办公系统的基础上进行扩展，使 得在外的业务人员能够及时地获得客户、业务相关的 动态信息，与此同时，实现企业内部的即时通信。? 业务需求/目标 ：通过该系统的实施，将人 工保费续缴、投保手续办理两项业务运转 周期缩短10％以上，使企业内部沟通效率 大幅改善，以帮助企业运转效率得以提高。业务目标示例某船厂商业管理系统目标A1.取代过时的系统 A2.集成订单文档及数据库 A3.使用经验数据进行报价 A4.支持系统化的销售 A5.快速捕获成本数据 A6.加快发票的制作某管理系统目标B1.降低IT成本 人事部门B2.实现一些任务的自动化 B3.消除出错源 B4.遵守最后期限 B5.减少繁琐工作 医院部门B6.减少加班及工作量不足的情况 B7.更快速的勤务规划 B8.改进勤务表质量业务需求就是定义系统目标? 现状：功能分解盛行的今天，常常会犯“盲人摸象” 的错误，这使得需求太过脆弱，难以经受考验。? 目标！目标！还是目标！--系统开发应目标驱动！目 标是团队唯一的行动纲领。? 目标的定义不能够流于形式，应该具有以下特征：业 务导向、可度量、合理、可行。要 注意目标太夸大会浪费资源，目标 太缩小会影响士气。（城堡与小屋） ? 目标通常就是业务需求！业务需求就是定义系统目标? 目标在哪里？业务需求是构建在“项目发起人”的脑 子里的，也就是谁提出项目，谁就拥有对“业务需求” 的最清晰的理解。? 引出宏观的目标：思考企业运作中存在什么问题？这 些问题主要是体现在哪些方面？这些问题对企业造成 了什么影响？认为可以怎么解决？希望达到什么样的 效果？? 将大任务分解成为小目标，并且引导客户良好地定义， 这也是我们形成“项目子目标描述”的关键基础。? 衡量这些目标的合理性与可行性。业务需求就是定义系统目标? 形成一个不超过50字的项目目标，并且列出5-9个主要 子目标，并且将其制作成一页文档，作为“项目的行 动纲领”，还应该得到“项目发起人”的认可。? 在此基础上，可以编写“项目的目标和范围文档”(或 称项目综述，即POS，内容包括问题/机会、项目目标、 项目目的、成功标准、假设/风险/障碍)，对于产品而 言，我们还可以构建一个从市场角度分析的“愿景” 文档。? 该部分工作是处于“需求过程”的金字塔尖，多花费 一些时间和精力是值得的，也是必要的。业务需求就是定义系统目标? 有了清晰的目标之 后，还应该对系统 划定范围，最常用 的方法是工作上下 文范围图（结构化 分析方法）：用户需求? 用户需求是指描述用户使用产品必须要完成什么任务， 怎么完成的需求，通常是在问题定义的基础上进用户 访谈、调查，对用户使用的场景进行整理，从而建立 从用户角度的需求。? 用户有不同类型& 管理型、事务型 & 信息系统、人 & 决策层、使用层 & 常用者、偶用者 ? 组织方法：用例、用户故事、特性 ? 例子：对快到期的客户，系统将通过短信 将续保信息发给该客户的代理人系统需求? 解释一：系统需求是相关联的硬件、软件系统对待开 发系统的相关需求。? 解释二：从系统实现的角度描述的需求。? 开发人员（设计及分析人员）在业务需求、用户需求 的基础上生成的。功能需求? 功能需求是需求的主体，是需求的本质 ? 功能需求定义了：系统必须完成的那些事，即为了向 它的用户提供有用的功能，产品必须执行的动作 ? 零散（需求项）?整理（特性、用例） ? 敏捷方法：用户故事质量属性? ? ? ? ? ? ? 产品必须具备的属性或品质 可靠性：成熟性、容错性、易恢复性 易使用性：易理解性、易学习性、易操作性 效率：时间特性、资源特性 可维护性：易分析性、易更改性、稳定性、易测试性 可移植性：适应性、易安装性、一致性、易替换性 McCall体系：运行(正确性、可靠性、效率、 完整性、使用性)、修正(维护性、测试性、 灵活性)、转移(移植性、复用性、共运行性)设计约束? 也称为限制条件、补充规约，这通常是对 解决方案的一些约束说明。? 例如：必须采用国有自主知识版权的数据 库系统… ? 再如：必须运行在UNIX操作系统之下正确理解需求―考虑系统的本质? 正确理解系统需求，就是理解系统的外围环境杯体，组件，盛液体和嘴的接口杯把，组件，方便拿 和手的接口 和桌子的接口? 需求：使人能够将热的液体送到嘴里而液体不会溅出，人 也不会烫伤正确理解需求―考虑系统的本质? 考虑因素& 杯子本身没有用，要依靠人胳膊的机械运动 & 杯子的杯体部分要依靠重力的存在才能发挥作用 & 杯子必须被正确使用，拿反了就会使液体倒出 ? 这个简单杯子要具备其用途的功能，最终取决于& 从组件交互所表现出来的属性 & 与外部组件的合适接口 & 正确嵌入外围系统―由人手拿住，并用胳膊举起 & 适当环境的存在―失重条件下需另一种解决方案两个世界三种设计问题域 机器域for(i=0;i=i+1;i++) { }需求规格说明书程序问题域? 某需求分析师在一个“为货车运输公司开发软件”， 该软件的目的是跟踪卡车、司机、货物及散布于全国 各地的客户。? 如果一开始就描述客户所期望的尽可能详细的行为屏幕的外观，每一版块的信息以及程序对鼠标的应答， 那么―你就忽略了需求！！ ? 需求定义的是软件所要解决的问题，而不是描述软件 如何解决它。即它是与问题域相关联的。? 例如：货运公司软件的一个需求可能是按要求把货物 从一个地方送到另一个地方，软件通过调度卡车和委 派司机来实现需求需求? 需求是通过计算机编程在问题域中施加的效果 ? 需求是确定客户需要得到什么的陈述：能在问题域中 执行某种类型的活动，能使用问题域的部分信息，使 问题域中的参数保持在一定的范围等 ? 货运公司软件需求中使用的术语应该是问题域中的对 象，如“对于指定卡车，一个职员可以找出它正装载 的货物是什么” ? 需求不包括像数据库、按钮、双向链表、文件等术语优秀的需求? 完整性：完整描述即将交付使用的功能，发现缺少某 项信息，可以采用TBD来标注 ? 正确性：经过用户或用户信任的代理人审阅 ? 可行性：在已知能力和约束条件中实现 ? 必要性：每项需求记录的功能都应是用户真正需要的 ? 有优先次序：提供了实现优先级 ? 无歧义：对所有读者只有一种一致的解释 ? 可验证性：可以设计测试方法来检查概要信息系统基础理论 需求的基本概念与原理 需求工程 需求定义最佳实践 需求捕获最佳实践1）掌握需求的相关工作 2）了解需求的相关人员需求错误的代价需求：1 设计：5 编码：10 测度：20-50 运行与维护：200需求开发与管理需求开发活动需求获取? 应收集什么信息& 问题域的描述 & 要求解决的问题列表（需求） & 用户对系统的行为或结构施加的任何约束 ? 信息来源& 客户（实际的和潜在的） & 任何原有解系统（已有系统）及其文档 & 原有系统用户 / 新系统的潜在用户 & 应用（问题）领域专家 & 定义了任何接口系统的特片和行为的文档 & 相关的技术标准和法规需求获取技术? ? ? ? ? ? ? ?阅读背景资料 头脑风暴讨论分析文档考古 面谈（用户访谈） 联合应用设计 用户调查 需求剥离? ? ?现场观摩任务观察 用例和场景需求获取的误区? ? ? ? ? 缺乏计划性：随意、走过场，预先没计划 缺乏科学性：未从本质入手 捕获对象不明确，甚至造成岐义 过于迷信现有文档 过于迷信“听”到的东西需求分析? 所谓分析是指通过对问题域的研究，获得对该领域特 性及存在于其中（需要解决）的问题特性的透彻理解 并用文档说明 ? 分析方法：结构化分析法、面向对象分析法、面向问 题域分析法 ? 任何分析法，均需描述以下几个方面& 问题域的结构（子域，及子域间关系） & 问题域的数据 & 问题子域的固有属性及行为 & 问题域中的重要事件及现象 & 需求：应产生的效果需求分析方法―结构化分析? 从基于文本分析和规格文档?图形建模表 示法 ? 结构化分析初期的模型：数据流图+E-R图 ? 数据流图：体现了流程，但是以数据为中 心的流程 ? E-R图：体现了要存储的信息 ? 数据字典：对数据、数据流的描述需求分析方法―结构化分析? 对问题域的研究力度不够大 ? 分析和设计之间缺乏清晰的界限，将会导 致不成熟的内部设计 ? 没有一个真正的功能规格说明 ? 需求实质上是根据满足该需求的某一特定 系统的内部设计来加以说明的 ? 内部设计的开发使用的则是不可靠的内部 设计技术，即功能分解 ? SA不适用于某些类型（绝非少数）的应用需求分析方法―面向对象分析? 与开发方法最为接近的分析方法 ? 主要模型& 用例模型：系统的功能，场景化分析 & 类模型：对象、数据 & 活动图、状态图 ? 用例驱动的需求实践?最佳实践需求分析方法―面向问题域分析? 是一种新的、返璞归真，较少强调建模? 搜集基本的信息并开发问题框架，以建立 问题域的类型；在问题框架类型的指导下， 进一步搜集详细信息并给出一个问题域相 关特性的描述。需求分析―何时进行? 应该在“业务需求”充分理解，并且收集了最本质的 “用户需求”之后就开始需求分析，但并不是等到需 求捕获完全做完之后 ? 交替进行，先把握用户需求主要部分，然后在分析的 基础上引入系统级的需求（系统的设计与实现角度）， 并且分析模型，成为开发人员之间、开发人员与客户 之间达成共识的一个平台 ? 分析的基础上，就会发现更多的不明确项， 更多待捕获的信息，这时就可以生成第二次 的需求调研的计划、问题、素材需求分析―何时结束? 需求捕获、分析与建模、规格说明书的编 写、需求的验证这个需求开发的循环，是 在整个软件开发生命周期中存在的 ? 每一次的循环，都将在需求开发的工作要 点与份量上有所不同，它们应该遵循以下& 从本质到边缘：本质、重要、次重要、一 般、镶金 & 细化阶段是需求开发最密集的阶段 & 构建阶段需求开发逐渐减少需求分析―内容与形式? 需求分析与建模不应该是孤立的行为 ，产生的结果也 不一定非得是规范度很高的标准文档，而应该重在分 析、重在方法、重在交流、重在解决问题 ? 团队聚在一起，利用白板甚至是纸张，在充分的合作 下进行分析与初步建模是成本最低、效率最高、实用 性最强的方法 ? 对于这些活动所产生的结果，可以利用数码相机、扫 描仪进行文档化 ，“直到你一定要用时，再写文档” ? 对于比较重要、核心的内容，再采用Rose、 Together这样的工具进行文档化编写规约? 规格说明书是对需求分析结果的文档化过程 ? 比较“正规”的开发组织都会重视这个活动，甚至可 以说是“重视过度”，而且产生出来的文档经常是与 实际的开发脱离，完成之后就束之高阁，再也不使用、 不更新。这是一个需求崩溃的信号 ? 规格说明书的格式与所采用的开发过程、分析方法相 关的，不同的方法格式不同 ? 定义统一的格式是一个很重要的工作 ? 规约内容的严谨、正确、无岐义是很重要的需求验证? 这个工作大多数组织都不够重视，导致这个工作直到 交付系统时才真正被履行，这也就是为什么客户拿到 系统后才提出许多这样那样的需求变更，甚至认为整 个系统都不是他所需要的 ? 提高需求质量的重要手段& 需求评审 & 需求确认 & 通过原型来验证需求需求开发与需求管理的分界需求基线管理? 频繁的需求变更会破坏开发的节奏，使整个项目开发 的进度陷入混乱和失控的状态，而且会变成一个“救 火队”式的工作，整天都在处理突发事件 ? 将所有现在的、将来的需求进行优先级评估，然后分 解成为不同的组，每次迭代都选择其中优先级最高的 部分进行开发，然后在迭代完成之前，开发工作不响 应变更，这些划入的需求项就是需求基线的组成部分需求基线管理―操作思路? 我们应该在分析的基础上，将需求整合成为用例或功 能项，然后对其进行优先级、依赖性进行综合性评估 ? 优先级判断：业务人员确定业务决定，技术人员确定 技术决策；“满意度/不满意度”模型 ? 依赖性是指对于某些功能，在实现上有必须的依赖关 系，即当某些功能没有实现时，另外的功能无法开始， 这就需要对其进行调整需求变更管理? 需求变更是一定存在的，而需求变更管理并不是指逃 避它，更不是说要避免它，它实际上是希望控制变更 ? 在基线内的需求不响应变更，为开发人员提供一个安 静的工作时间状态 ? 专门的需求变更管理来对所有的需求变更进行响应， 了解需求变更的关键意图、新产生的工作量，从而良 好地进行重新计划，以便能够有效地解决其对整个开 发带来的麻烦需求变更管理―变更的流程? 提出变更：正式的方式提交变更是很重要的，合约式 的沟通平台 ? 变更评估：合理性评估，进一步了解其变更的主要原 因，认清其是否是因为沟通上的误会与不理解而造成 的不必要的变更；工作量评估则是评估其对进度的影 响；影响面分析则是评估该变更会对哪些部分工作产 生影响，具体地说会对哪些人的工作产生影响 ? 分级响应评估：不影响相关模块开发进度的，可直接 响应；影响本模块开发进度但不影响项目总体进度的， 可由项目经理协调后直接响应；影响项目进度的，则 应该交与客户协商响应方式需求跟踪? 需求的跟踪是指对需求的完成情况、变更影响进行系 统化的跟踪与处理 ? “需求是不是已经被实现？”、“需求的变化将需要 修改哪些设计元素？会影响谁的工作？对已经完成的 部分是否有影响？”需求管理的参与者需求分析师? 需求分析员是对项目涉众的需求进行收集、分析、记 录和验证等职责的主要承担者，是用户群体与软件开 发团队间进行需求沟通的主要渠道 ? 典型活动：定义业务需求、确定项目涉众和用户类别、 获取需求、分析需求、为需求建模、编写需求规格说 明、主持对需求的验证、引导对需求的优先级划分、 管理需求 ? 必备技能：倾听、交谈和提问的技巧，分析、 协调、观察、写作、组织、建模、人际交 往和创造能力需求分析师? 必备知识：现代需求管理技术、各种软件开发生命周 期、领域知识 ? 需求分析员的来源：用户转为分析员（软件工程知识 欠缺）、开发人员转为分析员（领域知识、沟通能 力）、主题专家（易按自己的偏好来构建系统）软件客户权利法案? 要求需求分析员使用客户的语言 ? 要求需求分析员熟悉客户的业务，了解客户的系统目 标 ? 要求需求分析员把需求收集过程中客户提供的信息组 织成书面的软件需求规格说明 ? 要求需求分析员解释需求过程生成的所有工作结果 ? 要求需求分析员和开发人员尊重客户，始终以合作和 专业的态度与客户进行互动 ? 要求需求分析员和开发人员为需求和产 品实现提供思路和备用方案软件客户权利法案? 要求开发人员实现能让产品使用起来更容易、更有趣 的特性 ? 调整需求，便于重用已有的软件组件 ? 在提出需求变更时，获得对变更的成本、影响及二者 权衡关系的真实评估 ? 获得满足功能和质量要求的系统，这些要求必须事先 告知开发人员并征得其同意软件客户义务法案? 为需求分析员和开发人员讲解业务并定义业务术语 ? 提供需求，阐明需求，通过与开发人员的交互将需求 充实完善 ? 对系统需求的描述必须详细、准确 ? 需要时，及时对需求做出决断 ? 尊重开发人员对需求成本和可行性的评估 ? 与开发人员协作 ，为功能需求、系统特性 和用例设置优先级需求过程需求过程概要信息系统基础理论 需求的基本概念与原理 需求工程 需求定义最佳实践 需求捕获最佳实践对问题进行了正确的定义 意味着成功解决了问题的一半信息系统立项前的分析方法? GPOA方法：Goal?Problem?Option?Answer ? G（目标）：要确定需要开发某个信息系统之前，应 该分析其应该达到的目标：业务性、可度量 ? P（问题）：要达到该目标所需解决的问题！ ? O（选项）：针对这些问题可选的解决方案 ? A（答案）：针对各种Option进行分析、评估，最终 确定答案。信息系统立项可行性分析? 确定目标：信息系统实现前，信息系统实现后 ? 提出解决方案：分析P，给出O，得出A ? 可行性分析& 效益分析：经济可行性，投资回报 & 社会可行性 & 技术可行性信息系统立项时的常见误区? 目标：含混不清，过为宏观 Solution基于业务需求思考 ? 解决方案：思路过于受限 Solutions& 只想What，别想How & 了解、理解IT技术 ? 期望值：脱离现实 ? 发起人、用户、使用者想法不一致框定问题的技巧? 问题的定义是需求工作的第一步，也是最重要的一步。? 问题是否能够解决，通常与是否能够更好、更准确地 框定问题相关。框定问题的技巧? 软件需求第一和可能最重要的步骤是框定问题―把问 题的特定部分，以及部分间特定的关系，放入一个特 定的形式中。问题框定方法应使问题的细节适合一个 简单连贯的框架? 同时，这也表现出，深入地理解问题域的知识，正确 地抓住其本质特性，是十分重要的。框定问题的技巧? 问题：在风景旅游胜地的山脉中建成了一条很长的汽 车隧道，为了防止停电时发生灾难，必须提醒司机进 入隧道之前把车灯打开。? 解决方案一：“警告！前有隧道请打开车头灯” ? 新问题：隧道出口风景很美，返回时发现汽车没电― 忘了关车头灯！！ ? 解决方案二：出口处立标牌“关掉车灯” ? 新问题：夜行车也会关掉车灯？ ? 解决方案三：建充电站 ? 新问题：维护开支大，充电站也会出故障框定问题的技巧? 解决方案四：授权私人经营充电站 ? 新问题：风景区商业化，政府与游客均不接受 ? 解决方案五：在隧道尽头，树立新标牌 如果是白天，并且车灯开着，请熄灭车灯； 如果天色已晚，并且车灯没开，请打开车灯； 如果是白天，并且车灯没打，就别打开它； 如果天色已晚，并且车灯开着，请别关掉它。? 新问题：谁能在行驶时读完？！ ? 终极解决方案：你的灯亮着吗？问题分析的五个步骤? 问题分析：理解真实世界中的问题和用户的需求并提 出满足这些多方面要的解决方案的过程 ? ①在问题定义上达成共识 ? ②理解根本原因―问题背后的问题 ? ③确定风险承担人和用户 ? ④定义解决方案系统的界限 ? ⑤确定加在解决方案上的约束在问题定义上达成共识? 把问题写下来，看每个人是否都同意 ? 采用标准化格式& 问题：描述问题 & 影响：确定受问题影响的风险承担人 & 结果：确定问题对风险承担人和商业活动的影响 & 优点：指出解决方案并列出主要优点理解根本原因―问题背后的问题? TQM的鱼骨图?帕雷托图60旧陷折缺的他造品成制其制不 准 确 的 订 单 运 输 损 耗 用 户 退 货 制 成 员 折 旧 制 造 缺 陷其 他不 准 确 的 订 单 运 输 损 耗 用 户 退 货太多废品50 40 30 20 10 0理解原因后对问题的陈述? 问题：不准确的订单 ? 影响：订单操作者、客户、生产者、销售者及 ? 结果：增加废品、额外处理成本、客户不满及收益降 低 ? 优点：& 增加了输入点订单的准确性 & 增加了销售数据的报告以便进行管理 & 获得更好的效率确定风险承担人和用户? ? ? ? ? 系统的用户是谁？ 系统的客户是谁？ 还有哪些人会受系统输出的影响？ 系统完成并投入使用后，有谁会对它进行评估？ 还有没有其他系统内部或外部用户，他们的需要有没 有必要被考虑到？ ? 系统将来由谁维护？ ? 还有其他人吗？定义解决方案系统的界限? 谁会对系统提供信息？谁会在系统中使用信息？谁会 从系统中删除信息？ ? 谁将操作该系统？ 输入 系统 输出 ? 谁是系统的维护者？ 系统 ? 系统将会在哪儿被使用？ 界限 ? 系统从哪儿得到信息？ ? 哪些外部系统要 我们的解决方案 和系统进行交互？其他系统确定加在解决方案上的约束? 经济约束：预算？ ? 约束：存在许可问题？潜在内外部政问题？部门 间问题？ ? 技术约束：技术选择有何限制？限制在已有平台或技 术上？禁止使用新技术？需要购买软件包？ ? 系统约束：建立在现有系统上？需要维护与原系统的 兼容性？必须支付什么操作系统？ ? 环境约束：合法吗？性要求？其他标准限制？ ? 进度及资源：进度要求？已有资源？外部劳动力可用 否？有无扩展资源？确定加在解决方案上的约束? 操作性：销售订单数据必须在数据库中备份一年，因 为数据丢失风险太大，需并行运行至少一年的数据 ? 系统及操作系统：应用在服务器上占用不超过200M， 因为服务器上存储空间有限 ? 设备预算：必须在已有服务器和主 机上开发 ? 人员预算：固定的人力资源，没有外部资源 ? 技术要求：应用新的面向对象的方法项目定义―业务需求? 产品/项目的目的：对业务目标的简短、可度量的描 述 ? 客户：为谁构建？ 顾客 ：谁会购买？ ? 风险承担者：哪些人在产品中拥有既得利益？ ? 用户：谁将操作它？他们的能力如何？ ? 限制条件：必须采用某设计方案？时间？经费？ ? 名称：该项目使用哪些术语？ ? 相关事实和假定：每个人都需要知道什么？ ? 工作的范围：什么是产品和项目的边界？ ? 估算的费用：需要花费多少工作量或资金 ? 风险：面临的主要风险项目定义―目标的六要素? 目标：精确预报道路结冰时间并分派除冰卡车 ? 业务优势：通过预报道路结冰情况来减少道路事故 ? 度量：因结冰而发生的事故数年将低于冬季发生的事 故总数的15% ? 合理性：消除因结冰而发生的事故而减少的损失，与 构建该系统所花费的成本和工作量相比，是否有价值？ ? 可行性：及时地除冰能否减少事故的发生？会降到总 数的15%以下吗？ ? 可达成性：该目标能达到吗？项目定义―风险承担人与用户? 用户：与主题相关的经验、技术上的经验、智力能力、 对工作的态度、对技术的态度、受教育程度、语言技 能、年龄、性别 ? 风险承担者：用户、客户、顾客、管理者、业务主题 相关者、开发人员、检查人员、市场力量、法律方面、 反对者、专业团体、公众意见、政府、特殊利益团队、 技术专家、文化利益、相邻系统项目定义文档―前景文档? 业务需求 & 背景：新产品的来由与背景 & 业务机遇 & 业务目标与成功标准 & 客户与市场需求 & 业务风险 ? 解决方案的前景 & 前景说明(目标客户、需求与机会、竞争对手与优势) & 主要特性 & 假设与依赖项目定义文档―前景文档? 范围与限制 & 第一个版本的范围 & 各后续版本的范围 & 限制与排除 ? 业务背景 & 涉众简介 & 项目优先级 & 操作环境需求心理学―常见现象? 言过其实心理：说的流程是一种理想化流程，与实际 情况严重不符 ? 越俎代疱心理：对非自己处理的流程津津热道，根据 自己的理解、想像进行肯定的描述 ? 非正事心理：一直忙于工作，无瑕配合需求调研 ? 抗拒心理：新系统对其利益有损，故意不配合 ? 推卸责任心理：装不知，说没需求需求变化的预期? 流程变化：流程顺序变化，流程细节变化，流程负责 人变化，流程输入变化，流程输出变化。? 数据变化：数据格式变化、数据规则变化、数据输出 变化、数据项变化 ? 业务规则：规则增加、规则减少、规则变化 ? 系统表现形式变化：界面、风格、输入形式、 展现方式、访问方法、网络环境 ? 目标变化概要信息系统基础理论 需求的基本概念与原理 需求工程 需求定义最佳实践 需求捕获最佳实践需求捕获是一个探索的过程 是一个有计划、科学性的过程需求捕获的主要障碍? 大多数情况下，系统相关的人员无法陈述自己的需要 ? 许多用户难以解释所执行的任务，更难解释为什么执 行这些任务 ? 相关人员经常指定解决方案而不是需求 ? 相关人员也难以构想出新的工作方法，或者想像出使 用提供的方法执行熟悉的任务所能够得到的结果 ? 不同的相关人员可能持有相互矛盾的观点 ? 相关人员经常出于抵制变更而拒绝新系统 ? 需求可能过多―过度的需求 ? 需求随着时间而变化需求捕获的各方职责? 由需求分析师策划，由需求分析师、用户和其他风险 承担者积极合作完成。? 用户、顾客和客户：有责任向需求分析师提供他们的 工作知识 ? 需求分析师：理解用户所说的关于工作的事情，并将 其解释成产品的需求规格说明 & 观察和学习该项工作，从用户角度来理解它 & 用户对某项工作的描述必须作为事实来对待，要发 现工作的本质，而非表象 & 发明完成该工作更好的方法 & 以需求规格说明书和分析模型的方式记录用户在需求捕获过程中的角色? ? ? ? ? ? ? 作为设计组、专题讨论会的成员，参与设计用户界面 作为知识来源，提供任务、商业过程的当前执行情况 参与集策讨论会，提供构想、确定问题 作为测试用户，在验收时测试系统检查能否正常工作 作为审查者评估用户界面 进行可用性测度，尝试使用新的用户界面执行任务 作为项目管理委员会成员用户的各种需求? 意识到的需求：是指那些用户最先想到的 需求，常常表明用户希望改进的一些事情? 无意识的需求：是指那些用户没有言明的 事情，因为用户对它们知道得太多，以致 于他们假定其他任何人都具备同样的知识 ? 未梦想过的需求：是指那些一旦用户认识 到它们可能就会要求的事情系统化地组织需求捕获? 术语表、域建模、领域培训―这些都是因地制宜的业 务建模的常见工具。（Wiki） ? 与业务流程相关的系统，最重要的是：置身于流程之 中，分析信息、工作流。? 从“组织结构与岗位设置图”所体现的管理层次与线 条建立全局了解；--参与者的来源；? 针对业务流程，绘制出跨部门职能流程图，以帮助开 发人员对客户方的业务流程建立宏观、清晰的认识， 以便更加有的放矢地进行进一步的需求捕获工作。跨部门职责流程图系统化地组织需求捕获? 应该搜集什么信息？细化地研究流程图，看看是否已 经对每个环节、每个步骤都清楚地认识了。我们应该 根据自己的理解首先对每个流程的工作进行定义，写 出事件流，并且标识出疑问点，这些都将使我们明白 “应该收集什么信息”。? 从哪搜集这些信息？流程涉及到什么部门、岗位，答 案就应该从谁身上找。（闲聊惹的祸） ? 用什么机制来搜集？需求捕获技术有多种，重点在于 因地制宜地使用不同的机制……主要需求捕获技术比较当 前 工 作相关人员分析当 前 问 题B目标 及关 键问 题A未来 系统 构想C切实 的可 能性结果 及 风险C认 可冲 突 决 议B最 终 需 求C优 先 级完 整 性B用户访谈现场观摩 任务示范 文档考古 用户调查 集策讨论会 重点问题讨论会 域专题讨论会 设计专题讨论会AA A A BAB A B B ABB C A A CCCC C C B B BC A A B A B B B C B B B C B C C B A A BAA主要需求捕获技术比较当 前 工 作 原型设计 小规模试验 C 当 前 问 题 目标 及关 键问 题 未来 系统 构想 C 切实 的可 能性 A A 结果 及 风险 B A 认 可 冲 突 决 议 最 终 需 求 A B B 优 先 级 完 整 性 C BB A研究类似公司询问供应商 协商 风险分析CC CBC B BAB CAA C BAB C A A ABB B C A成本/效益分析目标-域分析 域-需求分析BB CBB BCB CCCAA BCC B AAB B A B用户访谈? 用户访谈：最基本、最常见的技术 ? 利：直接有效、形式灵活、交流深入，应该做为主要 的需求捕获技术（宽带通信、固有灵活性、各类信息） ? 弊：占用时间长（特别当客户忙时更显示出其不足）、 面窄而容易造成信息的片面性。? 要点：首先要有准备：通常包括说明对流程的理解， 并征得客户的意见；预先根据流程中的不明确点设计 要询问的问题，并将客户的反馈记录下来；应留有一 些即兴的空间，根据实际情况应变，以确保信息完善。第二是要有计划性：计划好时间、计划好人员、计划 好策略。用户访谈：特点? 最传统的方法，单独使用并不有效，通常别期望用户 知道并能够说出他们的需求? 应先草拟一份问卷，向要访谈的用户发出一份涉及访 谈主题和时间安排的材料 ? 在访谈的过程中，及时用草图绘制模型（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 15:00~16:00 16:00~17:00 介绍 议程、设备、规则 情况简介 现状、需要、面谈结果 自由讨论 应用特性 午餐 自由讨论 继续 特征定义 写出2~3句话的特征定义 意见精简与优先级排序 总结和操作议项联合开发：组织技巧中间休息 迟到1次自由 廉价攻击规则：每人先发一张，允许迟到一次 而后向罚款箱投入xx元 目的：保持会议的动向规则：每人先发一张，允许自由攻击 或批评任何个人或部门，而后 再出现就向罚款箱投入xx元 目的：逗趣并提醒人们注意5分钟发言好主意！规则：每人可以在任何时候使用，让 出讲台给他并计时，不得打断 目的：允许结构化的即席发言规则：每人先发两张，送给提出好建 议的人，要尽快给出 目的：刺激与会者并奖励提出创新者联合开发：自由讨论与意见精简? 每人发25张索引卡片，按以下规则进行自由讨论1. 2. 3. 4. 不允许批评或争吵 允许发挥你的想像力 产生尽可能多的意见 转换和组合想法? 意见精简 & 修剪：去掉不值得进一步集体讨论的意见 & 归类：把意见归类 & 特征定义：用一句话描述未被删除的意见 & 确定优先次序：累积投票(百元测试)、关键/重要/有 用情节串联板制作：概述? 情节串联板制作：最互动的技术 ? 利：用户友好、交互性、对用户界面提供早期评审， 易于创建和修改。? 弊：需求捕获速度慢。情节串联板制作：类型联合开发：做什么及要点? 谁是扮演者 ? 他们发生了什么事 ? 是怎样发生的 ? ? ? ? 不要在情节串联板上投入太多精力 如果什么都不变，就什么都学不到 不要做得太好―误以为已完成 只要可能，就制作交互折需求捕获的最佳实践? 评估系统可行性：进行需求捕获之前，应先进行一个 可行性研究，评估现有技术下系统是否能够实现目的 & 主要效益：提示是否真正需要一个系统 & 引入成本：低 & 应用成本：低-中 ? 注意组织和行政方面的因素：需求捕获时，必须注意 影响需求源和可能会对你隐藏真正系统需求的组织和 行政因素 & 主要效益：有助于理解一些需求被建议的原因 & 引入成本：低 & 应用成本：很低 & 实施要点：注意不一致的目标、责任的丧失或转移、 组织文化、组织的管理态度和士气、部门差异需求捕获的最佳实践? 识别和咨询系统的项目相关人员：即那些直接或间接 从开发的系统中受益的人 & 主要效益：发现所有可能的需求源 & 引入成本：很低 & 应用成本：低 ? 记录需求源：即记录该需求所基于的信息的链接，可 以是人员、文档、其他需求 & 主要效益：来自于初始需求源的需求可跟踪性 & 引入成本：低 & 应用成本：低 ? 定义系统的操作环境：主动、硬件和软件系统 & 主要效益：交付系统没有安装问题 & 引入成本：低 & 应用成本：低需求捕获的最佳实践? 使用业务关系来驱动需求捕获：业务关系是必须满足 的高层目标，应识别、记录这些目标。& 主要效益：需求集中在核心业务需求上 & 引入成本：低 & 应用成本：低 ? 寻找领域约束：即来自于系统应用领域的系统需求 & 主要效益：领域约束经常会导致识别出关键需求 & 引入成本：低 & 应用成本：中等 ? 记录需求理由：即关于提出某需求的原因，根据系统 所需解决的问题来证明需求。是从需求源导出的。& 主要效益：提高对需求的理解 & 引入成本：低 & 应用成本：低-中等需求捕获的最佳实践? 从多视点收集需求：对系统的需求有许多影响源，对 系统应提供服务和提供服务的方式都有自己的视点 & 主要效益：更好的需求覆盖率 & 引入成本：中等-高 & 应用成本：中等 ? 原型化难以理解的需求：如果有不清楚或难以理解的 需求，则应考虑开发一个原型系统。& 主要效益：更好地理解系统用户的真正需要 & 引入成本：中等 & 应用成本：低-高 ? 使用场景来抽取需求：场景是最终用户和系统间某个 交互类型有关的交互会话。& 主要效益：用户易于理解场景和描述的相关需求 & 引入成本：相当高 & 应用成本：低需求捕获的最佳实践? 定义操作过程：应分析、理解和文档化各种业务过程， 将其作为需求捕获的一部分。& 主要效益：揭示过程需求和需求约束 & 引入成本：相当高 & 应用成本：中等 ? 复用需求：尽可能从在同一应用领域已经开发出来的 其他系统中复用需求。& 主要效益：较低的需求成本、较快的需求捕获 & 引入成本：中等-高 & 应用成本：中等
【需求分析师工作总结】议题需求的概念和需求分析的任务 需求分析与软件生命周期的关系 需求分析过程―需求分析的基本过程建筑需求与软件需求对大多数人来说，若要建一幢数百万元的房子，他 一定会与建房者详细讨论各种细节，他们都明白完 定会与建房者详细讨论各种细节，他们都明白完 工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧” 起来。软件项目中百分之四十至百分之六十的问题都是在 需求分析阶段埋下的“祸根”。可许多组织仍在那 些基本的项目功能上采用 些不合规范的方法，这 些基本的项目功能上采用一些不合规范的方法，这 样导致的后果便是一条鸿沟(期望差异)―开发者开 发的与用户所想得到的软件存在着巨大期望差异。为什么要需求分析需求分析就是分析软件用户的需求是什么.如果投入大量的人 力，物力,财力,时间,开发出的软件却没人要,那所有的投入都 是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户 的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信 大家都有)比如,用户需要一个for Linux的软件,而你在软件 开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而 想当然的认为是开发for windows的软件,当你千辛万苦地开发 完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕 不得找块豆腐一头撞死. 需求分析之所以重要,就因为他具有决策性,方向性,策略性的作 需求分析之所以重要 就因为他具有决策性 方向性 策略性的作 用,他在软件开发的过程中具有举足轻重的地位.大家一定要对 需求分析具有足够的重视.在一个大型软件系统的开发中,他的 作用要远远大于程序设计.风险承担者与需求分析阶段在软件工程中，所有的风险承担者(stakeholder)(这个词很有 意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众 的，也有的翻译成参与者的，但是我想他的主要意思就是和这 个项目有密切相关利益的人)都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员(负责收 集客户需求并编写文档，以及负责客户与开发机构之间联系沟 通的人)、开发人员、测试人员、用户文档编写者、项目管理 者和客户管理者。这部分工作若处理好了，能开发出很出色的 产品，同时会使客户感到满意，开发者也倍感满足、充实。若 处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价 处理不好 则会导致误解 挫折 障碍以及潜在质量和业务价 值上的威胁。因为需求分析奠定了软件工程和项目管理的基础， 所以所有风险承担者最好是采用有效的需求分析过程。软件需求的定义IEEE软件工程标准词汇表(1997年)中定义需 求为求为(1)用户解决问题或达到目标所需的条件或权能 (Capability)。(2)系统或系统部件要满足合同、标准、规范或 其它正式规定文档所需具有的条件或权能。(3)一种反映上面(1)或(2)所描述的条件或权能的 文档说明。需求工程领域中常见术语(1)软件需求包括三个不同的层次―业务需求、 用户需求和功能需求―也包括非功能需求。用户需求和功能需求 也包括非功能需求业务需求( business requirement)反映了组织机构或客户对 系统、产品高层次的目标要求，它们在项目视图与范围文 档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须 要完成的任务，这在使用实例(use case)文档或方案脚本 (scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现 功能需求 定义 发人员必须实现 的软件功能，使得用户能完成他们的任务，从而满足了业 务需求。所谓特性(feature)是指逻辑上相关的功能需求的集 合，给用户提供处理能力并满足业务需求。非功能需求作为补充，软件需求规格说明还应包括非功 能需求，它描述了系统展现给用户的行为和 能需求 它描述了系统展现给用户的行为和 执行的操作等。它包括产品必须遵从的标准、 规范和合约；外部界面的具体细节；性能要 求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反 映产品功能。多角度描述产品对用户和开发人员都极为重 映产 功能 多角度描述产 户 发人 都极为重 要。值得注意的一点是，需求并未包括设计细节、实现细节、 项目计划信息或测试信息。需求与这些没有关系，它关注 的是充分说明你究竟想开发什么。准确说明开发什么?开发软件系统最为困难的部分就是准确说明开发什 么。最为困难的概念性工作便是编写出详细技术需 求，这包括所有面向用户、面向机器和其它软件系 统的接口。同时这也是一旦做错，将最终会给系统 带来极大损害的部分，并且以后再对它进行修改也 极为困难。为什么这么说呢，因为在大多数的软件系统中，最 终用户可能都不清楚他的需求是什么，这是千真万 确的。如果你的用户告诉你需求就是这些了，不要 相信他，继续刨根问底，直到你们都筋疲力尽了。需求分析定义需求分析是指理解用户需求，就软件功能与客户达 成 致，估计软件风险和评估项目代价，最终形成 成一致，估计软件风险和评估项目代价，最终形成 开发计划的一个复杂过程。（这个和微软的做法不 太一样，微软的需求分析大多是市场人员和用户协 助小组的人去评估用户的接受程度，这一点也可以 理解，因为公司的性质有根本差别）在这个过程中， 用户的确是处在主导地位，需求分析工程师和项目 经理要负责整理用户需求，为之后的软件设计打下 基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档； 3.Acceptance Plan.需求分析广义定义从广义上理解：需求分析包括需求的获取、分析、 规格说明、变更、验证、管理的 系列需求工程。规格说明、变更、验证、管理的一系列需求工程。狭义上理解：需求分析指需求的分析、定义过程。需求分析的任务简言之,需求分析的任务就是解决&做什么& 的问题,就是要全面地理解用户的各项要 的问题 就是要全面地理解用户的各项要 求,并准确地表达所接受的用户需求.需求分析的过程需求分析阶段的工作,可以分为四个方面:问题识别; 问题识别 分析与综合; 制订规格说明; 评审.需求分析的几个方面需求分析可分为问题识别、分析与综合、编制需求分析文档、 需求评审等四个阶段，包括以下几个方面：确定软件所期望的 用户类；获取每个用户的需求；了解实际用户任务和目标以及 这些任务所支持的业务需求；分析员与用户的信息以区别用户 任务需求、功能需求、业务规则、质量属性、建议解决方法和 附加信息；将系统级的需求分为几个子系统，并将需求中的一 部分分配给软件组件；了解相关质量属性的重要性；讨论得出 实施优先级；将所收集的用户需求编写成需求规格说明和模型； 评审需求规格说明，确保与用户达成共识。问题识别就是从系统角度来理解软件,确定对所开发系 统的综合要求,并提出这些需求的实现条件, 统的综合要求 并提出这些需求的实现条件 以及需求应该达到的标准.这些需求包括：功 能需求(做什么),性能需求(要达到什么指标), 环境需求(如机型,操作系统等),可靠性需求 (不发生故障的概率）,安全保密需求,用户界 面需求,资源使用需求(软件运行是所需的内 存,CPU等),软件成本消耗与开发进度需求,预 先估计以后系统可能达到的目标.分析与综合逐步细化所有的软件功能,找出系统各元 素间的联系,接口特性和设计上的限制,分 素间的联系 接口特性和设计上的限制 分 析他们是否满足需求,剔除不合理部分,增 加需要部分.最后,综合成系统的解决方案, 给出要开发的系统的详细逻辑模型(做什 么的模型).制订规格说明书即编制文档,描述需求的文档称为软件需 求规格说明书.请注意,需求分析阶段的成 求规格说明书 请注意 需求分析阶段的成 果是需求规格说明书,向下一阶段提交.评审对功能的正确性,完整性和清晰性,以及其 它需求给予评价.评审通过才可进行下一 它需求给予评价 评审通过才可进行下 阶段的工作,否则重新进行需求分析。议题业务访谈 专题会议 业务过程/工作流程观察 遗留文档 问卷调查 原型试验 领域专题讨论会议需求获取的沟通原理进行分析沟通的定义是人们分享信息、思想和情感的任何过 程，另 种定义是沟通是通过信息交互作用来影响 程，另一种定义是沟通是通过信息交互作用来影响 看法、决策和行为，在需求获取的沟通中信息就是 这个系统的需求。需求获取沟通的目的就是为了建 立系统需求的概念，统一对系统需求的定义和理解， 即系统应该做什么，不应该做什么。沟通的模式见 下图沟通必须是双向的注意这里沟通必须是双向的。需求获取中的沟通要素包括传送 接收者 任何沟通参与者都不例外既是传送者也是接收 传送－接收者，任何沟通参与者都不例外既是传送者也是接收 者，沟通参与者都扮演了一定的角色，角色是在相互关系中， 个体所起到的特定作用和可以用一组规范来比照的行为方式， 在需求获取中参与者主要是用户和开发人员； 信息,包括了与需求相关的符号、文章、思想和情感等等； 渠道，通过听觉、视觉或者触觉来实现沟通； 噪音，需求获取过程中噪音主要是对需求定义不同的理解和产 生歧义的信息； 反馈，传送者和接收者之间的相互作用，是沟通成立的必要条 件，反馈不一定是语言，比如回复的email、调查问卷的答案 等等都是不同形式的反馈； 环境，带有主观意味的选择和设定，是沟通发生的地方。沟通方式沟通按照发生的主客体分类，可以分成人际沟通、 人机沟通和组织沟通，组织沟通是指组织成员之间 的信息交流和传递，需求获取是组织沟通的一种,组 织沟通分成了下行沟通、上行沟通和平行沟通，下 行沟通为组织中上级对下级命令、指示或通报等形 成的沟通，上行沟通事下级对上层反应情况的沟通， 平行沟通是组织统一层次之间的沟通，需求获取应 该就是这种沟通，避免成为下行或者上行沟通。沟通的改进&良好的沟通对于一个组织就如血液对于 生命。生命 “ 虽然沟通的最终目的是把信息传递给接收 者，它却有说、写、听等多种方式，沟通 旨在处理信息和改善关系。怎样运用沟通 的技巧来提高沟通的效率？这需要我们从 沟通的多个方面进行改进。多个 行口头沟通口头沟通：通过口头沟通，我们可以以一种更准确、 便捷的、及时性的方式获得信息，为讨论、澄清问 题、理解和即刻反馈提供了场所。在口头沟通时候要观察对方身体语言、语音语调这些丰富 口头交流的重要因素。口头沟通应该坦白、明确，不要在表达自己的意见的时候 产生误导或者难以理解，沟通交流的核心不是语言，而是 理解，口头沟通的双方都应该重视聆听。在沟通过程中信息的发送者和接收者在某些问题上可能有 着截然不同的理解。口头沟通技巧这时应该注意在交流之前尽量获取更多的信息，做一个明晰的阐述要 比总提出问题好，太多的疑问会使你的可信度大大下降，使人们没法 正确的理解你，人们会对你产生消极的印象。正确的理解你 人们会对你产生消极的印象 尽量把问题阐述清楚,让对方理解你的意思和态度,如果你没弄明白对 方的意思，自己却产生了其他的某种理解或是设想，大可以直接问对 方，要尽快地弄清对方的意思，尽早解决在互相交流中产生的误解。让每个人都把心思集中于目标上，建立一个共同的立场，这能使人们 互相理解，不会害怕捅什么娄子，不会自相残杀。了解质询和辩护二 者的区别，花时间咨询其他人的意见，也与对方分享为什么你坚持自 己的立场。口头沟通的时候人们必须谨慎，不要使用可能被理解成是性别歧视、 种族歧视、偏见或者攻击性的言语。因为这种方式是同步的，口头沟 通也要注意时机，闯进用户打断对方工作或者在走廊里面遇到 用户聊上半个小时这都是不太合适的。会议和座谈会议和座谈：会议是加强组织建设，强化成员期望，促进对 项目目标的投入的有效工具和手段。为了使会议有效，会前必须确定会议的目的、与会人员和议程， 并且把会议目的和议程和资料分发给每位与会人员； 会议期间，必须按时召开会议，指定会议记录人员，会议主持 人应该督促而不是支配会议，会议内容应该及时并尽可能记录 下来，在会议或者面谈中应该使用笔记本电脑，指定一个打字 熟练的人把所有的讨论记录下来，记录的同时还要做一定的整 理，另一种办法就是采用录音的方式，会议参与者全心投入到 会议中，而事后通过录音整理。如果不这样做，那么你结束会 会 中 事后 音整 如 这样做 么你结束会 议的时候就会发现，所有的讨论只剩下一个模糊的印象，需求 对你来说仍然是一件遥远的事情，会议结束前总结会议成果并 文档化，请参与讨论的用户对记下的内容评论并更正，控制会 见进度和讨论范围按时结束会议； 会后，公布会议结合，要安排人员对项目决定和安排进行跟进。会议与座谈技巧(7-1)第一次用户和开发人员的会面就像两个陌生 人的第一次见面一样，大家都不知道说什么， 人的第 次见面 样 大家都不知道说什么 问什么，都担心他们说的或做的带来分歧， 他们都在想自己要得到的东西也就是不同的 期望，同时他们都希望同一件事件就是项目 的成功。下面建议的问题列表能够帮助会议 组织者有的放矢织者有的放矢会议与座谈技巧(7-2)第一阶段：从自由的问题开始，得到一些基 本的了解，比如要解决的是什么问题，需要 本的了解 比如要解决的是什么问题 需要 解决方案的人，以及解决方案希望达到的效 果。1、谁是问题的提出者或者是解决方案的受益者？ 2、谁将使用这个解决方案？ 3、成功的解决方案能够得到哪些经济上的利益 （不要涉及到用户的商业秘密）？ 4、是否有或者需要另一种解决方案？会议与座谈技巧(7-3)第二阶段：得到问题的更好理解和用户表达 的想法1、解决方案定位与解决哪些问题？ 2、成功的解决方案将产生什么样的输出？ 3、解决方案将在什么样的环境下使用？ 4、有什么特殊的性能要求或者约束影响了解决 方案 方案？会议与座谈技巧(7-4)第三阶段：关注于会议的效果1、你认为是否有更适合的人回答这些问题？ 1 你认为是否有更适合的人回答这些问题？ 2、是否会议的时间太长，问题太多？ 3、其他人是否能提供别的信息？ 4、是否我们还有其他的问题没有问到？会议与座谈技巧(7-5)处理冲突：沟通过程中不可避免地会产生冲突，在目标、动机、 性格、气质上存在差异产生分歧就会导致冲突，我们必须重视并 且正视冲突。冲突也有其有利的 面，它能够将问题暴露出来， 且正视冲突。冲突也有其有利的一面，它能够将问题暴露出来， 使之及早得到重视；它能够激起讨论，澄清观念；迫使寻求求新 的方法；培养创造性，更好地解决问题。处理冲突有下面几种方 法：1、回避或者撤出：卷入冲突的人员主动从这一情况中撤出来，避免发生 争端。这种做法是一种消极的方法，会使得冲突积累起来，导致后来的逐 步升级。2、竞争或者逼迫：把冲突当成胜－负的局势，认为获胜比相互之间的关 系更有价值，可能会导致人们的怨恨心里，恶化工作气氛。3、调停或者消除：尽力在冲突中找出意见一致的地方，最多可能的忽视 差异，对可能产生分歧的地方不进行讨论，但是这并没有将问题彻底解决。4、妥协：寻求一个调和的折中解决方案，着重于分散差异。5、合作解决问题：直接正视问题，寻求双赢的结局，尽力得到最好、最 全面的方案，卷入冲突的人员都把对方所持观点的假设理解清楚，特别是 那些发生冲突的部分，愿意放弃或者重新定义之间的观点、意见。可以看 出这是最积极最好的处理冲突方法。会议与座谈技巧(7-6)书面沟通：正视文件、备忘录或者邮件这些方式都 属于书面沟通，它的特点是持久性。书面沟通应该 仅仅用在必要的时候并且不会增加双方的工作量情 况下使用，我们往往不愿意在琐碎的文档中寻找那 些能够在下次会议上能口头沟通获得的信息，所有 书面的表达必须清楚、简洁，不能附带与主题无关 的其他内容，用短句来替代长句，用主动语态替代 被动语态，避免使用双重否定或者古汉语词汇，措 词要自然。要 书面沟通也是帮助记忆的一种有效方式。会议与座谈技巧(7-7)讲演和报告：讲演和报告前要明确目的，准备书面 提纲，充分准备多多练习，内容要简明，确认信息 能被清楚、正确的理解，不要以数量而要用质量来 打动接受者，多用图片、表格来说明问题。在讲演 和报告过程中语言清晰流畅、句式简短、要点之间 过渡自然，也应该尽量使用身体语言，有意识的微 笑，同时放松双臂或者加上解释性的手势动作，会 显得更加自信一些并且能够消除紧张情绪。讲演和 报告一定要在规定的时间内完成，不要拖延，最好 留出一段时间与听众进行相互沟通。业务流程需求调研需要充分细致的了解客户目标， 用户业务内容、流程等，这是一个对需求 用户业务内容 流程等 这是 个对需求 的采集过程，是进行需求分析的基础准备。当我们已经了解、理解了用户的业务，于 是可以开始分析需求了。软件系统的需求 分析可以由产品工程师或系统分析员或两 者分阶段合作完成全部的需求分析工作。者分阶段合作完成全部的需求分析工作提取出核心、主要、急迫的业务， 明晰业务流程(2-1)通过需求调研，我们会发现用户各方面的业务很多，从大处着 眼，包括用户的各种业务项目、业务流程，再明细到业务过程 的每一个单据，每一条记录，如生产过程中每一个环节的记录， 办公中的每一个通知，甚至包括文件报刊的收发，计划生育指 标统计等等。如此繁杂的各类业务，我们从何下手？这时需要 我们回头去查看软件的项目规格说明书，再次温故客户对软件 项目或产品的最初提出的需求目标和范围，我们的软件主要是 为用户解决什么样的问题。从众多的业务中提取出用户核心的、主要的、急需的业务，这 些是我们软件需求主要关心所在。写一篇文章需要重点突出， 些是我们软件需求主要关心所在 写 篇文章需要重点突出 主次分明，我以为规划一个软件产品也是同理。提取出核心、主要、急迫的业务， 明晰业务流程(2-2)从用户繁杂的业务中进行业务、业务流程的提取， 把那些分布在各个部门的同 种业务提取出来。把那些分布在各个部门的同一种业务提取出来。比如物资的管理，涉及到生产部门的需用计划，汇 总到物资部门的计划，计划的审批，采购合同， 物资采购，物资部门的收发存业务，生产部门的物 资领用消耗等等，我门需要分析用户的这个业务流 程中哪些是系统能帮助管理的，哪些是要在系统外 处理的，充分分析了用户现有的业务和业务流程， 我们进入下一步骤。运用管理思想，优化业务流程我们提供的是管理软件产品，要帮助用户解决的是管理问题， 那么用户是这样的业务流程，就需要我们分析这样的流程合理 吗，还有缺陷吗，怎样做能提高效率、解决问题，可以运用更 先进的管理思想吗……。一般情况下，我们需要从两个方面考虑业务流程的优化。一方面是我们采用了网络计算机这些新的技术手段，较之原先手工、电话 等方式在信息的传递、信息的共享、数据的处理等方面将会带来新的方式， 必将改变原有的业务流程。另一方面就是我们根据对用户业务的理解，考虑是否可以运用先进的管理 思想，比如MRPII、ERP、SCM、CRM、JIT、EIA、E-Business等等管 理模型，进行现有业务流程的重组或优化。当然一旦牵涉到业务流程的修 改一定要与客户的中高层管理者进行充分的沟通，只有客户认同方可确定， 因为这一定会在软件实施时需要相应的管理配套执行。进行业务分类，规划系统蓝图(2-1)以上都明确了以后，我们可以描绘系统蓝图了。系统有几个子系统， 每个子系统有哪些模块，各个模块处理哪些业务，很重要的一点还有 各子系统模块之间的数据接口关系，基础数据从哪里进入，通过哪些 各子系统模块之间的数据接口关系 基础数据从哪里进入 通过哪些 处理生成哪些结果等等。这个过程需要整理、抽象用户业务，规划软 件实现，规划软件系统模块间的逻辑关系。因为系统的页面实现是按 照系统模块的规划，所以应尽量采用用户易理解、熟悉的方式、词语 进行模块的描述。进行业务分类，规划系统蓝图(2-2)例如ERP系统中的物资管理子系统，首先明确这个子系统是ERP系 统中进行物资相关的业务处理系统，同时它为主生产系统、成本管理 子系统提供生产物资供应、领用消耗核算等的数据支持。因此在规划 子系统提供生产物资供应 领用消耗核算等的数据支持 因此在规划 子系统模块时，按照业务过程模型，应包含物资需用计划、物资采购 计划、出入库管理、库存管理等主要业务模块，再考虑软件运行必须 的初始数据设置，增加一个基础信息维护模块(包括物资大类、物资 编码等信息维护)，还有考虑到不同用户对此系统的不同需求，如更 多的生产人员、管理人员的需求，再单独增加一个综合查询和分析模 块。