我太难了，自认为对需求已经非常清楚了，但交付软件时用户却说：这不是他想要的！
软件行业从事需求分析师的人经常会提到下面的一些有代表性的现象
■现象1.认真听取了用户需求、并且用界面原型向用户进行了需求确认，费尽了千辛万苦把软件开发出来后，用户一试却说“这不是我想要的东西！”，这样的结果让我感到崩溃，不是确认好的吗？！这说明编码之前需求工程师与用户双方对用原型表达的需求认知是一致的（如不一致是不会开始编码的），相信很多需求分析师都经历过，这个问题一旦发生了就会带来开发返工、成本超支、延迟罚款，甚至最后双方不欢而散。
■现象2.开发工程师总是抱怨说需求分析师的资料看不懂、表达不清晰，有时为了搞清楚一个问题（在一张A4纸上用文字说明）可能需要打3～4天的电话沟通。久而久之就造成了产品经理、开发工程师对需求分析师的不信任，形成了需求分析师水平低的印象。
■现象3.对完成的分析与设计结果正确与否判断不清楚（或没有判断方法）。老手的需求分析师可以通过积累的专业知识和经验来做出判断，但是对新手的需求分析师来说因为没有积累可以利用，常常面对完成的分析与设计结果不知道用什么方法来判断它的正确与否，交给开发之后总是提心吊胆怕什么地方出错误。
这种现象在其他行业则很少会出现，比如IT行业经常会用建筑与软件的设计制造过程做比较，但由于建筑物是具象的，看到设计图形马上能联系起你所有的经验记忆，在大脑中建立起一个具体的形象。描绘建筑物是用几何图形、位置关系和物理尺寸来表达的，比如：用与实际相似的图形来表达建筑物的外观，还可以将建筑物分解为窗、门、柱、梁、板等构件，同样用完全相似的图形来表达，建筑物从里到外都可以精确地给出构件之间的衔接关系，看了建筑设计图之后，投资业主、建筑设计师和施工公司三方都不会对图形有认知上的歧义。
那么软件行业为什么会出现前述的现象呢？主要是因为软件产品的需求和交付物都比较“抽象”，很难用“具象”的图形表达出来，对同一个软件需求不同的人有不同的理解和表达，没有绝对公知的、唯一的和定量的表达方式，这个难题对提需求的用户、分析需求和开发的软件工程师来说都是一样的，这就容易造成交流时出现理解和认知上的误差。
有的需求分析师说：与用户交流前我画了高保真的界面原型，用原型法向用户确认需求并获得了用户的认可，为什么还会出现不尽人意的结果呢？原因在于：利用原型法虽然可以直观地说明与确认界面上数据输入方面的需求，但是对不同原型之间的关系、输入后数据之间的关系、业务整体的运行机理、未来需求发生变化时系统的应对方法等，用原型法是难以获得这些复杂逻辑关系和重要信息的，原型法主要帮助获得功能操作层面的逻辑和信息。
抽象的对象是人为的认识，用文字、界面表达的内容与现实的对象有联系，但是并不能够做到“形似”，（因为研究的对象没有“形”），它是一种用文字、或是逻辑图标（符号）表达的“抽象”形象。在软件中除去操作界面（interface）的表达具有一定的“形象”以外，支持这个界面运行的所有内容都是抽象的， 比如采购流程、组织分解、管理控制、合同签订、核算支付等，它们的事理、逻辑非常不同。
软件需求工作中重要的成果之一就是分析和表达“逻辑”，除了用文字和界面原型的方法外，表达逻辑的最重要的方式是绘制逻辑图，逻辑图是由图标、连接线、位置、包含关系等组成的（对比建筑物的表达用图标、形状、位置、尺寸等）。界面原型表达的是“数据的输入和处理结果的展示”，逻辑图形表达的是“业务事理、逻辑”，是表面看不到的信息，而这些信息正是用来抽提业务规律、建立数据模型的依据。
因此，在需求调研完成时除去要搞清楚功能（界面原型）和数据以外，还必须要搞清楚“逻辑”。除界面原型和文字两种形式外，表达逻辑的图形有：业务的分层图、框架图、分解图、流程图、数据勾稽图等。用图形表达的逻辑来源于“架构设计”，缺乏逻辑表达的资料往往缺乏的就是架构设计环节，没有架构设计环节的系统基本上就是需求分析师看到什么做到什么，看一步做一步。缺乏逻辑表达的是造成前述现象的重要原因之一。下面简单说明一下逻辑与前述现象之间的因果关系。
□现象1：界面原型与逻辑
用户可以理解原型界面上的内容，但是他不清楚原型背后的逻辑（如流程、流转条件、发生变化时的应对方法等），这是因为需求工程师用界面原型仅确认了用户做事的“表单（需要哪些字段）”，但没有做业务流程、各功能间协同关系等深层次的逻辑确认，所以当系统运行中处理各种各样的真实场景时，用户就感到不是他预想的样子了（通常用户会认为界面原型对了，原型背后的逻辑就一定是他想要的样子）。
□现象2：开发工程师与逻辑
软件开发工程师非常关注逻辑表达（因为编程是基于逻辑进行的），需求分析资料必须要表达出做事的步骤顺序、每个步骤上的内容、内容要描述到精细的规则。由于需求分析师不注重从“逻辑”的角度进行分析与表达，且完成资料中的大部分内容采用文章体的描述方式，由于文字表达的局限性（不规范、因人而异等），就造成了产品经理、开发工程师的阅读和理解的困难（特别是复杂逻辑），觉得资料中的功能描述都是独立的、缺乏逻辑关系的描述，整个系统到处是断点、经不起推敲。
□现象3：结果是否正确与逻辑推演
从事需求分析工作时间短、或是遇到了首次接触的用户业务时，如果新手需求分析师能够采用“逻辑推演”的方式进行调研和分析，则可以很大程度上弥补因对用户业务知识不足而带来的判断不准问题。逻辑推演方式分为三层（业务逻辑层、数据逻辑层和管控逻辑层）来检查分析与设计结果是否正确，其原理就是采用“顺藤摸瓜”的方法搞清楚研究对象，在三个不同层面上进行逻辑推演的方式简述如下：
□第一层（底层）-业务逻辑推理（确保业务事理正确）。
第一层主要用业务架构图的形式表达。给出业务构成的要素、要素间的关系，这一步给出了业务要素之间外在的“定性关系”，勾勒出业务的“形象”，使得所研究的业务对象可视、有形，它是后续分析、设计、开发的基础。业务关系明白了，粗线条的逻辑关系就清楚了。
□第二层（中层）-数据逻辑推理（确定数据间引用关系）
第二层主要用数据关系图的形式表达，在第一层的基础上给出业务要素内在的“定量关系”，第一层说明了要素之间的外在关系是定性的，第二层通过对数据之间的逻辑关系分析，给出要素之间精确的、唯一的关系表达。数据关系明白了，详细的逻辑关系就清楚了。
□第三层（上层）-管控逻辑推理（确定约束条件合理）
有了前面对业务要素的从“业务层、数据层”的“定性、定量”分析和描述，下面就可以在此基础之上给出要素之间的管控关系，管控关系说明了要素之间的相互作用以及因此产生的约束关系，约束关系在企业管理系统的中的作用就是“管理”。
完成符合三层逻辑的设计后，最后再采用业务用例验证和应用用例验证的方式对设计结果进行检查和验证（即利用场景进行动态推演）。这种方式大大地提升了需求分析师与用户、开发工程师的沟通效率，基本上确保了分析与设计结果与完成后系统的相似度，同时也基本上消除了系统开发完成后发生大规模返工或推倒重来的风险。
从前述的三种现象以及造成现象的原因可以看出来，研发一款非具象的软件产品，逻辑思维、分析和表达是非常重要的基础能力，需求分析师是将用户的抽象需求、通过分析和设计，转换为可视、可操作产品的第一人。某种意义上可以说，需求分析师的逻辑思维、分析和表达水平，决定了最终产品水平的高低，特别是对于复杂系统来说更是如此。
通过逻辑推演的方法搞清楚了用户需求，虽然还不能表明你具有优化需求和提升用户价值的能力（要想做到优化和提升，还必须掌握相当深度的用户业务知识），但至少为理解、优化和提升打下了基础。