需求调研方法论

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