国内的软件公司在追求文档规范的同时，忽略了图表示意、交互操作模拟对调研内容传递的重要作用。
文档只是作为对需求调研内容辅助描述的一种手段，如果把他作为需求调研内容的唯一载体那将是一个极其悲哀的一件事情。上文所说的文档我暂且把它限定在平面化的文档，也就是缺乏用户交互体验的文档。
包括CMM软件成熟模型要求的文档化，随着软件系统的复杂，应用水平的提高，其文档化的内涵必然不断地扩展和延伸。随着多媒体技术的发展以及应用软件模型化开发的普及。国内对需求调研的真实度、仿真度的要求必定越来越高。
我们曾经走过一些改良的路子：利用成型的软件来做需求调研的原形。这不失为一个好方法，可以将自己的管理理念、系统功能快速的介绍给用户，使用户的思维尽早的转换到“今后我用这个系统的时候，他还有何缺陷，有没有更好的实现方法？”的思维模式上来，而不是“今后这个系统应该具备什么功能，这个功能应该如何实现？”。但是我们同样也遇到这样的困惑，成型的系统，面对用户的特殊需求，需求调研人员由于开发技术上的缺陷无法快速按照用户的需求构造出一个可交互模拟的业务办公原形与用户进行沟通，从而丧失宝贵的第一手资料。
因此我们可以采用业务快速建模的方式完成业务手工办理模式的计算机模拟。使项目的需求调研内容可以直观通过计算机的模拟操作来进行解释说明，使需求调研内容不只停留在访谈和文字描述的阶段，当然文档补充描述是必不可少的。
一般情况下，我们在进行需求调研时，会形成3个主要的成果：组织结构调研、业务流程调研、软硬件环境调研。将这三个方面的成果映射到用户的需求模型的计算机描述：组织模型、业务模型、资源模型。
文档只是作为对需求调研内容辅助描述的一种手段，如果把他作为需求调研内容的唯一载体那将是一个极其悲哀的一件事情。上文所说的文档我暂且把它限定在平面化的文档，也就是缺乏用户交互体验的文档。
包括CMM软件成熟模型要求的文档化，随着软件系统的复杂，应用水平的提高，其文档化的内涵必然不断地扩展和延伸。随着多媒体技术的发展以及应用软件模型化开发的普及。国内对需求调研的真实度、仿真度的要求必定越来越高。
我们曾经走过一些改良的路子：利用成型的软件来做需求调研的原形。这不失为一个好方法，可以将自己的管理理念、系统功能快速的介绍给用户，使用户的思维尽早的转换到“今后我用这个系统的时候，他还有何缺陷，有没有更好的实现方法？”的思维模式上来，而不是“今后这个系统应该具备什么功能，这个功能应该如何实现？”。但是我们同样也遇到这样的困惑，成型的系统，面对用户的特殊需求，需求调研人员由于开发技术上的缺陷无法快速按照用户的需求构造出一个可交互模拟的业务办公原形与用户进行沟通，从而丧失宝贵的第一手资料。
因此我们可以采用业务快速建模的方式完成业务手工办理模式的计算机模拟。使项目的需求调研内容可以直观通过计算机的模拟操作来进行解释说明，使需求调研内容不只停留在访谈和文字描述的阶段，当然文档补充描述是必不可少的。
一般情况下，我们在进行需求调研时，会形成3个主要的成果：组织结构调研、业务流程调研、软硬件环境调研。将这三个方面的成果映射到用户的需求模型的计算机描述：组织模型、业务模型、资源模型。
- 组织模型再细分可以分为：用户、岗位、权限；
- 业务模型再细分可以分为：业务状态、业务角色、业务权限、业务表单（输入、查询、新增修改、输出）、业务报表、业务流程、数据模型、业务资源（组件、服务（web service、job service）、脚本、消息）；
- 资源模型再细分可以分为：基础类库、扩展类库、模板中心、注册组件、注册服务。
以上是静态的管理框架的基本功能需求，还缺少一个动态的支持业务流转的运行框架。下面以抽象的业务办理流程为例说明业务模型定义、模拟运行的主要功能需求。一般业务在计算机实现基本上包括以下几个方面：录入信息、查询信息、办件通知、办件过程查询、办结通知、退件通知、办件流转。
- 办件流转、办件通知是组织管理业务办理各要素，并使之协作的根本；
- 信息采集是业务办理的本质需求；
- 信息查询（汇总）是业务办理的辅助需求。
通过业务流程来将状态、权限、角色、表单、报表、资源等各个要素组织起来形成可流转的业务模型。每个工作节点分别由办理角色、操作表单、操作报表、操作资源、办理时限（是否计入工作时间）、工作任务提交处理机制业务模型元素来描述每个工作节点的内容。
并且通过业务模型可以生成业务调研的成果，比如word文档。