由于技术局限，用户很难准确地把系统需求传达给开发商；由于业务局限，开发商也很难准确获取用户真实的应用需求。需求信息的不对称和需求描述的错位，容易引起系统设计的缺陷，最终导致系统应用不理想甚至系统失败。可以说，需求调研和分析是信息化建设的第一步，也是关键一步，牵一发而动全身。
什么是系统需求？
简而言之，系统需求就是从用户的应用特点出发，依据其总体规划和目标，对系统进行抽取细化，就系统性能、规格、行为等方面总结出来的期望。
更进一步，用户需求可以分为两类：系统需求和软件需求。前者是整个系统所提出的需求，后者则是系统中软件部分所涉及的需要。
从应用特点看，系统需求可分为基本需求和特定需求，在特定需求中又可细分为必需的特定需求和非必需的特定需求。一般来说，特定需求往往决定系统的二次开发。
如何进行需求调研？
需求调研涉及三个问题。一是如何确定调研对象，二是如何确定被调研对象，三是采用何种调研方法。调研对象的组成应以互补为原则，至少要由三类人员组成：技术人员、业务专家和管理者。被调研对象主要是人员和业务两类，其间主要涉及人与人、人与事物、事物与事物等三种关系。
其中，关键是确定调研范围。调研范围包括关键域和关键活动。而关键活动又由关键流程加关键点构成。
找到关键域，明确关键流程和关键点，对需求调研至关重要，需要专家或咨询顾问介入。而能否把握这一时机并找准需求提炼的关键点，是考验需求调研人员的重要方面。优秀的需求调研人员不仅能认识问题之所在，还能藉此获取足够多的知识，最后成为问题领域的专家。
需求调研非常困难，必须引起重视。因为：
●缺乏专门领域的知识，同时应用领域中的许多问题通常模糊，很难界定；
●机构实践存在默认知识，难以描述；
●多个知识源或信息源既有冲突又有重合；
●被调研对象可能有认知偏见或者欠缺或有时不愿提供确切信息。
这些都会给需求调研人员带来障碍和困难。在这种情况下，掌握必要的方法与技巧非常重要。
需求调研方法一般有问卷法、面谈法、数据采集法、用况法、情景实例法以及基于目标的方法等。此外，还有知识工程方法，如场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。然而最基本的方法还是问卷法和面谈法。
如何进行需求分析?
需求工程是继软件工程之后的又一热点工程。从理论上说，包括调研需求、模拟和分析需求、需求描述、需求认可、需求演进这五个层次，并且逐层递进、螺旋式上升。需求分析是需求工程的核心，贯穿于系统整个生命周期。
需求分析的出发点在于：对调研的需求进行进一步提炼并指导需求的抽取；帮助需求分析人员发现问题。需求模拟则帮助检查验证对问题的理解。需求分析和模拟又包含三个层次的工作：需求定义、需求建模、需求模拟。
需求定义，是对经调研获取的需求进行初步整理，抽取其中基本需求和关键需求予以界定，并为需求建模提供必要的需求元素。
需求建模，是把抽象的需求通过概念、符号、数学模型及逻辑结构表现出来。表现形式有自然语言、半形式化（如图、表、结构化英语等）和形式化表示等三种。自然语言形式具有表达能力强的优点，但不利于捕获模型语义；半形式化表示可捕获结构和一定的语义，也可进行一定的推理和一致性检查；形式化表示具有精确的语义和推理能力，但构造一个完整的形式化模型，需要较长时间和对问题领域的深层次理解。相对而言，图表形式的需求模型直观常用，比如组织结构图、系统流程图、网络拓扑图等。
良好的需求概念模型应包括以下几个特点：实现的独立性、足够抽象、足够形式化、可构造性、利于分析、可追踪性、可执行性、最小冗余性。
需求模拟，分为企业模拟、功能需求模拟和非功能需求模拟等。
企业模拟是一种软系统方法，涉及整个组织，从不同视点分析问题，包括目标、组织结构、活动、过程等。有些企业模拟，还建立可执行的领域模型。
功能需求模拟从不同视点为模拟软件提供服务，包括结构视点和行为视点等，主要方法有结构化分析、面向对象分析和形式化方法。
结构化分析是一种面向数据的方法，以数据流为中心。其核心概念包括进程、数据流、数据存储、外部实体、数据组和数据元素。有代表性的模拟工具有数据流图、数据字典、原始进程规格说明。
面向对象分析以对象及其服务作为建模标准，比较自然，对象也具有相对稳定性。主要模拟元素有对象、类、属性、关系、方法、消息传递、UseCases等。其主要原理包括分类继承层次、信息隐藏、汇集关系等。
形式化方法，一般用于一致性检查、类型检查、有效性验证、行为预测以及设计求精验证。但形式化手段也有局限性，表现在形式化涉及太多细节，分析级别较低；其核心问题是一致性和完整性，而不是获取需求；没有合适工具；代价更多。
描述需求的任务是撰写软件需求规格说明书，这是需求调研和分析的直接成果。好的需求规格说明书需求层次清晰、语言专业且简练、基本需求描述完整、特定需求既有现实性又有前瞻性、流程和结构定义准确、有可操作性、可逆性等。
需求规格说明书的主要服务对象可能来自于用户、系统分析员、软件需求分析员、软件开发者、程序员、测试员、项目管理者等。但归根结底还是要尊重用户发展战略和机构运行策略所必需的现实的和潜在的期望。
需求描述完成并不意味需求工作的结束，需求认可和需求演进是确保系统持续改进的必经之路。需求认可就是让上述人员对需求规格说明达成一致。需求演进的必要性是明显的，因为用户需求不断变化，系统开发又总是落后于客户需求的变化和增长，如何及时感知需求变化并系统整理成为系统进化的首要问题。可以说，基于需求演进的管理效率直接决定了系统能否支持用户的持续变革。