关键词：
前两周，我分别通过两篇文章《测试人员参与需求评审的价值是什么？》和《需求评审之实战演练》对需求评审阶段要做的事情做了大概的说明，今天是第三篇，主要想说说需求评审过程中对隐形需求挖掘的重要性。
一
我们先来看一个例子：
「爸爸，我想吃面条。」
「现在太晚了，饭店已经关门了，明天我带你去吃好不好？」
「不好不好，我就要吃面条。」
「你这孩子，这都 11 点了，哪还有面条？快给我睡觉去。」
「哇……」
脑补下宝宝大哭的画面。
来，我们现在换一个爸爸来对话：
「爸爸，我想吃面条。」
「今天太晚了，饭店已经关门了，明天我带你去吃好不好？」
「不好不好，我就要吃面条。」
「闺女是不是肚子饿了？我给你拿你最爱吃的面包好不好？」
「好呀好呀。」
虽然只是一句话的差别，但是得到的结果却是天壤之别。
上面例子中这句话如果按我们测试的行话说，就是发现了用户的隐性真实需求。
我闺女是想吃面条，但是因为饿才想吃，而不是单纯的想吃，那么只要解决饿的问题就好了，她爱吃意大利面我是知道的，她同样也爱吃吐司，我也是知道的，所以就可以通过吐司来解决她饿的问题了。
道理看起来很简单，但如果想不到这个点，就解决不了问题，还有可能造成负面影响。
这里我想说的是，隐性需求，就是真实的原始需求。
二
我们继续拿之前那个简易计算器的需求作为第二个例子，重新描述下需求：
现在有一个 PC 客户端的命令行工具，这个工具可以接收三个命令行参数，其中，前两个是数字，最后一个是运算符，运算符只支持加减乘除四种，工具的功能就是把前两个数字使用运算符做下运算，然后输出运算结果。
看过之前文章的同学都知道，这是我经常用的一道写测试点的面试题。
从我面试的结果看，大部分在写功能测试点的时候都能覆盖到三个参数的正常和异常情况，一半的人能考虑到参数个数的正常和异常情况，一小半的人能考虑到数字参数的最大值情况，非常少的人能考虑到参数分隔符的正常和异常情况。
参数类型、参数个数这些都是需求里面明确写出来的，这些我们可以称为显性需求，所以能考虑到这部分用例的人很多，特别是参数的正常和异常，不管是否知道等价类划分法，都能考虑到。
但是参数个数和数字最大值，又可以算到边界值分析法里面，如果不知道边界值分析，可能不会考虑到参数个数所有异常的覆盖情况，如果不懂编程，可能问不出来数字使用什么类型这样的问题，当然也就不知道所谓的最大值要怎么构造了，所以这个也可以算到隐性需求的范畴。
最后一个很少人考虑到的参数分隔符，肯定是我们要说的隐性需求了，这种没有明确说明的地方，有时候开发会按照自己自以为的方式给实现了，比如默认空格分割，但是测试后期发现很多人也会用逗号去分割，修改的话会造成新的修改成本，其实这么简单的地方，需求评审的时候提一下，就可以把需求明确了，难的是谁能想的到。
这里我想说的是，隐性需求，就是把习惯性思维明确化。
三
第一个关于原始需求的例子，如果拿我们实际项目的情况来对应的话，可以找出来很多，比如某用户嫌某个软件的功能太多，其实他可能只是说他常用的功能入口太深而已，比如某用户嫌软件广告太多，其实可能只是推送的这些广告都不是他的关注点而已。
第二个关于习惯性思维的例子，实际项目中也经常发生，而且特别坑人，有个专有名词叫「经验主义」特别适合这个地方，这里我又想起来另一个例子，可以说一说。
我高中时的数学还不错，最喜欢上的就是数学课，对各种数学题比较感兴趣。
记得有一次课间休息，我不知道怎么就坐到一位成绩不太好的同学的座位上了，然后看到他桌子上放着还没做完的数学作业，一时兴起，就顺手给做完了，本来想着这同学回来该感谢我的，可是等到的却是责怪，责怪我不该把他作业给做了，确实是我的错，我一时无语。
事后我仔细想了想，这件事纯粹就是我自己的一厢情愿了，我以为不爱学习的同学都不爱写作业，我以为帮别人写了作业别人会高兴，所有这些都是「我以为」，或者说是我的经验主义在作祟，让我没能从实际情况去做出正确的判断。
这种事在需求评审过程中很常见，有一些貌似「不言自明」的逻辑，每个人都以为自己明白，别人也肯定能明白，并且和自己理解的一致，其实每个人可能理解的都不一样。
这件事之后，我对自己的经验就总是持怀疑态度了，不过这是另外的话题了，这件事带给我的一个好处就是，每件事我都尽可能的去把它明确了，我听别人说的话，就算很明白，我也尽量复述一遍让他确认，别人听我说的话，我也尽量让他复述一遍，我再确认。
其实需求评审就是这么个明确显性需求、挖掘隐性需求，然后相互确认理解一致的过程。
这里我想说的是，隐性需求，就是避免经验主义。
四
一不小心又啰哩啰嗦的写了这么多，几个例子无非都想说明的是，隐性需求很重要，有时候，正确挖掘过的隐性需求会直接推翻现有的需求方案。
不知道你的项目中是否出现过这些情况，欢迎留言讨论。
产品经理之产品评审会
...板下载五、参考文章 一、什么是产品评审会 需求评审通常是由产品经理主持，通过讲解产品需求文档，让相关人员了解具体需求，并提出疑问，进行沟通的过程。统一大家对产品需求的理解，为后续“如何做&rdqu... 查看详情
测试之功能测试
...来，我们来看一下功能测试的工作流程： 1.需求分析与评审 2.测试计划与测试方案 3.测试用例设计 4.测试用例评审 5.执行测试用例 6.缺陷跟踪与产出报告最后，我们来一一详细了... 查看详情
软件测试流程
一、测试过程之需求分析 测试介入阶段一般从需求分析开始，需求分析阶段是整个软件生命周期最关键的一环，产品、研发、测试三方对产品需求理解应做到一致，所以需求评审会尤其重要，所以一般会先进行一次需求评审... 查看详情
第六章：需求评审如何进行
前言今天我们讲的需求评审包括两个部分，需求过滤和需求评审。需求过滤1.需求分析不是所有需求都要做进产品，我们要根据公司和产品的定位，进行合适地分析和过滤。我们需要分析出用户需求所对应的本质，将其转化为产... 查看详情
产品经理的战场：需求评审会
因项目需要做需求评审，之前没有参与过类似专题工作，特地在网上找了些资料，感觉这篇还不错。 【转载自互联网的壹些事】 你还记得自己参加过多少场「需求评审会」吗?不管自己是作为主机主导，还是作为僚机配合，... 查看详情
测试流程
1.产品经理去客户现场进行需求调研，将调研后点需求整理成文档2.产品经理根据需求画原型3.产品经理叫上开发负责人、测试负责人进行一次小范围的需求评审，评审通过后将需求发给项目组成员（一般需求评审前一天发给... 查看详情
测试需求内容
测试需求名称*测试需求编号*需求来源：规格/设计报告评审状态：已评审/未评审重要性：高/中/低紧迫性：高/中/低优先级：高/中/低业务前提测试需求状态：新增/修改创建人*创建日期*业务功能说明*业务要素分析：输入/输出业... 查看详情
《软件测试常见面试题四》
1.简述软件测试的基本过程a、测试人员进行测试需求分析b、测试负责人编写测试计划c、测试人员根据测试需求分机设计和编写测试用例d、测试人员搭建测试环境，创建测试数据，执行测试用例，提交缺陷报告并进行跟踪、记录... 查看详情
《软件测试常见面试题四》
1.简述软件测试的基本过程a、测试人员进行测试需求分析b、测试负责人编写测试计划c、测试人员根据测试需求分机设计和编写测试用例d、测试人员搭建测试环境，创建测试数据，执行测试用例，提交缺陷报告并进行跟踪、记录... 查看详情
团队项目-需求分析报告
团队项目-需求分析报告一、博客链接组长博客二、组队后的团队项目的整体计划安排编写需求说明书。约定好编码规范，初步架构搭建，完成需求规格说明书最终版。UI设计，完成架构设计，制定测试计划。完成Alpha版本——编... 查看详情
学生宿舍水电管理系统产品需求评审（用户故事）
学生宿舍水电管理系统产品需求评审（用户故事） 用户故事通常按照如下的格式来表达： 作为一个<角色>，我想要<做什么、活动>，以便达到<什么目的、商业价值> (Asa<Role>,Iwantto<... 查看详情
全程软件测试_测试过程工作分解表
1.需求、Demo、开发计划评审1.1阅读文档以了解系统需求（需求包含字段的具体描述）1.2需求规格说明书评审1.3编写/修改测试需求1.4Demo的查看和评审1.5开发计划查看和评审2.测试计划2.1确定测试目标（功能性需求和非功能性需求... 查看详情
5.5.产品设计之项目管理
了解市场→了解需求→产品设计→产品运营产品设计：产品理念，产品方案及规划，产品架构设计，交互设计，原型及需求，项目管理，验收及发布，用户体验，实战点评。综述：01.产品规划产品设计理念：02.产品设计基... 查看详情
课程笔记——网易测试工程师的日常
1.一个产品问世的流程：产品孵化-需求/策划-交互/视觉-开发/测试-系统运维-运营/推广-用户研究-数据分析。2.测试过程：1）需求评审（仔细评审需求，挖掘需求漏洞；推动开发仔细评审需求，推动需求仔细完善需求）2）测试分... 查看详情
软件测试流程详解
测试流程需求分析与评审编写测试计划与测试方案设计测试用例与评审用例执行测试用例与缺陷跟踪编写测试报告需求分析与评审什么是软件需求？软件需求：是指为用户解决某一问题或达到某一目标所需要的软件功能。如：手... 查看详情
项目需求分析
项目需求分析一、团队分工组员比重（%）林泽宇16李涵14尹海川14郏敏杰14何永康14陈炳旭14苏宇翔14二、产品订单v1.0无三、使用场景描述无四、评审表格无五、评审结果无 查看详情
测试用例评审流程
...能由研发和测试自行定义人员研发人员测试人员研发经理需求人员时间由测试人员编写完测试用例和思路后，进行评审，评审时间必须根据预期时间（提前预期24小时）给出，如有延误提前通知与会人员。考虑需求功能交互疑问... 查看详情
项目整体工作流程总结---20200109
开始--提出需求（业务需求报告）--项目立项（项目立项说明书、项目立项PPT）--立项评审--需求调研（项目需求文档、需求调研单）--项目计划（WBS、项目整体计划）--需求分析（产品原型、需求规格说明书）--蓝图评审--系统设... 查看详情