测试小故事24：寻找需求的真相

  经典的需求理解图示。

  相同的需求，不同的人理解各不相同。
  是什么造成对于需求理解的不同：行业知识、行业背景、工作的环境、生活的经历、问题的痛点、思考的方式。。。。。。
  面对需求，林林总总的不同，造成了不同人对于需求的描述、原型设计的不同。
  面对需求，有你理解的一面，有我理解的一面，更重要的是有真实需求的一面。

  软件开发过程中，面对需求的问题争议存在一个特殊的角色：仲裁，也就是对需求进行最终确认和拍板。
  软件开发过程中，开发与测试之间的争执总是聚焦于：
  1.是不是BUG？
   你说是BUG，我理解的不是，需求说了算。。。对不起需求的真相在被不断的描述中已经变异了
  2.BUG要不要改？
   你说改，我认为不影响不需要改，需求说了算。。。需求的真相还没有被真正的描述出来呢
  无论怎么解释，判断的依据依旧是：需求。
  需求有哪些？显示需求 + 隐式需求
  依图不难发现，显示需求的理解尚且会有不同的描述，何况隐式需求呢？理解不同造成评判标准的不同 
 
  既然需求这么不靠谱，软件开发过程又能做什么呢？总结一句：
  破解需求理解的不同，我们需要的不仅仅是信息量，不仅仅是沟通，更需要多维度的思考和观察。
  1.理解和明确原始需求的真相。锤子和凿子的需求并不是锤子和凿子本身，可能真正的需求只是最后凿出来的那个洞。知道了真正的原始需求后，实现需求只是手段和方法的不同。
  2.针对不同的角色用专业的语言描述需求。对客户讲需求用行业语言而不是讲C++、JAVA或是操作系统、数据库，对开发讲需求用设计、模块、MVC的模式讲解，而不是用高深和专业的行业语言。真正靠近不同角色，用行业形像化的思维才能真正讲通需求。
  3.用不同的方法、不同的方式描述需求，寻找描述间的漏洞，不断修正。日常沟通中，当彼此不理解或是出现偏差时，最好的办法就是从不同的角度重新描述问题，直至彼此达成一致。 Let's us check it again.