需求调研-刘克先

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