有的需求分析师说：与用户交流前我画了高保真的界面原型，用原型法向用户确认需求并获得了用户的认可，为什么还会出现不尽人意的结果呢？原因在于：利用原型法可以直观地说明与确认界面上数据输入方面的需求，对不同原型之间的关系、输入后数据之间的关系、业务整体的运行机理、未来需求发生变化时系统的应对方法等，用原型法是难以获得这些复杂逻辑关系和重要信息的，原型法主要帮助获得功能操作层面的逻辑和信息。
抽象的对象是人为的认识，用文字、界面表达的内容与现实的对象有联系，并不能够做到“形似”，（因为研究的对象没有“形”），它是一种用文字、或是逻辑图标（符号）表达的“抽象”形象。在软件中除去操作界面（interface）的表达具有一定的“形象”以外，支持这个界面运行的所有内容都是抽象的，比如采购流程、组织分解、管理控制、合同签订、核算支付等，它们的事理、逻辑非常不同。
软件需求工作中重要的成果之一就是分析和表达“逻辑”，除了用文字和界面原型的方法外，表达逻辑的重要的方式是绘制逻辑图，逻辑图是由图标、连接线、位置、包含关系等组成的（对比建筑物的表达用图标、形状、位置、尺寸等）。界面原型表达的是“数据的输入和处理结果的展示”，逻辑图形表达的是“业务事理、逻辑”，是表面看不到的信息，而这些信息正是用来抽提业务规律、建立数据模型的依据。
在需求调研完成时除去要搞清楚功能（界面原型）和数据以外，还必须要搞清楚“逻辑”。除界面原型和文字两种形式外，表达逻辑的图形有：业务的分层图、框架图、分解图、流程图、数据勾稽图等。用图形表达的逻辑来源于“架构设计”，缺乏逻辑表达的资料往往缺乏的就是架构设计环节，没有架构设计环节的系统基本上就是需求分析师看到什么做到什么，看一步做一步。缺乏逻辑表达的是造成前述现象的重要原因之一。下面简单说明一下逻辑与前述现象之间的因果关系。
□现象1：界面原型与逻辑
用户可以理解原型界面上的内容，他不清楚原型背后的逻辑（如流程、流转条件、发生变化时的应对方法等），这是因为需求工程师用界面原型仅确认了用户做事的“表单（需要哪些字段）”，但没有做业务流程、各功能间协同关系等深层次的逻辑确认，当系统运行中处理各种各样的真实场景时，用户就感到不是他预想的样子了（通常用户会认为界面原型对了，原型背后的逻辑就一定是他想要的样子）。