今天呢，想用故事说话，先看看啥叫用户需求挖掘。其实看完故事之后，我自己颇为震撼，请看。
故事一：
100多年前，福特公司的创始人亨利·福特先生到处跑去问客户：“您需要一个什么样的更好的交通工具？”几乎所有人的答案都是：“我要一匹更快的马”。
很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求。但是福特先生却没有立马往马场跑，而是接着往下问。
福特：“你为什么需要一匹更快的马？”
客户：“因为可以跑得更快！”
福特：“你为什么需要跑得更快？”
客户：“因为这样我就可以更早的到达目的地。”
福特：“所以，你要一匹更快的马的真正用意是？”
客户：“用更短的时间、更快地到达目的地！”
然而，福特并没有去马场而是发明了汽车，很好的满足了的客户的需求。
故事二：
某富翁想娶老婆，有三个人选，富翁给三个女孩各一千元，请她们把房间装满。
第一个女孩买了很多棉花，装满房间的1/2。
第二个女孩买了很多气球，装满房间3/4。
第三个女孩买了蜡烛，让光线充满房间。
最终，富翁选了胸部最大的那个。
大家应该都听过这两个故事，告诉我们要通过现象看本质，从收集起来的数据中发现新的需求。就好比，你问女票情人节想要什么礼物，她们很可能会说“不用送了”、“随便吧”，但如果你真的照办的话，那就GG了...
所以，了解用户的真实需求非常重要！！！ （敲黑板···）
一、到底什么是需求？
百度百科是这么说的，需求(Demand) 是指人们有能力购买并且愿意购买某个具体商品的欲望。
在我的眼中，指的是人们真正想要解决的某种问题。
二、什么是需求分析？
我的理解是，对要解决的问题进行详细分析和深刻的理解，弄清楚产生该需求的根本原因和具体的要求，以及预期的结果。
三、需求来源于哪里？
可以分为老板需求、公司战略、用户需求、市场需求、同事反馈、竞品分析、头脑风暴。
1）老板需求：优先级最高，能满足尽量满足。但要积极思考老板提出这个需求目的是什么、有什么意图、要做些什么，结合数据和制作图表进行分析来确认需求的合理性。
2）公司战略：需求与公司战略不一致很危险，一致才能走的更远。比如在起步阶段，要关注核心功能的实现、在发展阶段，要进行功能扩展和完善、在迭代阶段，要注重用户体验。
3）市场需求：在特点的时间、地点、特定人群的共同需求。就像故事所说，人们都需要更快更方便的出行方式。
4）用户需求：最直接的需求来源，是产品功能的直接使用者。因为有时候用户也说不清楚，所以要多问为什么，要比用户更了解他们想要什么。
5）同事反馈：同事也是高级用户，在团队工作中不可缺少的一部分。比如通过EXCEL导出产品或技术参数的明细，便于核对，确保参数的正确。
6）竞品分析：知己知彼，才能百战不殆。为什么人家会有这个功能？有什么特色或吹嘘或借鉴的地方？
7）头脑风暴：放空思绪，碰撞创造性的创意。人们需要交通工具更快、更载人，那么头脑风暴可能想到交通工具的舒适性、豪华感、身份象征、全自动等等。
四、需求会变化吗？
个人认为需求会变化正确，需求不会变化也正确。
为什么需求会变化正确。因为在需求分析阶段不可能解决全部的需求问题，人们在考虑问题总有不全面的时候，俗话说三个臭皮匠顶个诸葛亮，最好的方法是将各方意见综合在一起，尽量减少遗漏的点。所以在设计&开发&测试直至交付客户，都在不断与客户沟通，纠正需求理解的偏差。通常适当的需求变更是可以接受的。
为什么需求不会变化也正确。以交通工具的需求举例，从古到今，人们最初依靠双腿，后来驯服了马、发明了自行车、三轮车、汽车、轮船、火车、飞机等等，其实说到底，是用户对解决方案的期望值在不断变化，而需求一直存在并且没有变化。
五、如何获取需求？
可以分为政策调整、动态资讯、行业数据、用户调研、客户反馈。
1）政策调整：关注行业相关的政策调整，并思考其对现有功能的影响。
2）动态资讯：关注行业资讯，思考行业动向和趋势，及对产品的影响。
3）行业数据：利用行业数据报告、行业数据统计工具获取需求。
4）用户调研：以用户为中心的设计方法论所进行的活动，要走到用户当中，深入了解他们在具体场景下的想法和感受。
5）客户反馈：了解用户在使用产品或某功能的时候，遇到的问题以及一些之前根本没考虑到的需求点。
露出来的冰山，就好比用户能清晰、具体、明确表达出的需求和想法。水面下的冰山，就好比用户无法表达的愿望或未知的需求。所以，获取到需求后做好需求挖掘，能让决策更有说服力。
六、需求讨论的小妙招
需求讨论，是需求分析中最重要的一环。对分析人员的理解能力、沟通能力、与人交往等各方面要求比较高。那么，有哪些工作是可以提前准备、且能提高会议效率、还能体现我们的专业度能提升在客户心中的地位呢？
1）对需求进行深度理解、运用我们的专业知识或借鉴其他项目组的做法，提供比客户的需求更加合理、可操作的解决方式。
2）弄清楚客户方有哪些决策，谁是需求提出者、谁是决策者、谁在支持我们，而谁 又自觉不自觉的阻碍我们。
3）对于领域专家，需要谦虚慎重、相互尊重、慷慨的交往。
4）要结识能够帮助我们的人并保持适当的谦卑，因为我们要依靠他们去学习业务知识和收集需求，为将来需求分析提供素材。
5）确定合适的时间、合适的地点、通过合适的形式与客户讨论，并至少提前1日发出会议邀请。
6）可以将业务人员划分为多个业务组或按模块划分，因为业务人员自身局限，不可能对全部业务领域的细节全面掌握。
7）讨论中尽量使用业务术语，因为客户不一定要懂得软件开发的术语。
8）提前了解客户的业务和目标，准备好讨论的侧重并列出疑问。比如换系统，那么了解旧系统，有利于交流可改进之处。
七、我的需求分析的方法论
可以分为三大部分，首先是需求梳理，其次是需求分析，最后是需求评审。
1）需求梳理
a)建立需求池（通过EXCEL表格或软件记录下收集到的idea或功能，并初步评估优先级）
b)评估需求的合理性（充分与客户沟通、结合同行业做法或实际业务场景，找出可实现且有价值的需求，过滤掉那些无意义或者是暂时可以不实现，无关痛痒的需求。那么如何区分需求是否有价值？那就得看需求分析人员需要对产品的愿景和设计理念的理解、以及工作经验围绕着最终实现的功能去筛选。当然，如果收集到的需求数据无法满足现有产品功能的设计，也可以提出新的需求。比如用户要做一套账户信息浏览交易，那么需求分析人员提提顺便通过EXCEL清单或PDF对数据导出的功能。）
c)需求的划分（看需求属于新增的功能还是先有功能优化，属于in-scope还是out-scope）
2）需求分析
a)对现有逻辑的影响（也要考虑潜在的影响，比如将来新增了客户证件类型的种类，现有需求会有什么样的影响，如何设计方法能更提高可扩展性、灵活性）
b)需求方案的设计（新的需求可能设计新的流程、新的功能，设计方案时要考虑系统的可复用性、可扩展性）
c)多角度思考（很多时候一个需求不是仅仅涉及开发和测试，当实现之后更要市场、运营等部门进行配合，所以要全面思考给处合理化的建议和方案。）
3）需求评审
a)完成需求文档的编写，内部评审通过后转用户方审核，并帮助开发和用户解答需求中的问题。
b)跟踪需求开发，测试和验收阶段的问题，确保按时交付并高质量的上线。
c)复盘整个需求，有什么样的收获、能尽善尽美的地方、或在哪个环节耗时比较多。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
