需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。大多数的需求分析方法是由数据驱动的，也就是说，这些方法提供了一种表示数据域的机制。分析员根据这种表示，确定软件功能及其他特性，最终建立一个待开发软件的抽象模型，即目标系统的逻辑模型。数据域具有3种属性:数据流、数据内容和数据结构。通常，一种需求分析方法总要利用其中的一种或几种属性。

　　目前已经出现了许多需求分析方法，每一种分析方法都引入了不同的记号和分析策略。但是它们仍具有以下的共性:

　　（1）支持数据域分析的机制

　　尽管每种方法进行数据域分析的方式不同，但它们仍有一些共同点。所有的方法都直接或间接地涉及到数据流、数据内容或数据结构域的属性。在多数情况下，数据流特征是用将输入转换成输出的变换（功能）过程来描述的，数据内容可以用数据词典机制明确表示，或者通过描述数据或数据对象的层次结构隐含地表示。

　　（2）功能表示的方法

　　功能一般用数据变换或加工来表示，每项功能可用规定的记号（圆圈或方框）标识。功能的说明可以用自然语言文本来表达，也可以用形式化的规格说明语言来表达，还可以用上述的两种方式的混合方式———结构化语言来描述。

　　（3）接口的定义

　　接口的说明通常是数据表示和功能表示的直接产物。某个具体功能的流进和流出数据流应是其他相关功能的流出或流入的数据流。因此，通过数据流的分析可以确定功能间的接口。

　　（4）问题分解的机制以及对抽象的支持

　　问题分解和抽象主要依靠分析员在不同抽象层次上表示数据域和功能域，以逐层细化的手段建立分层结构来实现。例如，无论使用哪种分析方法，都能表示“计算职工每月工资”之类的功能，并在这个抽象层次上操纵这个功能。另外，所有的分析方法都提供逐层分解的机制，把“计算职工每月工资”功能划分成一些子功能，如计算房租、计算用电费、计算用水费、计算养老保险费等等。其中，每项子功能还可以在更低的一级抽象层次上表示。

　　（5）逻辑视图和物理视图

　　大多数方法允许分析员在着手问题的逻辑解决方案之前先分析物理视图。通常，同一种表示法既可用来表示逻辑视图，也可用来表示物理视图。

　　（6）系统抽象模型

　　为了能够比较精确地定义软件需求，可以建立待开发软件的一个抽象的模型，用基于抽象模型的术语来描述软件系统的功能和性能，形成软件需求规格说明。这种抽象的模型是从外部现实世界的问题领域抽象而来，在高级层次上描述和定义系统的服务。

　　对于比较简单的问题，不必建立抽象系统模型。或者可以认为，系统模型在分析员头脑中形成，直接由分析员写成规格说明。但对于比较复杂的问题，仅有在头脑中想象的模型是不够的，必须建立适当的比较形式化的抽象系统模型，才能准确全面地反映问题领域中各种复杂的要求。不同类型的问题有不同的需要解决的中心问题，因而要建立不同类型的系统模型。对于数学软件，设计的中心问题是算法，软件人员主要力量要花在数学模式算法的考虑上。对于数据通信软件，中心问题是数据传送和过程控制，实现算法简单，采用数据流模型比较合适。对于涉及大量数据的数据处理软件，中心问题是数据处理，包括数据的采集、数据的传送、存储、变换、输出等，一旦了解了数据结构，与它相关的算法就很简单了。如果系统要求有数据支持，通过数据库获取和存放信息，还需要考虑数据在数据库中的组织方式和存取方法，建立数据库模型。因此，在分析过程中数据模型是首先要集中精力考虑的问题。

　　系统模型的建立是对现实世界中存在的有关实体和活动的抽象和精化，其建立过程包括观察分析、模型表示和模型检查3个阶段。

　　首先，分析员和用户合作，从各方面观察现实世界中的有关实体和活动，建立理解的共同基准，分清哪些概念与系统相关，必须纳入系统模型，哪些是系统模型不必关心的，分析员和用户在共同理解的基础上，建立系统模型，包括系统提供的各种系统服务，模型表示的细节应有:系统输入、系统输出、系统数据处理、系统控制等。

　　建立系统模型以后，还要进行检查。除了静态检查之外，系统描述可以部分地模拟执行，将执行情况与对外部现实世界系统观察得到的系统跟踪信息进行对照，检查模型是否符合要求。这种建立系统模型并模拟执行和检查的方法叫做系统原型开发。