需求定义严格来说并不属于需求工程的范畴之内，它是产品立项时要做的事情，最核心的工作是确立一个合理的项目目标与范围。
关于项目目标与范围，企业高层通常是依据自己的洞见与经验去判定，有时缺乏集体智慧与科学验证，导致它与团队实际能力及业务真实需求出现偏差，即找不准要解决的根本性业务问题或发展机会，项目出现“上梁不正下梁歪”的情况。
如果方向错误且船只结构的打造扛不住实际风浪，那么船只不仅偏离合理的轨迹，还会面临惊涛骇浪，最终做了很多无用功。可见，需求定义是不容忽视的一个环节。
需求定义的工作从方向性着手点是确定问题或者寻找机会。
举个例子，当一家杂货店发展为雇用了几个店员的小型超市时，货品丰富，日成交量数十倍增，这时候用EXCLE难以满足经营管理需要，比如多人协作的数据登记工作、数据安全性无法保障、无法固定业务操作流程等问题。
为了解决这个问题，小超市就需要一套采用ERP系统来满足企业资源管理的需要，才能使业务有序、高效率的发展。
也就说，伴随着业务量级的增长，企业都会在资源管理、客户服务等方面出现业务瓶颈，比如资源复用性低、效率差、流程繁琐不可控等，这时候我们需根据业务发展来确定问题或寻找机会来设计产品以支持发展战略。
那么我们如何确定问题or机会（目标）？
一类内部寻根，找到项目发起人深入沟通；另一类是外部溯源，有些项目的发起可能受外部环境影响，比如竞品同行、新技术趋势等等，这时我们需要找到参照物进行研究。
通常情况，我们都是根据数据反馈或者KPI指标来发现表象问题，接下来我们该如何找到问题根源并准确定义问题以及合理的解决思路呢？
1. 对问题达成共识
1.1准确定义问题
首先我们自己要问题清楚定义，这里涉及到两个技巧。
第一、转换思维，即把未知解问题转换成已知解问题。比如朋友欠钱不还，自己追还不了，那么可以找到他的身份信息起诉，自己不会起诉不要紧，委托个律师就好了。通过解决一些系列已知解问题来解决根本问题
第二、追溯本源。问题经常会被表象掩盖，如果直接解决表层问题，不仅不能治本，还会带来其它方面的问题。
举个例子，在一个山脉内建了一条很长的汽车隧道，为了防止停电时隧道内发生车祸，交通部在隧道入口写了“进隧道前请打开车头灯！”的提示语。
但是，不久后有司机投诉，由于隧道出口景色太美，司机经常忘记关灯，导致返程时汽车没电了。
有人提出可以提醒他们出隧道时关掉车灯！那么我们思考问题解决了没？没有，因为在司机如果是在夜晚行驶（不同的时间状态下）时候会懵圈。
有人说那我们可以提示司机“白天，进隧道时打开车头灯，出隧道关闭车头灯；晚上出隧道时不要关闭车头灯！”,显然这个方案弊端就是文字太长，在高速行驶上，司机没有时间和注意力看完一段文字。
那么，我们思考怎样根本上解决问题？
案例中，我们对问题的因果最终推导是：车没电是因为司机忘记关灯，而忘记关灯时因为缺乏提醒。
那么，解决方案在于我们要如何提醒且又能避免夜行司机产生误解呢？答案是提示“你的灯亮着吗？”，这便引导司机关注周围明暗场景来决定自己的车头灯是否应该打开。
这个例子就是示范我们如何定义问题以及确定根本问题。
1.2 找到问题的根本原因
1.2.1 利用工具分析
工具1：鱼骨图分析
鱼骨图属于定性分析，它有利于我们追踪到问题的根源，使分析人员将问题的原因放在首位，而不是表象，且能让我们概览导致问题发生的所有原因的全景图，这也为收集资料和行动提供全面可靠的指引。
具体实施方法如下：
1.把第一步定义的每个问题都独立做一次鱼骨图分析
2.群体头脑风暴只找原因而不是找解决方案
3.分类问题，确定问题归属的类型。比如常见的人机料法环
4.如果某个原因属于多个类型，并这个情况多次出现，可以考虑新增问题类型
5.每个原因可以思考what-why-where三者来发展更细层级的原因
6.公开讨论所有原因的想法和经验
7.寻找重复性高的原因（即多人提出的）
8.使用检查表收集资料、制作流程图或进行客户调查，通过帕累托分析法测试
9.各种原因的相对强度
10.投票制达成一致意见，缩小范围进行比对
工具2：帕累托图分析
鱼骨图比较依赖于决策者的经验与洞见，外界一直是出于变化的趋势，为了能够更准确实时把握住根本原因，还需要结合帕累托图分析。它主要作用就是利用2/8定律，去锚定影响问题的最关键根本原因，集合有限的资源优先解决它。
帕累托分析通常是根据问题发生的各原因从相对频率和大小从高到低降序排列的直方图，找到解决80%问题的20%原因。
这里就需要我们去收集已有的产品数据及用户反馈进行分类针对性地统计。
做个比喻，鱼骨图帮助我们找到解决问题的方向靶，帕累托图则是在靶子标上环数。
1.2.2 确定相关人员与用户
在产品需求定义阶段，沟通最多的应该是对应业务的高层人员，方向性决不能出错，此者是管理层，最后是基层操作人员。对于产品的用户，我们切记要分类产品的直接用户，罗列各自的特点并分析，这指导着后续的需求分析。
1.2.2 定义解决方案的界限
我们可以把产品的范围和边界区分开来。范围即产品涉及到的哪些功能和内容来支持业务运转，边界则是产品与人的职责边界。
一个产品划分出子系统之后，子系统中所支持的流程中我们可以切割出边界，如何确定边界有三个因素需综合考虑。
首先我们会以经费、资源等作为考量因素，即多大能耐就做多大的事。
其次，对性价比、可行性方面的考虑，往往需求方出于同样的资源投入想获得更高回报的心理而认为所有需求都是最高优先级，即啥都要，这里我们需要从可行性、人力成本去传达哪些需求该做，哪些需求不该做，哪些先做哪些慢做，哪些能做哪些不能做，以此说服需求方。
最后，对边界的延伸与创新，则比较少见。它是基于特定战略或产品方向去做决策的，通常会把客户及客户行为习惯等纳入产品的考虑范围，把业务流程延伸到人的身边，提高服务支持的便捷性，提高用户体验。
1.2.4 确定解决方案的约束
我们在做设计产品时，不可能去自由发挥，有时候基于产品特性、技术要求、外部条件等因素会做一些限制，就不如建设一栋房子，想要建成什么样的房子，它就会受原材料、地基、土壤、经费、住宅建设政策等条件的限制。软件产品的约束通常会分为技术开发与项目实施这两大类。
技术开发：技术约束、预期的软硬件环境、预期的使用环境等。
项目实施：项目预算、行政约束、进度要求及资源支持、环境约束等。
2. 需求定义产出物中的关键点
2.1 目标
一个好的目标需满足SMART原则，即满足具体的、可度量、可行的、相关性、时间限制这五个要素。下表为例子。
2.2 范围
在目标确定后，需求定义最主要的工作是围绕“范围”展开的，系统需要做哪方面的功能服务才能支撑起业务需要。在范围的文档描述上，我们分别会产出系统的构建图、上下文关系图以及需求大纲，简称为“两图一纲”。
2.3 相关人员与用户
需求定义阶段确定相关人员与用户的目的在于可指导我们在获取需求具体的执行工作，帮助我们了解这些群体，提高产品的可用性。通常我们会收集群体与系统主题的相关经验、技术理解、工作态度、受教育程度、语言技能、年龄等等，即群体的形象建模，其次是他们对产品的关注点或需实现什么利益。
2.4 相关事实与假定
相关事实指的是当前产品所存在的问题，比如说原有的产品的人机交互上异常繁琐，导致效率低下。假定指的是预估未来可能发生的事件导致产品无法应对，需列出假定事件，避免现有的解决方案思考不周，导致做了许多无用功。
03 定义需求范围
前文已说明需求范围的产出物是“两图一纲”，而一般逻辑简单的系统出需求大纲即可。为了让读者更为明白如何操作，因此篇幅会比较长，后续笔者会做细致的分享。
项目的目标与范围就是指南针，方向错了，那么后续的行为就丝毫没有正确可言，因此，我们要避免拍脑袋的事情，毕竟人有时会出现认知偏误的时候，依据管理层的经验洞见不见得是准确，毕竟人脑中的“系统1”有时候会蒙蔽我们的眼睛。
文章首发于公众号“达云霄”，欢迎关注交流。
