1、需 求 调研方 法 论我在 2010 年 8 月参加国家电网公司审计部的审计信息化创新项目需求调研工作。 对我来说 ， 这是一个很好的研究和实践需求调研的机会， 我完整、 系统的 参加了项目的需求调研过程。 需求调研完成后， 学习研究了他人的需求调研理论， 总结整理了我在需求调研过程中的一些想法，形成本文。 在 编 写 本 文 的 过 程 中 ， 因为时间关系， 未能很系统的一次完成整个文档结构， 经历过数次结构的调整后， 才形成现在的样子， 其中还有很多不完善、 不严谨之处， 还望各位予以指正， 欢 迎探讨。By:张永铅目 录1 需求概述 11.1 软件需求. 11.1.1 需求定义 11.
2、1.2 需求层次 11.1.3 需求来源 11.2 需求调研定义 . 21.3 需求调研目的 . 21.4 需求调研必要性 .31.5 需求调研是否可裁减 .61.6 需求调研启动时机 .62 需求调研过程 72.1 调研实施前活动 .72.1.1 识别调研范围 72.1.2 组建调研团队 72.1.3 确定调研方案 82.1.4 调研准备 122.1.5 前期沟通 132.2 调研实施. 132.2.1 调研实施 132.2.2 经验分享 162.2.3 调研注意事项 193 编写需求规格说明书 2011 需 求 概 述1.1 软 件 需 求1.1.1 需 求 定 义需求是用户 一种期望 ，
3、 是用户期望 改善现状 ， 解决某些问 题或达到 某 种 目标的需要。 需求实现 的过程， 就是通过软件 产品的功能达成用户目标， 使 之与用户期望目标相符的过程。1.1.2 需 求 层 次软件需求的三个层次1业务需求： 反映了组织机构或用户对系统、产品高层次的 目 标 要 求 。2用户需求： 描述了用户使用产品必须要完成的任务。3 功能需求： 定义了开 发人员必须实现的软件功能， 使得用户能完成他 们的任务，从而满足 业务需求。4 非功能性的需求 ： 不 直接完成用户完成某项工作， 但是在用户在操作 系统过程中伴随产生的需要， 描述了系统展现给用户的行为和执行的操作等， 它包括产品必须遵从的
4、标准、 规范和约束， 操 作界面的具体细节和构造上的 限制。1.1.3 需 求 来 源软件需求可以 来自方方 面面，这取决 于所开发 产品的性质和 开发环境 。 下面是几个软件需求的典型来源。1. 访谈、调查 用户或潜在用户 为找出新软件 产品的用 户需求，最直 截了当的 方法是询问他 们。 通过 直接 与 最 终 用 户 的 访 谈 或 调 查 ， 了 解 用 户 目 前 管 理 或 应 用 过 程 中 存 在 的 问 题 、 思想或想法、业务未来发展趋势，经过整理分析，形成软件需求。2. 研究竞争对手 同类产品 当用户在实际 工作中产 生出新的需求 后，总会 有对需求感觉 灵敏的厂 商嗅到
5、商机， 把用户的需求转换为产品。 在我们没有更好条件深入到客户中进 行调研的情况下， 可以对竞争对手同类产品进行研究， 发掘产品中的优点和 存在不足，研究产品功能的目的和意义，倒推出软件需求。23.需求分析人员 的经验需求分析人员 要时刻保 持对所在领域 知识的敏 感，勤于思考 ，结合积 累 的丰富的所在领域知识， 加上自己的分析和判断， 形成基于用户实际工作中 需求的假设，形成软件需求。4.市场支持活动 软件产品发布 推广后， 用户在实际工 作中对软 件产品进行检 验。在市 场售后的支持人员在对用户进行培训和提供技术支持工作的同时， 他们收集了 用 户 在 使 用 系 统 过 程 中 所 遇
6、 到 的 问 题 ， 还 接 受 了 用 户 关 于 系 统 改 进 的 想 法 。 因此， 可以通过收集市场支持人员接受的系统改进想法， 并把它们转换为软 件需求。5. 政策制度和法律法规 公司所在的国 家、行业 的政策制度和 法律法规是企业经营活 动过程中 必须遵循的规则， 对公司 活动有强制约束力。 研 究目标企业所在国家、 行业 的 政策、 法规和制度， 发 现其中信息化相关的要求， 经过整理和分析形 成软件 需求。 尤其是当企业所 使用的法律法规、 政策 制度 发生变动时， 是软 件产 品 更新换代的一个重大契机。1.2 需 求 调 研 定 义通常情况下 ，用户无 法 独立直接提 出
7、完整、 准 确的需求， 这就 需要 通 过 项目组的介入， 借助 需求调研把用户已经表述的需求弄清楚， 挖掘用户尚未 说明的需求。需求调研指通 过和 用户 进行沟通和交 流而获取 用户的需求的 一系列活 动 ， 是为编写需求说明书 而做的前期工作。换言之，需 求调研就 是 假设用户已 经掌握需 求 ，通过 某些 手段或方 法 将 需求准确、完整的描述出来 ，以便软件开发的后续活动顺利进行。1.3 需 求 调 研 目 的需求调研就 是 了解参 与 实际工作的 人们 真正 需 要什么样程 序的过程 ， 获 取准确、 清晰、 完整的用户需求信息， 编写需求说明书， 为后续工作 提供依 据。需求调研有
8、三个主要目的：31、获取准确、清晰、完整的需求，包括功能 需求和非功能需求；2、确定需求的分级， 划分需求优先级，指导后续工作；3、 收集调研对象业务资料， 预测需求的发展趋势， 为软件产品发展方向 提供依据。1.4 需 求 调 研 必 要 性1、需求调研是 减小用户“期望差异”的关键一步 软件产品作 为一种特殊 的商品，是 软件公司 通 过有限的技 术手段 、 资 源为了满足用户的需要 而开发出来的。 由于需求 “效用” 的不可计量， 再加上 软件产品不能直接创造价值的特殊性， 用户就有可能会对最终产品产生 “期 望 差 异 ”， 这 种 “期 望 差 异 ”会 影 响 用 户 对 软 件
9、产 品 的 满 意 度 ， 影 响 软 件 产 品的销售。 需求调研就是要了解到用户的期望， 以期在软件研发过程中减小 这种差异，提高用户的满意度。软件需求也 可以说是 用 户在一定的 条件下为 了 改善管理条 件、追逐 更 大 利润的 “欲望” 。 当欲望 得到满足， 人们会感到快乐和幸福， 这就是 “效用 ”。 处于软件产品两端的用户和开发商由于受到客观条件的限制， 双发不能传递 准确的需求信息， 在一开始无法在信息系统 的需求上达成一致意见。 由于技 术 能 力 的 局 限 ， 用 户 很 难 准 确 地 把 系 统 需 求 传 达 给 开 发 商 ； 由 于 业 务 局 限 ， 开发商
10、也很难准确获取用户真实的应用需求。 需求信息的不对称和需求描述 的错位， 容易引起系统设计的缺陷， 最终导致系统应用不理想甚至系统失败。作为客观世 界的存在 ， 用户所处环 境、思想 等 的不同，不 同用户对 同 一 领域的需求是存在差异的。 软件产品是在有限 的资源、 有限的时间、 有限的 技术手段和条件下研发出来的， 不可能获取所有潜在用户的需求， 也不可能 满足所有潜在用户的需要， 这就需要软件产品确立目标用户， 重点关注目标 用户的需求。 能够获取 目标用户的满意， 赢得 目标用户的认同， 促进 目标 市 场的销售，就是一款成功的产品。作为一家商 业的软件 公 司，其追求 的目标是 利
11、 益最大化， 利益的 重 要 来 源就是向市场推出更多令人满意的软件产品 ， 获得市场的成功。 如何令 用户 对我们推出的产品满意， 是作为软件研发、 销 售人员时刻警惕和思考的主题。 在我看来， 让用 户 满意就是在用户看到、 使用我们软件的时候满足其 “期望” ，4甚 至 超 出 他 的 “期 望 ”， 这 就 会 引 起 用 户 的 购 买 欲 ， 从 而 带 来 销 售 机 会 。 而获取、 了解用户的期望 值， 是软件产品能够满 足 用户期望的先决条件， 只有 了解了用户的期望， 通过产品研发最大限度的实现 用户期望， 提升用户的 满 足感， 研发出的软件产品才能更好贴近 用户的期望
12、， 提升用户期望的满足度。结论：1） 软件产品一定要有目标客户， 目标客户的需求才是需要重点关注的 ；2） 需 求 调 研 很 重 要 ， 是 软 件 产 品 能 够 赢 得 市 场 的 先 决 条 件 ， 是 任 何 软 件公司、软件研发人员必须重视的一个环节。3） 需 求 调 研 和 分 析 是 信 息 化 建 设 的 第 一 步 ， 牵 一 发 而 动 全 身 ， 做 好 需 求调研是软件产品成功的关键一步 。2、需求变动大， 可能是因为需求不完整、不清晰。 参与过软件研 发的很多人都有这样的 抱怨“ 用 户需求又变了 ，截至今 天已经变了 3 次， 很多工 作得重新返工， 真不知 道下
13、次还会不会变了。 ”， 尽管 无奈， 又不得不对改变的需求重新评估、 设计、 开发、 测试， 这些变 更不只 是加大了软件研发的成本， 对研发人员的积极性也是一种挫伤， 降低了研发 人员的成就感。尽管需求发生 变化时， 对软件研发影 响很大， 但往往 需求变 更又是不 可 控的， 需求变化是客观存在的， 是作为软件研发人员必须正视和面对的问题。 随着目标用户的变化， 目 标 用户认知的提高、 用户内部环境的变化、 外部 环 境的变化、 技术的进步 等 ， 需求也总是在不断 改变的 ， 往往是在前期 需求 得 到满足后，会产生出更高层次的需求。诚然，为保证 软件研发 的顺利进行， 保证软件 产品
14、的按时交 付， 我们 要 对需求加强管理， 控制 需求变更， 但是面对变 更， 我们更应该考虑如 何减 少 变更发生的机会， 让我 们更多掌握研发的主动权。 更何况控制需求变 更， 不 可避免的要牺牲用户的满意度， 在软件产品还没有交付到用户手中时， 已经 产生了“期望差异” ，势必对产品的销售造成影响。换个角度看这 个问题， 用户的需求总 是发生变 化， 很有可能 是我们原 本 就没有完全获取用户 的需求， 或者没有挖掘出用户隐含的需求， 研发所依据 的需求是不完整、 不清晰的 。 通过需求调研， 是获取完整、 清晰用户需求的5很好途径， 有了完整、 清晰需求作为研发依据， 可以很好降低需求
15、发 生变化的几率。 结论：1） 需 求 变 化 是 客 观 存 在 的 ， 作 为 软 件 研 发 人 员 必 须 保 持 良 好 心 态 处 理 好需求变更；2） 需 求 在 一 定 的 时 间 范 围 、 一 定 的 环 境 下 （ 经 济 环 境 、 组 织 结 构 、 发 展期间、IT 应用水平） 、一定的 用户群体范围内是确定的，或者说是相对确 定的。3） 加 强 需 求 管 理 ， 进 行 需 求 调 研 ， 尽 快 、 尽 早 获 取 完 整 、 清 晰 需 求 是 比控制需求变更更好的办法；3、错误越早修复成本越低 需求阶段是软 件研发中 的一个重要阶 段，其成 果是研发 后续
16、 各阶段工 作的重要依据， 对研发有着重大影响 ， 需求质量的高低往往决定着一个项目的 成败。 做好需求调研是获取完整、准确、清晰需求的前提，准确的需求是 项目成功的关键。据权威机构对软件各阶段发现错误修复成本的统计，如下图：需 求设 计 编 码单 元 测试 验 收 测试维 护从上图可以看 出，在软 件研发过程中 ，越到后 面阶段修复错 误的成本 越6高， 而且往往是需求阶 段成本的成百上千倍 。 进行需求调研， 可以尽 早使 不清晰的需求更加明确， 可以对不准确的需求进行修订， 补充完善需求 ， 尽早 发现错误， 尽快修复， 减少研发过程中后续阶段的潜在错误数， 缩短 研发周 期，降低研发成
17、本。结论： 需求调研可以有效减少研发过程 中潜在的需求错误数量， 降低研发成本。1.5 需 求 调 研 是 否 可裁 减在实际的研发 过程中 ， 由于外部环境 或内部环 境的压力，软 件研发往 往 面临着时间紧、 任务重 的局面， 为了能够保证 按时交付软件产品， 项 目管 理 者往往会选择裁剪或压缩需求调研， 而给软件编码 和测试预留充足时间， 结 果往往是项目结束时按期交付了产品，质量 如何就不好说了。在我看来，这 样的过程 是很 危险的， 很可能是 花费了大量的 时间成本 和 人力成本， 得到一个并 不被市场认可 的产品， 公司浪费了人力财力， 参与 其 中 的 研 发 人 员 也 不
18、能 从 中 获 取 成 就 感 。 即 使 软 件 研 发 团 队 面 临 着 工 作 量 大 、 人员不足、 时间紧张的局面， 研发团队也不能在不了解需求的情况下直接编 码，凭自我感觉做事。需求不清晰、 不完整、 不稳定 是项目最大的风险， 可能导致项目的返工， 导致项目延期， 最终导 致项目的 终止。 一个有 生命力的软件产品， 必 然要 以 真实用户的需求为依据， 严谨的研发过程为保 证， 从 用户中来， 回到 用户中 去。需求调研的过 程是否可 以裁减，我认 为是可以 的，只要 需求 是清晰、 完 整、 准确的， 并且研发团队 与 用户对需求的认知是一致的， 在这样的条件下， 需求调研
19、过程是可以裁减的， 但是建议项目团队出具需求文档， 便于项目的 传承交接。 在其他情况 下 ， 需求调研过程应该 都是不可以裁减的， 但 可以 根 据条件选择适合的调研方式。1.6 需 求 调 研 启 动 时机从软件研发阶段来看， 项目立项后， 软件产品范围和目标用户就确定了， 产品人员就可以着手 准备进行需求调研了。72 需 求 调 研 过 程2.1 调 研 实 施 前 活 动2.1.1 识 别 调 研 范 围需求调研范围 对需求调 研过程影响重 大，决定 了需求调研对 象、调研 参 与人员和调研周期 的长短， 清晰、 准确的需求 调研范围是调研活动获得成功 的先决条件， 在决定进 行需求调
20、研后， 必须要 尽快识 别 需求调研范围 ， 确定 调研内容。调研范围从宏 观上划分 了调研内容边 界，决定 了本次调研的 主要内容 ， 可 以 依 据 产 品 范 围 和 预 期 目 标 分 析 目 标 组 织 特 征 和 业 务 特 征 ,确 定 需 求 调 研 范围，划分清楚调研业务边界 。如果一次需求 调研范围 过大，则可能 导 致调研 实施周期长， 调研质量 不 稳定。 在这种情况下， 项目管理者可以依据 经验把调研范围划分成若干个 业 务域，识别其中关键 的业务域，确定调研重点，便于调研过程的控制。2.1.2 组 建 调 研 团 队项目成功的一个重要前提条件就是有一个责权分明、 强
21、有力的执行团队。 根 据 项 目 需 求 调 研 工 作 要 求 ， 为 及 时 有 效 沟 通 ， 更 好 的 推 进 需 求 调 研 工 作 ， 组建调研团队，可以视项目大小和复杂程度确定人员要求和数量。需求调研工作 的参与方包括业务用户和调研实施人员：1、 业务用户： 由熟悉 调 研范围相关业务实际工作的用户组成， 负责提出 需求，评审需求结果 ,协助调研实施人员完成需求调研工作；为保证需求 调研的质 量 ， 需求调研 应该选择 尽 可能多的用 户进行调 研 ， 但 是 由 于 项 目 时 间 和 成 本 上 的 原 因 ， 不 可 能 对 所 有 的 用 户 都 进 行 需 求 调 研
22、 ， 所 以 要 识 别 出 能 够 确 定 需 求 和 便 于 了 解 业 务 流 程 的 用 户 作 为 每 类 用 户 的 代 表。系统用户在 很多方面 存 在着差异， 例如： 知 识 技能、所处 岗位（ 所 进 行 的 业 务 过 程 ） 、 权 限 、 地 理 上 的 布 局 以 及 个 人 的 素 质 和 喜 好 等 等 。 根 据 这 些 差异， 你可以把这些不同的用户分成不同的用户类 ， 从每类用户中选择具有 代表性的部分用户 作为调研对象。 每类用户户至少选择一位能真正代表他们8需 求 的 人 作 为 代 表 并 且 能 够 作 出 决 策 ， 用 户 代 表 往 往 是 本
23、 类 用 户 中 三 类 人 ：对项目有决定权的领导、 熟悉业务流程的专家 、 系统最终用户。 每一 个 用户 代表者代表了一个特定的用户类， 并在那个 用户类和开发者之间充当主要的 接口， 用户代表从他们所代表的用户类中收集需求信息， 同时每个用户代表 又负责协调他们所代表的用户在需求表达上的不一致性和不兼容性。用户类不一 定都指人 ， 也可以包括 其他应用 系 统、接口或 者硬件， 这 样 做使得与系统边界外的接口也成为系统需求。 将用户群分类并归纳各自特点， 并详细描述出它们的个性特点及 任务状况， 将有助于需求的获取和系统设计。2、 调研实施人员 ： 由熟悉调研业务领域人员组成， 负责
24、组织、 协调和开 展需求调研工作， 记录调研内容，编写需求说明书。调研实施人员是整个需求调研过程的 执行者， 通过调研实施人员按计划 、 按步骤的与用户沟通，收集调研范围需求，最终出具需求规格说明书。调研实施人员的能力和活动对需求调研的进度、 质量起着重大影响作用。 调研实施人员的组成应以互补为原则， 至少由 三类人组成： 技术人员 、 业务 人员和管理者，根据需求调研范围选择能力与之相匹配的人员参与调研。确定调研实施 人员后， 结合调研实施 人员能力 和调研内容， 以充分发 挥 个人特长和利于需求调研为原则， 确定调研实施人员角色， 并结合调研范围 进行分工。3、 需 求 调 研 管 理 人
25、 员 ： 负 责 需 求 调 研 工 作 的 整 体 工 作 部 署 ， 重 大 业 务 、 进 度等事项的协调，调研 进度和质量的控制。2.1.3 确 定 调 研 方 案2.1.3.1 调研方 式在进行调研前 ，项目负 责人要充分了 解参与调 研双方的基本 情况， 依 调 研对象的工作习惯、 业务能力及调研人员能力、 调研进度要求等因素选择调 研方式。2.1.3.1.1 主导型 调研参与调研的用 户 对调研 范围业务领域 内知识、 经验不足，没 有系统、 完 整的认识， 在调研过程中 需要充分发挥调研实施人员的“专家”作用， 利用9调研实施人员掌握的知识、 经验整理需求概要内容， 提交给用户
26、进行分析和初步确认， 最终由 用户和调研实施人员对需求内容进行细化、 确认的过程称 之为主导型调研。此种调研方式 对调研 实 施人员能力要 求高， 调 研实施人员可 以根据项 目 时间要求自由安排进行 调研， 进度风险较低。 但是由于缺少业务用户的支持， 需求质量往往依赖于调研 实施人员的能力， 导致需求结果与业务用户 的真实 意图可能存在偏差，给 调研进度和需求质量带来风险。采用主导型调 研方式， 调研 实施人员 不仅要求 具备业务领域 内知识和 丰 富经验， 还要有良好的 沟通协调能力， 在调研 过程中 ， 要反复和 业务 用户 进 行沟通，对双发达成一致的需求必须由 业务用户签字确认。2
27、.1.3.1.2 引导型 调研业务用户在调 研 业务领 域内有较为完 整、系统 的知识、经验 积累，在 调 研过程中， 调研人员利用自身掌握的 知识引导业务用户将需求阐述完整 、 清 晰，最终由用户对需求进行确认的过程称之为引导型调研。此种调研方式 的调研过 程业务用户 和 调研 实施 人员相互配合 程度 高， 调 研实施人员可以根据项目进度要求 安排调研计划， 按计划进行调研。 调研实 施人员通过引导业务用户 提出需求， 利用自身 的知识积累、 职业判断 、 整理 需求信息， 由业务用户对需求 进行确认， 此种调研方式的进度和质量 风险最 小。2.1.3.1.3 被动型 调研业务用户强势 ，
28、且在 调 研领域内知识 、经验丰 富，对未来 建 设系统有 较 为清晰的认识， 在调研 过程 中 采取由业务用户主动说明、 阐述需求， 调研人 员记录、 分析需求的方式， 或由业务用户按照调研实施人员要求出具需求的 方式，称之为被动型调研；此种调研方式 对调研人 员要求最低， 但调研人 员不能掌握调 研进度， 无 法对收集到的需求质量进行判断，因而进度风险较大。采用被动型调 研方式， 调研人员要提 前做好调 研提纲，把调 研内容划 分 成若干个可独立调研的调研点， 并按照调研提纲制定调研计划， 按照调研计 划进行调研， 并在过程 中加强监控， 发现偏差 尽快采取措施， 降低进 度偏 差并划分清
29、楚每个活动的边界；10风险。 在调研过程中， 把 调研对象提出的需求与调研提纲进行比较， 分析收集的需求是否全面，保证需求质量。2.1.3.2 调研策 略1、由粗到细，从宏观到微观 ，由外到内，逐步深入 需求调研是一项系统工程，调研过程是围绕 业务需求展开的，调研收集的用户需求必须参照业务需求。 调研过程必须 先从宏观上了解用户业务的 整 体概况， 再逐步依序有计划的 深入细节， 在过程中不断修正对业务概况的理 解， 直至完成整个调研活动 。 因为对于用户的业务而言， 我们是外行， 如果 从业务细节着手， 很容易迷失方向， 失去对 业务核心的把握。 同时要认识到， 对于一个外行而言， 我们对细
30、节的 理解也必定是有限的， 不要指望自己能够 无 穷 的 、 彻 底 的 了 解 每 一 个 细 枝 末 节 。 一 是 项 目 是 有 计 划 、 有 成 本 控 制 的 ， 不可能有无限的时间给你了解， 二是 用户作为业务领域专家， 对业务 有很好 的理解， 作为调研实施人员也 没有必要熟悉每个细节， 因为未来的系统也不 可能完全包办所有业务的细节， 还有很多事情是要靠 用户企业中这些具有专 业技能的人来做的。2、从不同层次的 用户代表那里收集不同层次的需求 不同层次的用户 由于工作内容、擅长业务等的差异，造成不同层次用户往往对同一业务有着不同层次的需求。 作为调研人员， 我们要明确知道哪
31、类 需求应该从哪个层次的用户获取， 并在调研过程中检查需求 调研对象 的层次 和获取需求的层次是否 一致。 通过由上到下的逐级访谈， 对未来系统的描述 就从一个大黑箱变成多个小黑箱， 再变成透明、 明确、 详细的系统定义的过 程。通过调研企业高层决策者， 更多的是了解系统预期目标、功能蓝图；通 过调研业务操作人员， 可以收集业务细节和操作细节。3、以业务领域为主线，搞清楚每个业务的环节流程关系1） 按 照 调 研 内 容 的 关 联 程 度 和 特 征 ， 把 调 研 内 容 划 分 成 若 干 个 调 研 主 题，先理清楚每个主题的目标以及和其他主题发生的关系；2） 理 清 楚 每 个 主
32、题 内 部 存 在 的 活 动 以 及 和 其 他 主 题 之 间 发 生 的 活 动 ，113）针对每个活动进行调研，弄清楚每个活动的流程环节和内容。2.1.3.3 调研方 法需求调研方法 一般有 实 地观察法、面 谈法、 问 卷调查法、查 阅资料等 方 法。1、实地观察法 不和调研对象 进行正面 接触，而是在 旁边对具 体业务 进行观 察，参观 调研对象的工作流程， 观 察调研对象的操作。 根 据观察收集到的信息， 进行 整 理和分析，出具需求 规格说明书。2、面谈法 与调研对象进 行 面对面 交谈，由调研 对象描述 业务信息和需求信息， 调研人员向调研对象提出事先准备好的问题， 并记录访
33、谈过程。 经过对访谈过 程记录的整理和分析出具 需求规格说明书。3、问卷调查法 调研人员根据 调研内容 将相关问题制 成问卷表 格，向调研对 象发放调 研问 卷 ， 调 研 对 象 根 据 实 际 业 务 填 写 问 卷 表 格 ， 调 研 人 员 按 时 回 收 问 卷 表 格 。 调研人员根据收集 到调研问卷进行整理和分析， 获取需求， 出具需求 规格说 明书。4、查阅资料法 收集调研对象 在调研范 围内相关的规 章制度、 规范指南、工 作过程产 出等书面资料，并对收集到的资料进行整理和分析，获取需求的方式。 对于需求调研 来说，访 问调查宜采用 直接面谈 ，并且使用非 标准化的 方式，
34、这样便于发挥和沟通 ， 通过调研过程的互动， 可以激发调研对象积极性， 收获调研实施前遗漏的需求； 问卷调查法 是标准化调查， 可作为一种辅助手 段， 对于较为复杂的信 息系统调研， 不建议问 卷调查作为唯一调研方法； 而 实地观察法和查阅资料法， 作为由调研人员主动实施的调研方法 ， 依赖于调 研人员的主观判断， 有一定局限性， 可作为一种辅助手段对收集需求进行判 断。几种常用调研方法 比较表：调 研方 法 调 研周 期 调 研成 本 人 员要 求 调 研效 果12实地观察法 长 次高 次高 中面谈法 次长 高 低 优问卷调查法 中 中 中 良查阅资料法 短 低 高 差2.1.4 调 研 准
35、 备为确保调研工 作的顺利 开展，在调研 实施开始 前， 应安排一 系列支持 性 工作，加强团队管理和建设，保障调研工作的顺利进行。1、编制需求调研 计划 需求调研过程 是项目的 一个阶段，需 求调研计 划是项目计划 的一个组 成部分。 在需求调研范围、 调研团队确定后， 调研负责人预估工作量， 编制调 研计划。通常来说，需 求调研过 程是非标准化 的过程， 在调研的过程 中围绕主 题 进行发散性的探讨， 编 制需求调研计划， 任务 的粒度一般只需到业务块， 由 调研人员把握具体进度， 调研人员可以视调研 过程的实际情况在 “大 ”计划 指导下灵活调整细节计划。2、编制调研活动使用的文档模版
36、调研活动的主 要成果是 记载需求的一 系列文档 ，为便于文档 的理解和 后期整理、 使用， 软件需求应使用统一的 模版， 并按照一致的规范编写， 调 研 过程使用的文档模版 主要包括调研记录模版、 用户需求说明书模版、 软件需 求说明书模版等。编写规范和模版确定后，在调研组内进行推广、培训。3、准备调研过程使用的工具， 并分发给参与调研人员， 如 word、 excel、 visio等。4、制作调研提纲 为确保调研质 量，在调 研活动实施前 ，调研人 员应根据调研 范围编制 调研提纲。 调研提纲至少应包括如下几个方面：1） 调研对象的基本情况2） 调研对象的预期目标133） 调研业务的功能需求
37、4） 调研业务的非功能需求 调研提纲是贯 穿于整个 调研活动，在 调研实施 过程中，调研 人员可以 根据 调 研 提 纲 引 导 用 户 提 出 需 求 ， 检 查 用 户 提 出 需 求 是 否 完 整 ； 调 研 结 束 前 ， 调研提纲是判断调研是否完成的一个重要依据， 调研提纲所有内容都已经收 集到相关用户需求，调研活动可以宣告完成。5、调研背景培训 向调研人员介 绍本项目 的主要目标、 项目范围 和重点 工作， 避免在需 求 调研过程中业务人员所提需求超出范围，抓不住重点； 介绍调研对 象 基本 情况 ，包括调研 对象 目 前总 体状况、主 要业务 、组 织 机构和关键人物 等； 培
38、训调研对 象 的行 业知 识，学习调 研对象 使用 的术语，标 准，以 便能 够 准确的理解用户的需求，提高 调研人员的行业知识面；2.1.5 前 期 沟 通在调研实施前 的准备工 作基本就绪， 调研工作 实施前，由调 研工作负 责 人将调研工作计划、 团队及分工等信息告知 业务用户， 便于业务用户进行 调 研的相关准备工作。2.2 调 研 实 施2.2.1 调 研 实 施一、倾听、记录需求 以用户为主， 面对面的 进行沟通和交 流，完全 倾听 用户的心 声， 调研 实施随时记录用户所说的一切 有用信息， 并使用调研记录模版格式记录下自己 的认识和问题。 用户 完成某一主题的表述后， 调研人员
39、复述自己记录的需求 内容， 在复述的同时可以结合自己的认识和记录的问题发表建议， 使得记录 的需求条理化、合理化。调研内容应至少包括以下内容：1. 用户和本行业业务现状 及存在问题；2. 调研对象涵盖业务的组织机构及对应职责和权限；143. 调研对象主要业务 及业务的大概流程， 每个业务的流程流经哪些部门，业务如何在部门之间流转 ；4. 调研对象解决问题、改变现状的需求内容。5. 调研业务未来发展趋势是怎样的？6. 非功能方面的需求 调研记录是调 研人员在 调研过程中记 录下调研 对象的意思表 述，是需 求最为原始的记录， 是进 行需求分析、 总结的唯 一依据。 调研记录的质 量高 低 直接决
40、定了需求质量的好坏， 写好调研记录不仅要求调研人员如实记录调研 对象的真实意图， 还需要根据自己的理解将用户繁琐、 含糊不清的语言转换 为言简意赅的语句。调 研 记 录 应 至 少 包 括 业 务 流 程 、 工 作 方 法 和 具 体 内 容 ， 推 荐 使 用 4W1H的方式编写调研记录 ，4W 即“What、Who、When、Why”,1H 即“How” 。 What 需求是要做什么， 实现什么 目标？通过把调研内容划分成若干领域， 逐步弄清各个领域的工作流程和工作内容。 Who处理过程中涉及了哪些部门、 人或岗位， 业务 过程会有哪些相关者 ？ When在什么时间或什么条件下发生，如果
41、是周期性构成， 周期有多长 ？ Why为什么会 产生这个需求，需求的目的是什么？ How 如 何 完 成 需 求 处 理 过 程 ， 为 完 成 业 务 目 标 所 采 用 的 方 法 或 手 段是 怎 样的？二、引导需求 由于用户语言 表达、个 人能力 、所处 环境 等原 因，有时不能很好表达 内心想法， 这样的 情况下 调研实施 人员的 业务背 景和经验 往往对 需求收 集有效 性有很大 的影响 。需求 调研过程 不是简 单的听 用户讲， 而是需 要我们 去引导 用户讲出 他们真 正面临 的问题 和 解决问 题的想 法， 通过 我们积 极的沟 通让 用15户把他们真实的想法真正的表达出来。
42、引导用户的需 求应做到 能够描述用户 的常规需 求外，能够发 掘用户的 潜 在需求， 争取能 够提出 用户的兴 奋需求 ，挖掘 用户的 隐 性需求 ，这样 作出的 软件才有生命力，才能真正体现出软件的价值 。引导用户需求的几种常用方法： 向用户讲述基本的计算机操作。 向用户演示将要实施的系统的原型。 从软件开发中需求的 完整、 准确、 清晰、 一致等几个方面入手 ,使得 用户提出的需求完整、准确、清晰、前后一致 。 从显性需求出发，推断用户需求的真实意图， 超越显性需求， 发掘 潜在的隐性需求。三、评估需求 不是所有需求 都是受欢 迎的，也不意 味着 用户 提出的所有需求都是正 确的。在调研过
43、程中，往往存在着 如下情况： 由 于 用 户 所 处 环 境 （ 如 工 作 内 容 的 差 异 ） 的 不 同 ， 不 同 岗 位 、 层 次 的用户的需求层次不同， 彼此间 对类似业务提出的需求存在着差异； 由 于 用 户 个 人 能 力 的 原 因 ， 对 类 似 业 务 提 出 的 需 求 不 一 致 ， 相 互 矛 盾； 由 于 用 户 对 计 算 机 知 识 了 解 不 多 ， 提 出 的 需 求 无 法 利 用 信 息 化 手 段 实现，或花费很高的成本实现并不重要的需求；这就需要调研 人员在充 分理解需求的 基础上， 对需求的合理 性、可实 现 性进行评估， 并将评估结果反馈给
44、需求提出人， 与需求提出人达成一致意见 ， 尽可能早的发现不合理需求，减少后期需求分析复杂度和工作量 。 四、需求确认需求调研是一 个漫长的 过程 ，在这个 过程中调 研的 用户在不 同时间对 同 一业务的 表述可 能是不 一样的， 如何避 免由于 用户想法 的改变 而导致 的双方 对需求认知的不一致，是我们在需求调研过程中必须解决好的一个问题 。能够正确理解 用户的需 求，并且将用 户的各种 需求完整地体 现在 需求 规 格说明书 中将更 是一个 复杂而艰 辛的过 程，因 此在每一 次的会 谈之后 必须将16当天的会 谈纪录 形成文 档， 在下 一次的 调研开 始 前由用 户对上 次的调 研
45、记录进行确认，减少需求在传递过程中的损耗。 六、需求分级需求调研收集 到用户需 求后，如何利 用需求进 行系统建设？ 软件研发 的 实际情况 往往是 ：由于 客观条件 的限制 ，我们 没有能力 一次就 把所有 需求做 到尽善尽 美，在 软件研 发过程中 通常采 用迭代 的方法先 把一大 部分有 把握的 需求做好 ，再在 前面成 功的基础 上不断 做好剩 余的部分 ，直至 用户预 期目标 的达成。摆在我们面前 很重要的 一个问题就是 ，如何确 定需求实现的 先后顺序 ？ 哪些需求 是用户 重点关 注，需要 优先、 重点实 现的，又 有哪些 需求可 以暂缓 提供的。 哪些需 求在开 发过程中 应该
46、尽 可能完 整，才能 符合用 户预期 ，又哪 些需求只需提供基本功能，就能满足用户需求的为了使得各阶 段提供的 软件产品更符 合用户预 期，为后续系 统建设、 开 发提供依 据，在 了解用 户需求后 ，很重 要的一 个工作就 是在理 解需求 的基础 上确定需求层级。1）需求满足层级 基本性需求： 用户主动 提出的、迫切 需要实现 、未来建设的 信息系统 必须满足的需求，如果此类需求不获得满足，系统无法达成用户的预期目标。 满足性需求： 符合用户 预期，此类需 求 相对独 立，并且不对 主要业务 实 现造成很 大影响 。需求 实现后， 能够给 用户实 际工作带 来一定 便利， 能够提升用户对软件
47、产品的满意度。 兴奋性需求： 超出用户 预期，是同类 产品无法 满足而未来建 设信息系 统可以满足 的需求 。需求 实现后， 能够给 用户实 际工作带 来很大 帮助， 是信息 系统吸引用户，培养用户忠诚度的重要因素。2）需求优先级 按照用户对需 求关注的 重要程度、需 求对系统 建设目标影响程度，可 以将需求优先级划分为高、中、低三个层次。2.2.2 经 验 分 享1、 未雨 绸缪， 充分 准备17需求调研过程充满着变数，需要提前做好备案，在意外状况发生时 ，依据备案本着更好完成需求调研的目的进行灵活调整。1） 准备好访谈内容列表。 如果你去用户那捕获需求，通常用户会说，我 需要做一个什么样的
48、系统，然后我可以用它来做这个，那个，还有那 个， 然后就不知道该说什么了。 这时， 你 一定要拿出事先准备的问 题列表，针对每个大的功能的每一个功能点进行提问，一个都不能放 过，直至了解清楚列表上的每个细节内容。2） 用户背景、资料研究。 如果你在会面前没有对用户提供的资料，表格 等进行全面研究，对 用户需求就不可能调查全面，你可能需要反复去 约见他，这样你会给用户留下工作效率低的印象， 用户对你会逐渐的 感到厌烦，对你未来的工作表现 失去信心。3） 设计好访谈进 程。通常会面前的问题列表准备时间要远远多于会面的 时间。 通常用 户 在连续和你交谈个小时之后， 就会失去热情和耐心， 这是大部分
49、人的共同特点。所以 调研人员要提前设计好访谈进 程，营 造良好氛围。2、 换位 思考， 问对 问题 通常人们在谈论自己很熟悉的东西时，都会有说不完的话， 调研人员要做 的 就 是 用 怎 样 的 方 式 让 用 户 完 整 、 清 晰 、 准 确 的 将 自 己 的 意 思 表 述 出 来 ， 其中很重要的就是让 用户听懂调研人员的话，并对话题感兴趣。当你向用户提出问题的时候，你可以先进行换位思考，如果有人问你这 个问题你该怎么回答呢？是不是很好回答呢？如果连你也觉得这个问题 不 好回答时，就需要考虑换个问法了。你要针对他们要做的软件的功能，一部分一部分的问，不能着急，要深 入， 并细致， 对于他们如何处理这些事情的操作习惯等都要重视， 因为要改 变他们的习惯， 让他们适应你的软件的一种新的操作方法通常是会降低 用户 满意度的，甚至他们会要求你进行修改。3、 搞清 能正确 回答 问题 的人 不同的问题需要问不同的人，需求中有很多是细小的操作级别的问题，也 有 很 多 是 关 乎 全 局 的 问 题 ， 这 就 要 求 一 定 要 搞 清 楚 什 么 问 题 去 问 什 么 人 。18很多需求调研 人员抱怨说， “用户答不上这些 问题， 他们自己都不知道要怎么做” ，如果你碰到了这种事情，就要反省一下，你问对人了吗？ 用户中有一些是大干部，有些
